Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit bd9c6dc

Browse files
committed
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
1 parent 2eb2fcd commit bd9c6dc

File tree

5 files changed

+87
-50
lines changed

5 files changed

+87
-50
lines changed

doc/src/sgml/release-9.0.sgml

+16-10
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66

77
<note>
88
<title>Release Date</title>
9-
<simpara>2015-05-21</simpara>
9+
<simpara>2015-05-22</simpara>
1010
</note>
1111

1212
<para>
@@ -58,18 +58,24 @@
5858

5959
<listitem>
6060
<para>
61-
Consistently check for failure of the <function>*printf()</> family of
62-
functions (Noah Misch)
61+
Improve detection of system-call failures (Noah Misch)
6362
</para>
6463

6564
<para>
66-
Most calls of these functions did not consider the possibility that
67-
the functions could fail with, eg, out-of-memory conditions. The usual
68-
result would just be missing output, but crashes or exposure of
69-
unintended information are also possible. To protect against such
70-
risks uniformly, create wrappers around these functions that throw an
71-
error on failure. Also add missing error checks to a few
72-
security-relevant calls of other system functions.
65+
Our replacement implementation of <function>snprintf()</> failed to
66+
check for errors reported by the underlying system library calls;
67+
the main case that might be missed is out-of-memory situations.
68+
In the worst case this might lead to information exposure, due to our
69+
code assuming that a buffer had been overwritten when it hadn't been.
70+
Also, there were a few places in which security-relevant calls of other
71+
system library functions did not check for failure.
72+
</para>
73+
74+
<para>
75+
It remains possible that some calls of the <function>*printf()</>
76+
family of functions are vulnerable to information disclosure if an
77+
out-of-memory error occurs at just the wrong time. We judge the risk
78+
to not be large, but will continue analysis in this area.
7379
(CVE-2015-3166)
7480
</para>
7581
</listitem>

doc/src/sgml/release-9.1.sgml

+16-10
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66

77
<note>
88
<title>Release Date</title>
9-
<simpara>2015-05-21</simpara>
9+
<simpara>2015-05-22</simpara>
1010
</note>
1111

1212
<para>
@@ -58,18 +58,24 @@
5858

5959
<listitem>
6060
<para>
61-
Consistently check for failure of the <function>*printf()</> family of
62-
functions (Noah Misch)
61+
Improve detection of system-call failures (Noah Misch)
6362
</para>
6463

6564
<para>
66-
Most calls of these functions did not consider the possibility that
67-
the functions could fail with, eg, out-of-memory conditions. The usual
68-
result would just be missing output, but crashes or exposure of
69-
unintended information are also possible. To protect against such
70-
risks uniformly, create wrappers around these functions that throw an
71-
error on failure. Also add missing error checks to a few
72-
security-relevant calls of other system functions.
65+
Our replacement implementation of <function>snprintf()</> failed to
66+
check for errors reported by the underlying system library calls;
67+
the main case that might be missed is out-of-memory situations.
68+
In the worst case this might lead to information exposure, due to our
69+
code assuming that a buffer had been overwritten when it hadn't been.
70+
Also, there were a few places in which security-relevant calls of other
71+
system library functions did not check for failure.
72+
</para>
73+
74+
<para>
75+
It remains possible that some calls of the <function>*printf()</>
76+
family of functions are vulnerable to information disclosure if an
77+
out-of-memory error occurs at just the wrong time. We judge the risk
78+
to not be large, but will continue analysis in this area.
7379
(CVE-2015-3166)
7480
</para>
7581
</listitem>

doc/src/sgml/release-9.2.sgml

+16-10
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66

77
<note>
88
<title>Release Date</title>
9-
<simpara>2015-05-21</simpara>
9+
<simpara>2015-05-22</simpara>
1010
</note>
1111

1212
<para>
@@ -58,18 +58,24 @@
5858

5959
<listitem>
6060
<para>
61-
Consistently check for failure of the <function>*printf()</> family of
62-
functions (Noah Misch)
61+
Improve detection of system-call failures (Noah Misch)
6362
</para>
6463

6564
<para>
66-
Most calls of these functions did not consider the possibility that
67-
the functions could fail with, eg, out-of-memory conditions. The usual
68-
result would just be missing output, but crashes or exposure of
69-
unintended information are also possible. To protect against such
70-
risks uniformly, create wrappers around these functions that throw an
71-
error on failure. Also add missing error checks to a few
72-
security-relevant calls of other system functions.
65+
Our replacement implementation of <function>snprintf()</> failed to
66+
check for errors reported by the underlying system library calls;
67+
the main case that might be missed is out-of-memory situations.
68+
In the worst case this might lead to information exposure, due to our
69+
code assuming that a buffer had been overwritten when it hadn't been.
70+
Also, there were a few places in which security-relevant calls of other
71+
system library functions did not check for failure.
72+
</para>
73+
74+
<para>
75+
It remains possible that some calls of the <function>*printf()</>
76+
family of functions are vulnerable to information disclosure if an
77+
out-of-memory error occurs at just the wrong time. We judge the risk
78+
to not be large, but will continue analysis in this area.
7379
(CVE-2015-3166)
7480
</para>
7581
</listitem>

doc/src/sgml/release-9.3.sgml

+16-10
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66

77
<note>
88
<title>Release Date</title>
9-
<simpara>2015-05-21</simpara>
9+
<simpara>2015-05-22</simpara>
1010
</note>
1111

1212
<para>
@@ -58,18 +58,24 @@
5858

5959
<listitem>
6060
<para>
61-
Consistently check for failure of the <function>*printf()</> family of
62-
functions (Noah Misch)
61+
Improve detection of system-call failures (Noah Misch)
6362
</para>
6463

6564
<para>
66-
Most calls of these functions did not consider the possibility that
67-
the functions could fail with, eg, out-of-memory conditions. The usual
68-
result would just be missing output, but crashes or exposure of
69-
unintended information are also possible. To protect against such
70-
risks uniformly, create wrappers around these functions that throw an
71-
error on failure. Also add missing error checks to a few
72-
security-relevant calls of other system functions.
65+
Our replacement implementation of <function>snprintf()</> failed to
66+
check for errors reported by the underlying system library calls;
67+
the main case that might be missed is out-of-memory situations.
68+
In the worst case this might lead to information exposure, due to our
69+
code assuming that a buffer had been overwritten when it hadn't been.
70+
Also, there were a few places in which security-relevant calls of other
71+
system library functions did not check for failure.
72+
</para>
73+
74+
<para>
75+
It remains possible that some calls of the <function>*printf()</>
76+
family of functions are vulnerable to information disclosure if an
77+
out-of-memory error occurs at just the wrong time. We judge the risk
78+
to not be large, but will continue analysis in this area.
7379
(CVE-2015-3166)
7480
</para>
7581
</listitem>

doc/src/sgml/release-9.4.sgml

+23-10
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66

77
<note>
88
<title>Release Date</title>
9-
<simpara>2015-05-21</simpara>
9+
<simpara>2015-05-22</simpara>
1010
</note>
1111

1212
<para>
@@ -87,22 +87,35 @@ Branch: REL9_3_STABLE [c669915fd] 2015-05-18 10:02:37 -0400
8787
Branch: REL9_2_STABLE [01272d95a] 2015-05-18 10:02:37 -0400
8888
Branch: REL9_1_STABLE [2cb9f2cab] 2015-05-18 10:02:38 -0400
8989
Branch: REL9_0_STABLE [9b5e831e3] 2015-05-18 10:02:38 -0400
90+
Author: Tom Lane <tgl@sss.pgh.pa.us>
91+
Branch: master [0c071936e] 2015-05-19 18:19:38 -0400
92+
Branch: REL9_4_STABLE [2eb2fcd56] 2015-05-19 18:16:19 -0400
93+
Branch: REL9_3_STABLE [13341276e] 2015-05-19 18:16:58 -0400
94+
Branch: REL9_2_STABLE [221f7a949] 2015-05-19 18:17:42 -0400
95+
Branch: REL9_1_STABLE [0510cff6e] 2015-05-19 18:18:16 -0400
96+
Branch: REL9_0_STABLE [cf893530a] 2015-05-19 18:18:56 -0400
9097
-->
9198

9299
<listitem>
93100
<para>
94-
Consistently check for failure of the <function>*printf()</> family of
95-
functions (Noah Misch)
101+
Improve detection of system-call failures (Noah Misch)
102+
</para>
103+
104+
<para>
105+
Our replacement implementation of <function>snprintf()</> failed to
106+
check for errors reported by the underlying system library calls;
107+
the main case that might be missed is out-of-memory situations.
108+
In the worst case this might lead to information exposure, due to our
109+
code assuming that a buffer had been overwritten when it hadn't been.
110+
Also, there were a few places in which security-relevant calls of other
111+
system library functions did not check for failure.
96112
</para>
97113

98114
<para>
99-
Most calls of these functions did not consider the possibility that
100-
the functions could fail with, eg, out-of-memory conditions. The usual
101-
result would just be missing output, but crashes or exposure of
102-
unintended information are also possible. To protect against such
103-
risks uniformly, create wrappers around these functions that throw an
104-
error on failure. Also add missing error checks to a few
105-
security-relevant calls of other system functions.
115+
It remains possible that some calls of the <function>*printf()</>
116+
family of functions are vulnerable to information disclosure if an
117+
out-of-memory error occurs at just the wrong time. We judge the risk
118+
to not be large, but will continue analysis in this area.
106119
(CVE-2015-3166)
107120
</para>
108121
</listitem>

0 commit comments

Comments
 (0)