Commit 5cb8519c authored by Tom Lane's avatar Tom Lane

Last-minute updates for release notes.

Revise description of CVE-2015-3166, in line with scaled-back patch.
Change release date.

Security: CVE-2015-3166
parent 0c071936
...@@ -6,7 +6,7 @@ ...@@ -6,7 +6,7 @@
<note> <note>
<title>Release Date</title> <title>Release Date</title>
<simpara>2015-05-21</simpara> <simpara>2015-05-22</simpara>
</note> </note>
<para> <para>
...@@ -58,18 +58,24 @@ ...@@ -58,18 +58,24 @@
<listitem> <listitem>
<para> <para>
Consistently check for failure of the <function>*printf()</> family of Improve detection of system-call failures (Noah Misch)
functions (Noah Misch)
</para> </para>
<para> <para>
Most calls of these functions did not consider the possibility that Our replacement implementation of <function>snprintf()</> failed to
the functions could fail with, eg, out-of-memory conditions. The usual check for errors reported by the underlying system library calls;
result would just be missing output, but crashes or exposure of the main case that might be missed is out-of-memory situations.
unintended information are also possible. To protect against such In the worst case this might lead to information exposure, due to our
risks uniformly, create wrappers around these functions that throw an code assuming that a buffer had been overwritten when it hadn't been.
error on failure. Also add missing error checks to a few Also, there were a few places in which security-relevant calls of other
security-relevant calls of other system functions. system library functions did not check for failure.
</para>
<para>
It remains possible that some calls of the <function>*printf()</>
family of functions are vulnerable to information disclosure if an
out-of-memory error occurs at just the wrong time. We judge the risk
to not be large, but will continue analysis in this area.
(CVE-2015-3166) (CVE-2015-3166)
</para> </para>
</listitem> </listitem>
......
...@@ -6,7 +6,7 @@ ...@@ -6,7 +6,7 @@
<note> <note>
<title>Release Date</title> <title>Release Date</title>
<simpara>2015-05-21</simpara> <simpara>2015-05-22</simpara>
</note> </note>
<para> <para>
...@@ -58,18 +58,24 @@ ...@@ -58,18 +58,24 @@
<listitem> <listitem>
<para> <para>
Consistently check for failure of the <function>*printf()</> family of Improve detection of system-call failures (Noah Misch)
functions (Noah Misch)
</para> </para>
<para> <para>
Most calls of these functions did not consider the possibility that Our replacement implementation of <function>snprintf()</> failed to
the functions could fail with, eg, out-of-memory conditions. The usual check for errors reported by the underlying system library calls;
result would just be missing output, but crashes or exposure of the main case that might be missed is out-of-memory situations.
unintended information are also possible. To protect against such In the worst case this might lead to information exposure, due to our
risks uniformly, create wrappers around these functions that throw an code assuming that a buffer had been overwritten when it hadn't been.
error on failure. Also add missing error checks to a few Also, there were a few places in which security-relevant calls of other
security-relevant calls of other system functions. system library functions did not check for failure.
</para>
<para>
It remains possible that some calls of the <function>*printf()</>
family of functions are vulnerable to information disclosure if an
out-of-memory error occurs at just the wrong time. We judge the risk
to not be large, but will continue analysis in this area.
(CVE-2015-3166) (CVE-2015-3166)
</para> </para>
</listitem> </listitem>
......
...@@ -6,7 +6,7 @@ ...@@ -6,7 +6,7 @@
<note> <note>
<title>Release Date</title> <title>Release Date</title>
<simpara>2015-05-21</simpara> <simpara>2015-05-22</simpara>
</note> </note>
<para> <para>
...@@ -58,18 +58,24 @@ ...@@ -58,18 +58,24 @@
<listitem> <listitem>
<para> <para>
Consistently check for failure of the <function>*printf()</> family of Improve detection of system-call failures (Noah Misch)
functions (Noah Misch)
</para> </para>
<para> <para>
Most calls of these functions did not consider the possibility that Our replacement implementation of <function>snprintf()</> failed to
the functions could fail with, eg, out-of-memory conditions. The usual check for errors reported by the underlying system library calls;
result would just be missing output, but crashes or exposure of the main case that might be missed is out-of-memory situations.
unintended information are also possible. To protect against such In the worst case this might lead to information exposure, due to our
risks uniformly, create wrappers around these functions that throw an code assuming that a buffer had been overwritten when it hadn't been.
error on failure. Also add missing error checks to a few Also, there were a few places in which security-relevant calls of other
security-relevant calls of other system functions. system library functions did not check for failure.
</para>
<para>
It remains possible that some calls of the <function>*printf()</>
family of functions are vulnerable to information disclosure if an
out-of-memory error occurs at just the wrong time. We judge the risk
to not be large, but will continue analysis in this area.
(CVE-2015-3166) (CVE-2015-3166)
</para> </para>
</listitem> </listitem>
......
...@@ -6,7 +6,7 @@ ...@@ -6,7 +6,7 @@
<note> <note>
<title>Release Date</title> <title>Release Date</title>
<simpara>2015-05-21</simpara> <simpara>2015-05-22</simpara>
</note> </note>
<para> <para>
...@@ -58,18 +58,24 @@ ...@@ -58,18 +58,24 @@
<listitem> <listitem>
<para> <para>
Consistently check for failure of the <function>*printf()</> family of Improve detection of system-call failures (Noah Misch)
functions (Noah Misch)
</para> </para>
<para> <para>
Most calls of these functions did not consider the possibility that Our replacement implementation of <function>snprintf()</> failed to
the functions could fail with, eg, out-of-memory conditions. The usual check for errors reported by the underlying system library calls;
result would just be missing output, but crashes or exposure of the main case that might be missed is out-of-memory situations.
unintended information are also possible. To protect against such In the worst case this might lead to information exposure, due to our
risks uniformly, create wrappers around these functions that throw an code assuming that a buffer had been overwritten when it hadn't been.
error on failure. Also add missing error checks to a few Also, there were a few places in which security-relevant calls of other
security-relevant calls of other system functions. system library functions did not check for failure.
</para>
<para>
It remains possible that some calls of the <function>*printf()</>
family of functions are vulnerable to information disclosure if an
out-of-memory error occurs at just the wrong time. We judge the risk
to not be large, but will continue analysis in this area.
(CVE-2015-3166) (CVE-2015-3166)
</para> </para>
</listitem> </listitem>
......
...@@ -6,7 +6,7 @@ ...@@ -6,7 +6,7 @@
<note> <note>
<title>Release Date</title> <title>Release Date</title>
<simpara>2015-05-21</simpara> <simpara>2015-05-22</simpara>
</note> </note>
<para> <para>
...@@ -87,22 +87,35 @@ Branch: REL9_3_STABLE [c669915fd] 2015-05-18 10:02:37 -0400 ...@@ -87,22 +87,35 @@ Branch: REL9_3_STABLE [c669915fd] 2015-05-18 10:02:37 -0400
Branch: REL9_2_STABLE [01272d95a] 2015-05-18 10:02:37 -0400 Branch: REL9_2_STABLE [01272d95a] 2015-05-18 10:02:37 -0400
Branch: REL9_1_STABLE [2cb9f2cab] 2015-05-18 10:02:38 -0400 Branch: REL9_1_STABLE [2cb9f2cab] 2015-05-18 10:02:38 -0400
Branch: REL9_0_STABLE [9b5e831e3] 2015-05-18 10:02:38 -0400 Branch: REL9_0_STABLE [9b5e831e3] 2015-05-18 10:02:38 -0400
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [0c071936e] 2015-05-19 18:19:38 -0400
Branch: REL9_4_STABLE [2eb2fcd56] 2015-05-19 18:16:19 -0400
Branch: REL9_3_STABLE [13341276e] 2015-05-19 18:16:58 -0400
Branch: REL9_2_STABLE [221f7a949] 2015-05-19 18:17:42 -0400
Branch: REL9_1_STABLE [0510cff6e] 2015-05-19 18:18:16 -0400
Branch: REL9_0_STABLE [cf893530a] 2015-05-19 18:18:56 -0400
--> -->
<listitem> <listitem>
<para> <para>
Consistently check for failure of the <function>*printf()</> family of Improve detection of system-call failures (Noah Misch)
functions (Noah Misch) </para>
<para>
Our replacement implementation of <function>snprintf()</> failed to
check for errors reported by the underlying system library calls;
the main case that might be missed is out-of-memory situations.
In the worst case this might lead to information exposure, due to our
code assuming that a buffer had been overwritten when it hadn't been.
Also, there were a few places in which security-relevant calls of other
system library functions did not check for failure.
</para> </para>
<para> <para>
Most calls of these functions did not consider the possibility that It remains possible that some calls of the <function>*printf()</>
the functions could fail with, eg, out-of-memory conditions. The usual family of functions are vulnerable to information disclosure if an
result would just be missing output, but crashes or exposure of out-of-memory error occurs at just the wrong time. We judge the risk
unintended information are also possible. To protect against such to not be large, but will continue analysis in this area.
risks uniformly, create wrappers around these functions that throw an
error on failure. Also add missing error checks to a few
security-relevant calls of other system functions.
(CVE-2015-3166) (CVE-2015-3166)
</para> </para>
</listitem> </listitem>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment