===================================================================
RCS file: /cvsrepo/anoncvs/cvs/www/errata45.html,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- www/errata45.html	2014/03/31 03:12:47	1.36
+++ www/errata45.html	2014/03/31 16:02:48	1.37
@@ -77,7 +77,8 @@
 
 <ul>
 <li><a name="016_openssl"></a>
-<font color="#009000"><strong>016: SECURITY FIX: April 14, 2010</strong></font> &nbsp; <i>All architectures</i><br>
+<font color="#009000"><strong>016: SECURITY FIX: April 14, 2010</strong></font>
+&nbsp; <i>All architectures</i><br>
 In TLS connections, certain incorrectly formatted records can cause
 an OpenSSL client or server to crash due to a read attempt at NULL.
 <br>
@@ -86,7 +87,8 @@
 <p>
 
 <li><a name="015_mpi"></a>
-<font color="#009000"><strong>015: RELIABILITY FIX: April 4, 2010</strong></font> &nbsp; <i>All architectures</i><br>
+<font color="#009000"><strong>015: RELIABILITY FIX: April 4, 2010</strong></font>
+&nbsp; <i>All architectures</i><br>
 When updating sensors showing the state of RAID volumes
 <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=mpi&sektion=4">mpi(4)</a>
 allocates temporary memory and then returns it to the kernel as
@@ -100,7 +102,8 @@
 <p>
 
 <li><a name="014_kerberos"></a>
-<font color="#009000"><strong>014: RELIABILITY FIX: March 31, 2010</strong></font> &nbsp; <i>All architectures</i><br>
+<font color="#009000"><strong>014: RELIABILITY FIX: March 31, 2010</strong></font>
+&nbsp; <i>All architectures</i><br>
 When decrypting packets, the internal decryption functions were not
 paranoid enough in checking for underruns, which could potentially
 lead to crashes.
@@ -110,7 +113,8 @@
 <p>
 
 <li><a name="013_ftpd"></a>
-<font color="#009000"><strong>013: RELIABILITY FIX: March 12, 2010</strong></font> &nbsp; <i>All architectures</i><br>
+<font color="#009000"><strong>013: RELIABILITY FIX: March 12, 2010</strong></font>
+&nbsp; <i>All architectures</i><br>
 Due to a null pointer dereference, it would be possible to crash ftpd when
 handling glob(3)'ing requests. This is non-exploitable.
 <br>
@@ -119,7 +123,8 @@
 <p>
 
 <li><a name="012_openssl"></a>
-<font color="#009000"><strong>012: SECURITY FIX: March 12, 2010</strong></font> &nbsp; <i>All architectures</i><br>
+<font color="#009000"><strong>012: SECURITY FIX: March 12, 2010</strong></font>
+&nbsp; <i>All architectures</i><br>
 OpenSSL is susceptible to a buffer overflow due to a failure
 to check for NULL returns from bn_wexpand function calls.
 <br>
@@ -128,7 +133,8 @@
 <p>
 
 <li><a name="011_ptrace"></a>
-<font color="#009000"><strong>011: RELIABILITY FIX: January 29, 2010</strong></font> &nbsp; <i>All architectures</i><br>
+<font color="#009000"><strong>011: RELIABILITY FIX: January 29, 2010</strong></font>
+&nbsp; <i>All architectures</i><br>
 By using ptrace(2) on an ancestor process, a loop in the process tree
 could be created, violating assumptions in other parts of the kernel
 and resulting in infinite loops.
@@ -138,7 +144,8 @@
 <p>
 
 <li><a name="010_openssl"></a>
-<font color="#009000"><strong>010: SECURITY FIX: November 26, 2009</strong></font> &nbsp; <i>All architectures</i><br>
+<font color="#009000"><strong>010: SECURITY FIX: November 26, 2009</strong></font>
+&nbsp; <i>All architectures</i><br>
 The SSL/TLS protocol is subject to man-in-the-middle attacks related to
 renegotiation (see CVE-2009-3555, draft-ietf-tls-renegotiation-00).
 OpenSSL permitted this protocol feature by default and had no way to
@@ -149,7 +156,8 @@
 <p>
 
 <li><a name="009_getsockopt"></a>
-<font color="#009000"><strong>009: RELIABILITY FIX: October 28, 2009</strong></font> &nbsp; <i>All architectures</i><br>
+<font color="#009000"><strong>009: RELIABILITY FIX: October 28, 2009</strong></font>
+&nbsp; <i>All architectures</i><br>
 getsockopt(2) with any of IP_AUTH_LEVEL, IP_ESP_TRANS_LEVEL, IP_ESP_NETWORK_LEVEL,
 IP_IPCOMP_LEVEL will crash the system.
 <br>
@@ -158,7 +166,8 @@
 <p>
 
 <li><a name="008_xmm"></a>
-<font color="#009000"><strong>008: RELIABILITY FIX: October 05, 2009</strong></font> &nbsp; <i>i386 only</i><br>
+<font color="#009000"><strong>008: RELIABILITY FIX: October 05, 2009</strong></font>
+&nbsp; <i>i386 only</i><br>
 XMM exceptions are not correctly handled resulting in a kernel panic.
 <br>
 <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/4.5/i386/008_xmm.patch">
@@ -166,7 +175,8 @@
 <p>
 
 <li><a name="007_bind"></a>
-<font color="#009000"><strong>007: RELIABILITY FIX: July 29, 2009</strong></font> &nbsp; <i>All architectures</i><br>
+<font color="#009000"><strong>007: RELIABILITY FIX: July 29, 2009</strong></font>
+&nbsp; <i>All architectures</i><br>
 A vulnerability has been found in BIND's named server
 (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0696">CVE-2009-0696</a>).
 An attacker could crash a server with a specially crafted dynamic update message to a
@@ -177,7 +187,8 @@
 <p>
 
 <li><a name="006_perl"></a>
-<font color="#009000"><strong>006: RELIABILITY FIX: June 24, 2009</strong></font> &nbsp; <i>All architectures</i><br>
+<font color="#009000"><strong>006: RELIABILITY FIX: June 24, 2009</strong></font>
+&nbsp; <i>All architectures</i><br>
 An off-by-one error in the inflate function in Zlib.xs in the
 Compress::Raw::Zlib perl module before 2.017 (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1391">CVE-2009-1391</a>),
 as used in AMaViS, SpamAssassin, and possibly other products,
@@ -191,7 +202,8 @@
 
 
 <li><a name="005_audio"></a>
-<font color="#009000"><strong>005: RELIABILITY FIX: April 24, 2009</strong></font> &nbsp; <i>All architectures</i><br>
+<font color="#009000"><strong>005: RELIABILITY FIX: April 24, 2009</strong></font>
+&nbsp; <i>All architectures</i><br>
 On very high system load, an audio interrupt may occur while the
 audio process is filling audio ring buffers. This triggers bogus
 (and useless) correction code in the
@@ -204,7 +216,8 @@
 <p>
 
 <li><a name="004_aucat"></a>
-<font color="#009000"><strong>004: RELIABILITY FIX: April 24, 2009</strong></font> &nbsp; <i>All architectures</i><br>
+<font color="#009000"><strong>004: RELIABILITY FIX: April 24, 2009</strong></font>
+&nbsp; <i>All architectures</i><br>
 In server mode when in full-duplex mode (the default)
 <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=aucat&sektion=1">aucat(1)</a>
 will send each synchronization message twice, causing client applications
@@ -216,7 +229,8 @@
 <p>
 
 <li><a name="003_bus_dma"></a>
-<font color="#009000"><strong>003: RELIABILITY FIX: April 24, 2009</strong></font> &nbsp; <i>i386 only</i><br>
+<font color="#009000"><strong>003: RELIABILITY FIX: April 24, 2009</strong></font>
+&nbsp; <i>i386 only</i><br>
 When DMA'able memory is mapped by device drivers, the
 mapping flags and protection are partially uninitialized.
 Depending on the calling context, this may cause devices to misbehave, like
@@ -229,7 +243,8 @@
 <p>
 
 <li><a name="002_pf"></a>
-<font color="#009000"><strong>002: RELIABILITY FIX: April 11, 2009</strong></font> &nbsp; <i>All architectures</i><br>
+<font color="#009000"><strong>002: RELIABILITY FIX: April 11, 2009</strong></font>
+&nbsp; <i>All architectures</i><br>
 When pf attempts to perform translation on a specially crafted IP datagram,
 a null pointer dereference will occur, resulting in a kernel panic.
 In certain configurations this may be triggered by a remote attacker.
@@ -249,7 +264,8 @@
 <p>
 
 <li><a name="001_openssl"></a>
-<font color="#009000"><strong>001: RELIABILITY FIX: April 8, 2009</strong></font> &nbsp; <i>All architectures</i><br>
+<font color="#009000"><strong>001: RELIABILITY FIX: April 8, 2009</strong></font>
+&nbsp; <i>All architectures</i><br>
 The OpenSSL ASN.1 handling code could be forced to perform invalid memory
 accesses through the use of certain invalid strings
 (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0590">CVE-2009-0590</a>)