Last-minute updates for release notes.REL9_3_7

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

Security: CVE-2015-3166

4 files changed, 64 insertions, 40 deletions

diff --git a/doc/src/sgml/release-9.0.sgml b/doc/src/sgml/release-9.0.sgml
index a3d9461fa6f..9794b5b3b76 100644
--- a/doc/src/sgml/release-9.0.sgml
+++ b/doc/src/sgml/release-9.0.sgml
@@ -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>
diff --git a/doc/src/sgml/release-9.1.sgml b/doc/src/sgml/release-9.1.sgml
index 82dde5e038b..f6c0d131576 100644
--- a/doc/src/sgml/release-9.1.sgml
+++ b/doc/src/sgml/release-9.1.sgml
@@ -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>
diff --git a/doc/src/sgml/release-9.2.sgml b/doc/src/sgml/release-9.2.sgml
index ff715efaa59..168a387d345 100644
--- a/doc/src/sgml/release-9.2.sgml
+++ b/doc/src/sgml/release-9.2.sgml
@@ -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>
diff --git a/doc/src/sgml/release-9.3.sgml b/doc/src/sgml/release-9.3.sgml
index 4c0d8535435..38f3354bd8f 100644
--- a/doc/src/sgml/release-9.3.sgml
+++ b/doc/src/sgml/release-9.3.sgml
@@ -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>