===================================================================
RCS file: /cvsrepo/anoncvs/cvs/www/errata24.html,v
retrieving revision 1.64
retrieving revision 1.65
diff -c -r1.64 -r1.65
*** www/errata24.html	2014/10/02 14:34:45	1.64
--- www/errata24.html	2015/02/14 04:36:51	1.65
***************
*** 81,87 ****
  <hr>
  
  <ul>
! <li><a name="bmap"></a>
  <font color="#009000"><strong>RELIABILITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A local user can crash the system by reading a file larger than 64meg
--- 81,87 ----
  <hr>
  
  <ul>
! <li id="bmap">
  <font color="#009000"><strong>RELIABILITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A local user can crash the system by reading a file larger than 64meg
***************
*** 89,109 ****
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/bmap.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="lnpanic"></a>
  <font color="#009000"><strong>RELIABILITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A local user can crash the system because of a bug in the vfs layer.
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/lnpanic.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="poll"></a>
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A machine crash is possible when playing with poll(2).
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/poll.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="nlink"></a>
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A machine crash is possible when playing with link(2) on FFS.
--- 89,109 ----
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/bmap.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="lnpanic">
  <font color="#009000"><strong>RELIABILITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A local user can crash the system because of a bug in the vfs layer.
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/lnpanic.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="poll">
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A machine crash is possible when playing with poll(2).
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/poll.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="nlink">
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A machine crash is possible when playing with link(2) on FFS.
***************
*** 111,124 ****
  A source code patch exists which remedies this problem.</a>
  This is version four of the patch.
  <p>
! <li><a name="ping"></a>
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A buffer overflow existed in ping(8), which may have a security issue.
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/ping.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="ipqrace"></a>
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A race condition in IP ipq handling could permit a remote crash.
--- 111,124 ----
  A source code patch exists which remedies this problem.</a>
  This is version four of the patch.
  <p>
! <li id="ping">
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A buffer overflow existed in ping(8), which may have a security issue.
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/ping.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="ipqrace">
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A race condition in IP ipq handling could permit a remote crash.
***************
*** 127,133 ****
  It must be installed after <a href="errata24.html#maxqueue">the maxqueue patch</a>.
  and <a href="errata24.html#tcpfix">the tcp decoding patch</a>.
  <p>
! <li><a name="accept"></a>
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A race condition existed between accept(2) and select(2) which could
--- 127,133 ----
  It must be installed after <a href="errata24.html#maxqueue">the maxqueue patch</a>.
  and <a href="errata24.html#tcpfix">the tcp decoding patch</a>.
  <p>
! <li id="accept">
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A race condition existed between accept(2) and select(2) which could
***************
*** 135,148 ****
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/accept.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="maxqueue"></a>
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  IP fragment assembly can bog the machine excessively and cause problems.
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/maxqueue.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="uio"></a>
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  The readv(2) and writev(2) system calls would not accept a <em>struct iovec</em>
--- 135,148 ----
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/accept.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="maxqueue">
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  IP fragment assembly can bog the machine excessively and cause problems.
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/maxqueue.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="uio">
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  The readv(2) and writev(2) system calls would not accept a <em>struct iovec</em>
***************
*** 150,163 ****
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/uio.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="rst"></a>
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  TCP/IP RST handling was too sloppy.
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/rst.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="kvm_mkdb"></a>
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  During bootup, kvm_mkdb may exit with the error "kvm_mkdb: cannot allocate
--- 150,163 ----
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/uio.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="rst">
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  TCP/IP RST handling was too sloppy.
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/rst.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="kvm_mkdb">
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  During bootup, kvm_mkdb may exit with the error "kvm_mkdb: cannot allocate
***************
*** 165,171 ****
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/kvm_mkdb.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="nfs3_solaris7"></a>
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A problem with writing to NFS version 3 mounted filesystems from Solaris 7
--- 165,171 ----
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/kvm_mkdb.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="nfs3_solaris7">
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A problem with writing to NFS version 3 mounted filesystems from Solaris 7
***************
*** 174,180 ****
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/nfs3_solaris7.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="nfs3"></a>
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A problem with NFS version 3 mounts on big endian machines (m68k, sparc
--- 174,180 ----
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/nfs3_solaris7.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="nfs3">
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A problem with NFS version 3 mounts on big endian machines (m68k, sparc
***************
*** 184,190 ****
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/nfs3.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="termcap"></a>
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A security problem exists in the curses and ocurses libraries that affect
--- 184,190 ----
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/nfs3.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="termcap">
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A security problem exists in the curses and ocurses libraries that affect
***************
*** 196,202 ****
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/i386/curses.tar.gz">i386</a>
  platform.  Unpack it in /usr/lib.
  <p>
! <li><a name="terminfo"></a>
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A workaround for an xterm problem that causes <strong>vi</strong> to not
--- 196,202 ----
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/i386/curses.tar.gz">i386</a>
  platform.  Unpack it in /usr/lib.
  <p>
! <li id="terminfo">
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A workaround for an xterm problem that causes <strong>vi</strong> to not
***************
*** 212,225 ****
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/terminfo.db-BE.tar.gz">
  big endian</a> version.
  <p>
! <li><a name="userdir"></a>
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  <strong>userdir</strong> support was accidentally left out of httpd(8).
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/userdir.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="bootpd"></a>
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A remotely exploitable problem exists in bootpd(8).  bootpd is disabled
--- 212,225 ----
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/terminfo.db-BE.tar.gz">
  big endian</a> version.
  <p>
! <li id="userdir">
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  <strong>userdir</strong> support was accidentally left out of httpd(8).
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/userdir.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="bootpd">
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A remotely exploitable problem exists in bootpd(8).  bootpd is disabled
***************
*** 228,248 ****
  A source code patch exists which remedies this problem.</a>
  This is the second version of the patch.
  <p>
! <li><a name="tcpfix"></a>
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A remote machine lockup problem exists in the TCP decoding code.
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/tcpfix.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="tss"></a>
  <font color="#009000"><strong>SECURITY FIX</strong></font><br>
  This is another fix for a kernel crash caused by the
  <strong>crashme</strong> program.
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/i386/tss.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="bootargv"></a>
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font><br>
  The kernel was using a fixed and hard-coded location for the arguments
  vector passed from the <strong>/boot</strong> loader.  This prevented
--- 228,248 ----
  A source code patch exists which remedies this problem.</a>
  This is the second version of the patch.
  <p>
! <li id="tcpfix">
  <font color="#009000"><strong>SECURITY FIX</strong></font>
  &nbsp; <i>All architectures</i><br>
  A remote machine lockup problem exists in the TCP decoding code.
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/tcpfix.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="tss">
  <font color="#009000"><strong>SECURITY FIX</strong></font><br>
  This is another fix for a kernel crash caused by the
  <strong>crashme</strong> program.
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/i386/tss.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="bootargv">
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font><br>
  The kernel was using a fixed and hard-coded location for the arguments
  vector passed from the <strong>/boot</strong> loader.  This prevented
***************
*** 254,267 ****
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/i386/bootargv.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="trctrap"></a>
  <font color="#009000"><strong>SECURITY FIX</strong></font><br>
  i386 trace-trap handling when DDB was configured could cause a system
  crash.
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/i386/trctrap.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="installboot"></a>
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font><br>
  i386 installboot had a sign extension bug which prevented proper bootblock
  initialization when the root filesystem was placed beyond 4GB.
--- 254,267 ----
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/i386/bootargv.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="trctrap">
  <font color="#009000"><strong>SECURITY FIX</strong></font><br>
  i386 trace-trap handling when DDB was configured could cause a system
  crash.
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/i386/trctrap.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="installboot">
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font><br>
  i386 installboot had a sign extension bug which prevented proper bootblock
  initialization when the root filesystem was placed beyond 4GB.
***************
*** 270,276 ****
  Unfortunately, updated 2.4 install floppies are not available.  Just ensure
  that your root filesystem is below 4GB, for now.
  <p>
! <li><a name="hme"></a>
  <font color="#009000"><strong>DRIVER FIX</strong></font><br>
  The sparc hme(4) and be(4) drivers work poorly on some types of SS-20
  machines.  This is because those machines lie, saying they support 64-bit DMA
--- 270,276 ----
  Unfortunately, updated 2.4 install floppies are not available.  Just ensure
  that your root filesystem is below 4GB, for now.
  <p>
! <li id="hme">
  <font color="#009000"><strong>DRIVER FIX</strong></font><br>
  The sparc hme(4) and be(4) drivers work poorly on some types of SS-20
  machines.  This is because those machines lie, saying they support 64-bit DMA
***************
*** 278,291 ****
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/sparc/hme.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="le"></a>
  <font color="#009000"><strong>DRIVER FIX</strong></font><br>
  The sparc le(4) driver does media changes incorrectly on one type of
  sbus le(4) card.
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/sparc/le.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li><a name="hp300X"></a>
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font><br>
  The Xhp as shipped does not have the execute permissions set.  The fix is
  'chmod 755 /usr/X11R6/bin/Xhp' if you have installed X.
--- 278,291 ----
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/sparc/hme.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="le">
  <font color="#009000"><strong>DRIVER FIX</strong></font><br>
  The sparc le(4) driver does media changes incorrectly on one type of
  sbus le(4) card.
  <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/sparc/le.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
! <li id="hp300X">
  <font color="#009000"><strong>FUNCTIONALITY FIX</strong></font><br>
  The Xhp as shipped does not have the execute permissions set.  The fix is
  'chmod 755 /usr/X11R6/bin/Xhp' if you have installed X.