===================================================================
RCS file: /cvsrepo/anoncvs/cvs/www/errata47.html,v
retrieving revision 1.49
retrieving revision 1.50
diff -c -r1.49 -r1.50
*** www/errata47.html	2017/03/28 04:04:52	1.49
--- www/errata47.html	2017/03/28 06:41:18	1.50
***************
*** 82,88 ****
  <hr>
  
  <ul>
! <li id="013_pf">
  <font color="#009000"><strong>013: SECURITY FIX: February 16, 2011</strong></font>
  &nbsp; <i>Little-endian architectures</i><br>
  PF rules specifying address ranges (e.g. "10.1.1.1 - 10.1.1.5") were
--- 82,88 ----
  <hr>
  
  <ul>
! <li id="p013_pf">
  <font color="#009000"><strong>013: SECURITY FIX: February 16, 2011</strong></font>
  &nbsp; <i>Little-endian architectures</i><br>
  PF rules specifying address ranges (e.g. "10.1.1.1 - 10.1.1.5") were
***************
*** 94,100 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="012_openssl">
  <font color="#009000"><strong>012: SECURITY FIX: February 11, 2011</strong></font>
  &nbsp; <i>All architectures</i><br>
  An incorrectly formatted ClientHello handshake message could cause
--- 94,100 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p012_openssl">
  <font color="#009000"><strong>012: SECURITY FIX: February 11, 2011</strong></font>
  &nbsp; <i>All architectures</i><br>
  An incorrectly formatted ClientHello handshake message could cause
***************
*** 112,118 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="011_rtsock">
  <font color="#009000"><strong>011: RELIABILITY FIX: January 13, 2011</strong></font>
  &nbsp; <i>All architectures</i><br>
  sp_protocol in RTM_DELETE messages could contain garbage values
--- 112,118 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p011_rtsock">
  <font color="#009000"><strong>011: RELIABILITY FIX: January 13, 2011</strong></font>
  &nbsp; <i>All architectures</i><br>
  sp_protocol in RTM_DELETE messages could contain garbage values
***************
*** 123,138 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="010_cbc">
  <font color="#009000"><strong>010: RELIABILITY FIX: December 20, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  Bring CBC oracle attack countermeasures to hardware crypto accelerator land.
  This fixes aes-ni, via xcrypt and various drivers
! (<a href="http://man.openbsd.org/?query=glxsb&arch=i386&sektion=4">glxsb(4)</a>,
! <a href="http://man.openbsd.org/?query=hifn&sektion=4">hifn(4)</a>,
! <a href="http://man.openbsd.org/?query=safe&sektion=4">safe(4)</a>
  and
! <a href="http://man.openbsd.org/?query=ubsec&sektion=4">ubsec(4)</a>).
  
  <br>
  <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.7/common/010_cbc.patch">
--- 123,138 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p010_cbc">
  <font color="#009000"><strong>010: RELIABILITY FIX: December 20, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  Bring CBC oracle attack countermeasures to hardware crypto accelerator land.
  This fixes aes-ni, via xcrypt and various drivers
! (<a href="http://man.openbsd.org/OpenBSD-4.7/glxsb.4">glxsb(4)</a>,
! <a href="http://man.openbsd.org/OpenBSD-4.7/hifn.4">hifn(4)</a>,
! <a href="http://man.openbsd.org/OpenBSD-4.7/safe.4">safe(4)</a>
  and
! <a href="http://man.openbsd.org/OpenBSD-4.7/ubsec.4">ubsec(4)</a>).
  
  <br>
  <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.7/common/010_cbc.patch">
***************
*** 140,146 ****
  <p>
  
  
! <li id="009_pf">
  <font color="#009000"><strong>009: SECURITY FIX: December 17, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  Insufficent initialization of the pf rule structure in the ioctl
--- 140,146 ----
  <p>
  
  
! <li id="p009_pf">
  <font color="#009000"><strong>009: SECURITY FIX: December 17, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  Insufficent initialization of the pf rule structure in the ioctl
***************
*** 151,157 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="008_openssl">
  <font color="#009000"><strong>008: RELIABILITY FIX: November 17, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  Fix a flaw in the OpenSSL TLS server extension code parsing which could lead to
--- 151,157 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p008_openssl">
  <font color="#009000"><strong>008: RELIABILITY FIX: November 17, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  Fix a flaw in the OpenSSL TLS server extension code parsing which could lead to
***************
*** 163,169 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="007_scsi">
  <font color="#009000"><strong>007: RELIABILITY FIX: September 14, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  Avoid calling scsi_done() more than once in gdt(4). Fixes a kernel panic triggered by syncing disks during shut down.<br>
--- 163,169 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p007_scsi">
  <font color="#009000"><strong>007: RELIABILITY FIX: September 14, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  Avoid calling scsi_done() more than once in gdt(4). Fixes a kernel panic triggered by syncing disks during shut down.<br>
***************
*** 173,179 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="006_scsi">
  <font color="#009000"><strong>006: RELIABILITY FIX: July 8, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  Restore an unusual XS_SENSE semantic. Fixes dump(8)/restore(8) problems seen on certain tape drives.
--- 173,179 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p006_scsi">
  <font color="#009000"><strong>006: RELIABILITY FIX: July 8, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  Restore an unusual XS_SENSE semantic. Fixes dump(8)/restore(8) problems seen on certain tape drives.
***************
*** 182,188 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="005_pfsync">
  <font color="#009000"><strong>005: RELIABILITY FIX: May 14, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  Incorrectly initialized state updates can cause pfsync update storms.
--- 182,188 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p005_pfsync">
  <font color="#009000"><strong>005: RELIABILITY FIX: May 14, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  Incorrectly initialized state updates can cause pfsync update storms.
***************
*** 191,197 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="004_pfsync">
  <font color="#009000"><strong>004: SECURITY FIX: April 23, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  The combination of pfsync and IPSEC may crash the kernel.<br>
--- 191,197 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p004_pfsync">
  <font color="#009000"><strong>004: SECURITY FIX: April 23, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  The combination of pfsync and IPSEC may crash the kernel.<br>
***************
*** 199,205 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="003_openssl">
  <font color="#009000"><strong>003: SECURITY FIX: April 14, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  In TLS connections, certain incorrectly formatted records can cause
--- 199,205 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p003_openssl">
  <font color="#009000"><strong>003: SECURITY FIX: April 14, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  In TLS connections, certain incorrectly formatted records can cause
***************
*** 209,219 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="002_mpi">
  <font color="#009000"><strong>002: 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
--- 209,219 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p002_mpi">
  <font color="#009000"><strong>002: 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.7/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
***************
*** 224,230 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="001_kerberos">
  <font color="#009000"><strong>001: RELIABILITY FIX: March 31, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  When decrypting packets, the internal decryption functions were not
--- 224,230 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  
! <li id="p001_kerberos">
  <font color="#009000"><strong>001: RELIABILITY FIX: March 31, 2010</strong></font>
  &nbsp; <i>All architectures</i><br>
  When decrypting packets, the internal decryption functions were not