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
This commit is contained in:
parent
0c071936e9
commit
5cb8519ceb
@ -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 @@
|
|||||||
|
|
||||||
<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 @@
|
|||||||
|
|
||||||
<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 @@
|
|||||||
|
|
||||||
<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 @@
|
|||||||
|
|
||||||
<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 @@
|
|||||||
|
|
||||||
<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 @@
|
|||||||
|
|
||||||
<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 @@
|
|||||||
|
|
||||||
<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 @@
|
|||||||
|
|
||||||
<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
|
|||||||
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>
|
||||||
|
|
||||||
<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>
|
||||||
|
Loading…
x
Reference in New Issue
Block a user