mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Last-minute updates for release notes.

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

Security: CVE-2015-3166
This commit is contained in:
Tom Lane 2015-05-19 18:33:58 -04:00
parent 0c071936e9
commit 5cb8519ceb
5 changed files with 87 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
doc/src/sgml/release-9.0.sgml
View File

@ -6,7 +6,7 @@
<note>
<title>Release Date</title>
<simpara>2015-05-21</simpara>
<simpara>2015-05-22</simpara>
</note>
<para>
@ -58,18 +58,24 @@
<listitem>
<para>
Consistently check for failure of the <function>*printf()</> family of
functions (Noah Misch)
Improve detection of system-call failures (Noah Misch)
</para>
<para>
Most calls of these functions did not consider the possibility that
the functions could fail with, eg, out-of-memory conditions. The usual
result would just be missing output, but crashes or exposure of
unintended information are also possible. To protect against such
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.
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>
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)
</para>
</listitem>

26
doc/src/sgml/release-9.1.sgml
View File

@ -6,7 +6,7 @@
<note>
<title>Release Date</title>
<simpara>2015-05-21</simpara>
<simpara>2015-05-22</simpara>
</note>
<para>
@ -58,18 +58,24 @@
<listitem>
<para>
Consistently check for failure of the <function>*printf()</> family of
functions (Noah Misch)
Improve detection of system-call failures (Noah Misch)
</para>
<para>
Most calls of these functions did not consider the possibility that
the functions could fail with, eg, out-of-memory conditions. The usual
result would just be missing output, but crashes or exposure of
unintended information are also possible. To protect against such
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.
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>
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)
</para>
</listitem>

26
doc/src/sgml/release-9.2.sgml
View File

@ -6,7 +6,7 @@
<note>
<title>Release Date</title>
<simpara>2015-05-21</simpara>
<simpara>2015-05-22</simpara>
</note>
<para>
@ -58,18 +58,24 @@
<listitem>
<para>
Consistently check for failure of the <function>*printf()</> family of
functions (Noah Misch)
Improve detection of system-call failures (Noah Misch)
</para>
<para>
Most calls of these functions did not consider the possibility that
the functions could fail with, eg, out-of-memory conditions. The usual
result would just be missing output, but crashes or exposure of
unintended information are also possible. To protect against such
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.
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>
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)
</para>
</listitem>

26
doc/src/sgml/release-9.3.sgml
View File

@ -6,7 +6,7 @@
<note>
<title>Release Date</title>
<simpara>2015-05-21</simpara>
<simpara>2015-05-22</simpara>
</note>
<para>
@ -58,18 +58,24 @@
<listitem>
<para>
Consistently check for failure of the <function>*printf()</> family of
functions (Noah Misch)
Improve detection of system-call failures (Noah Misch)
</para>
<para>
Most calls of these functions did not consider the possibility that
the functions could fail with, eg, out-of-memory conditions. The usual
result would just be missing output, but crashes or exposure of
unintended information are also possible. To protect against such
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.
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>
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)
</para>
</listitem>

33
doc/src/sgml/release-9.4.sgml
View File

@ -6,7 +6,7 @@
<note>
<title>Release Date</title>
<simpara>2015-05-21</simpara>
<simpara>2015-05-22</simpara>
</note>
<para>
@ -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_1_STABLE [2cb9f2cab] 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>
<para>
Consistently check for failure of the <function>*printf()</> family of
functions (Noah Misch)
Improve detection of system-call failures (Noah Misch)
</para>
<para>
Most calls of these functions did not consider the possibility that
the functions could fail with, eg, out-of-memory conditions. The usual
result would just be missing output, but crashes or exposure of
unintended information are also possible. To protect against such
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.
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>
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)
</para>
</listitem>