===================================================================
RCS file: /cvsrepo/anoncvs/cvs/www/errata45.html,v
retrieving revision 1.55
retrieving revision 1.56
diff -c -r1.55 -r1.56
*** www/errata45.html	2017/03/28 04:04:52	1.55
--- www/errata45.html	2017/03/28 06:41:18	1.56
***************
*** 84,90 ****
  <hr>
  
  <ul>
! <li id="016_openssl">
  <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
--- 84,90 ----
  <hr>
  
  <ul>
! <li id="p016_openssl">
  <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
***************
*** 94,104 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="015_mpi">
  <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://man.openbsd.org/?query=mpi&sektion=4">mpi(4)</a>
  allocates temporary memory and then returns it to the kernel as
  device memory.
  This causes kernel memory usage to be misrepresented, eventually
--- 94,104 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p015_mpi">
  <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://man.openbsd.org/OpenBSD-4.5/mpi.4">mpi(4)</a>
  allocates temporary memory and then returns it to the kernel as
  device memory.
  This causes kernel memory usage to be misrepresented, eventually
***************
*** 109,115 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="014_kerberos">
  <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
--- 109,115 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p014_kerberos">
  <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
***************
*** 120,126 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="013_ftpd">
  <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
--- 120,126 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p013_ftpd">
  <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
***************
*** 130,136 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="012_openssl">
  <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
--- 130,136 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p012_openssl">
  <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
***************
*** 140,146 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="011_ptrace">
  <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
--- 140,146 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p011_ptrace">
  <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
***************
*** 151,157 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="010_openssl">
  <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
--- 151,157 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p010_openssl">
  <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
***************
*** 163,169 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="009_getsockopt">
  <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,
--- 163,169 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p009_getsockopt">
  <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,
***************
*** 173,179 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="008_xmm">
  <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.
--- 173,179 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p008_xmm">
  <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.
***************
*** 182,188 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="007_bind">
  <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
--- 182,188 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p007_bind">
  <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
***************
*** 194,200 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="006_perl">
  <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
--- 194,200 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p006_perl">
  <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
***************
*** 209,221 ****
  <p>
  
  
! <li id="005_audio">
  <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
! <a href="http://man.openbsd.org/?query=audio&sektion=4">audio(4)</a>
  driver causing the audio application to go out of sync, and in turn causing
  continuous stuttering until the application is restarted.
  <br>
--- 209,221 ----
  <p>
  
  
! <li id="p005_audio">
  <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
! <a href="http://man.openbsd.org/OpenBSD-4.5/audio.4">audio(4)</a>
  driver causing the audio application to go out of sync, and in turn causing
  continuous stuttering until the application is restarted.
  <br>
***************
*** 223,233 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="004_aucat">
  <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://man.openbsd.org/?query=aucat&sektion=1">aucat(1)</a>
  will send each synchronization message twice, causing client applications
  to think that buffer underruns are occuring.  Depending on the
  application, this may cause the sound to stutter.
--- 223,233 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p004_aucat">
  <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://man.openbsd.org/OpenBSD-4.5/aucat.1">aucat(1)</a>
  will send each synchronization message twice, causing client applications
  to think that buffer underruns are occuring.  Depending on the
  application, this may cause the sound to stutter.
***************
*** 236,248 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="003_bus_dma">
  <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
! <a href="http://man.openbsd.org/?query=audio&sektion=4">audio(4)</a>
  to stutter, but other anomalies might be observed for other
  device types.
  <br>
--- 236,248 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p003_bus_dma">
  <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
! <a href="http://man.openbsd.org/OpenBSD-4.5/audio.4">audio(4)</a>
  to stutter, but other anomalies might be observed for other
  device types.
  <br>
***************
*** 250,256 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="002_pf">
  <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,
--- 250,256 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p002_pf">
  <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,
***************
*** 271,277 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="001_openssl">
  <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
--- 271,277 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p001_openssl">
  <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