open-dsi
/
postgres
mirror of https://github.com/postgres/postgres
1
0
Fork 0
Code Issues 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
pull/14/head
Tom Lane 10 years ago
parent 0c071936e9
commit 5cb8519ceb
5 changed files with 87 additions and 50 deletions
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Show Stats Download Patch File Download Diff File
  1. 26
      doc/src/sgml/release-9.0.sgml
  2. 26
      doc/src/sgml/release-9.1.sgml
  3. 26
      doc/src/sgml/release-9.2.sgml
  4. 26
      doc/src/sgml/release-9.3.sgml
  5. 33
      doc/src/sgml/release-9.4.sgml

26
doc/src/sgml/release-9.0.sgml
Unescape 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
Unescape 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
Unescape 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
Unescape 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
Unescape 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>
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>
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.
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>

Write Preview
Loading…
Cancel
Save