Skip to content

P
Postgres FD Implementation
Commit 5cb8519c authored by Tom Lane's avatar Tom Lane
Browse files
Options

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
Hide whitespace changes
Inline Side-by-side
Showing with 87 additions and 50 deletions
doc/src/sgml/release-9.0.sgml
View file @ 5cb8519c
......@@ -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>
......
doc/src/sgml/release-9.1.sgml
View file @ 5cb8519c
......@@ -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>
......
doc/src/sgml/release-9.2.sgml
View file @ 5cb8519c
......@@ -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>
......
doc/src/sgml/release-9.3.sgml
View file @ 5cb8519c
......@@ -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>
......
doc/src/sgml/release-9.4.sgml
View file @ 5cb8519c
......@@ -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>
......
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