===================================================================
RCS file: /cvsrepo/anoncvs/cvs/www/errata24.html,v
retrieving revision 1.46
retrieving revision 1.47
diff -c -r1.46 -r1.47
*** www/errata24.html	2010/03/08 21:53:37	1.46
--- www/errata24.html	2010/07/08 19:00:07	1.47
***************
*** 53,59 ****
  <br>
  <hr>
  
! <a href="ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.4.tar.gz">
  You can also fetch a tar.gz file containing all the following patches</a>.
  This file is updated once a day.
  
--- 53,59 ----
  <br>
  <hr>
  
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4.tar.gz">
  You can also fetch a tar.gz file containing all the following patches</a>.
  This file is updated once a day.
  
***************
*** 69,106 ****
  <font color="#009000"><strong>RELIABILITY FIX</strong></font><br>
  A local user can crash the system by reading a file larger than 64meg
  from an ext2fs partition.
! <a href="ftp://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><br>
  A local user can crash the system because of a bug in the vfs layer.
! <a href="ftp://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><br>
  A machine crash is possible when playing with poll(2).
! <a href="ftp://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><br>
  A machine crash is possible when playing with link(2) on FFS.
! <a href="ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/nlink.patch">
  A source code patch exists which remedies this problem.  This
  is version four of the patch.</a>
  <p>
  <li><a name="ping"></a>
  <font color="#009000"><strong>SECURITY FIX</strong></font><br>
  A buffer overflow existed in ping(8), which may have a security issue.
! <a href="ftp://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><br>
  A race condition in IP ipq handling could permit a remote crash.
! <a href="ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/ipqrace.patch">
  A source code patch exists which remedies this problem.</a>
  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>.
--- 69,106 ----
  <font color="#009000"><strong>RELIABILITY FIX</strong></font><br>
  A local user can crash the system by reading a file larger than 64meg
  from an ext2fs partition.
! <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><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><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><br>
  A machine crash is possible when playing with link(2) on FFS.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/nlink.patch">
  A source code patch exists which remedies this problem.  This
  is version four of the patch.</a>
  <p>
  <li><a name="ping"></a>
  <font color="#009000"><strong>SECURITY FIX</strong></font><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><br>
  A race condition in IP ipq handling could permit a remote crash.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/ipqrace.patch">
  A source code patch exists which remedies this problem.</a>
  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>.
***************
*** 109,141 ****
  <font color="#009000"><strong>SECURITY FIX</strong></font><br>
  A race condition existed between accept(2) and select(2) which could
  permit an attacker to hang sockets from remote.
! <a href="ftp://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><br>
  IP fragment assembly can bog the machine excessively and cause problems.
! <a href="ftp://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><br>
  The readv(2) and writev(2) system calls would not accept a <em>struct iovec</em>
  with an <strong>iov_len</strong> of 0.  This causes a db test in perl to fail.
! <a href="ftp://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><br>
  TCP/IP RST handling was too sloppy.
! <a href="ftp://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><br>
  During bootup, kvm_mkdb may exit with the error "kvm_mkdb: cannot allocate
  memory".  
! <a href="ftp://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>
--- 109,141 ----
  <font color="#009000"><strong>SECURITY FIX</strong></font><br>
  A race condition existed between accept(2) and select(2) which could
  permit an attacker to hang sockets from remote.
! <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><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><br>
  The readv(2) and writev(2) system calls would not accept a <em>struct iovec</em>
  with an <strong>iov_len</strong> of 0.  This causes a db test in perl to fail.
! <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><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><br>
  During bootup, kvm_mkdb may exit with the error "kvm_mkdb: cannot allocate
  memory".  
! <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>
***************
*** 143,149 ****
  A problem with writing to NFS version 3 mounted filesystems from Solaris 7
  hosts exists.  Attempts to create files will result in an error such as
  "Inappropriate file type or format".
! <a href="ftp://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>
--- 143,149 ----
  A problem with writing to NFS version 3 mounted filesystems from Solaris 7
  hosts exists.  Attempts to create files will result in an error such as
  "Inappropriate file type or format".
! <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>
***************
*** 152,204 ****
  and powerpc) exists when mounting filesystems larger than 2gig.  You
  can see evidence of the bug by running df(1) and checking for negative
  partition sizes.
! <a href="ftp://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><br>
  A security problem exists in the curses and ocurses libraries that affect
  setuid programs linked with -lcurses or -locurses.
! <a href="ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/termcap.patch">
  A source code patch exists which remedies this problem.</a>
  <br>
  Precompiled versions of libcurses and libocurses exist for the
! <a href="ftp://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><br>
  A workaround for an xterm problem that causes <strong>vi</strong> to not
  restore the correct cursor position on exit.
! <a href="ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/terminfo.src.patch">
  A source code patch exists which remedies this problem.</a>
  <br>
  Alternately, you can also download a pre-compiled terminfo file to be
  installed as <strong>/usr/share/misc/terminfo.db</strong>.  For i386,
  alpha and mips, use the
! <a href="ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/terminfo.db-LE.tar.gz">
  little endian</a> version.  For sparc, m68k and powerpc, use the
! <a href="ftp://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><br>
  <strong>userdir</strong> support was accidentally left out of httpd(8).
! <a href="ftp://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><br>
  A remotely exploitable problem exists in bootpd(8).  bootpd is disabled
  by default, but some people may actually be using it.
! <a href="ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/bootpd.patch">
  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><br>
  A remote machine lockup problem exists in the TCP decoding code.
! <a href="ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/tcpfix.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  </ul>
--- 152,204 ----
  and powerpc) exists when mounting filesystems larger than 2gig.  You
  can see evidence of the bug by running df(1) and checking for negative
  partition sizes.
! <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><br>
  A security problem exists in the curses and ocurses libraries that affect
  setuid programs linked with -lcurses or -locurses.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/termcap.patch">
  A source code patch exists which remedies this problem.</a>
  <br>
  Precompiled versions of libcurses and libocurses exist for the
! <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><br>
  A workaround for an xterm problem that causes <strong>vi</strong> to not
  restore the correct cursor position on exit.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/terminfo.src.patch">
  A source code patch exists which remedies this problem.</a>
  <br>
  Alternately, you can also download a pre-compiled terminfo file to be
  installed as <strong>/usr/share/misc/terminfo.db</strong>.  For i386,
  alpha and mips, use the
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/terminfo.db-LE.tar.gz">
  little endian</a> version.  For sparc, m68k and powerpc, use the
! <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><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><br>
  A remotely exploitable problem exists in bootpd(8).  bootpd is disabled
  by default, but some people may actually be using it.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/bootpd.patch">
  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><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>
  </ul>
***************
*** 209,215 ****
  <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="ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.4/i386/tss.patch">
  A source code patch exists which remedies this problem.</a><br>
  <p>
  <li><a name="bootargv"></a>
--- 209,215 ----
  <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><br>
  <p>
  <li><a name="bootargv"></a>
***************
*** 221,241 ****
  stage.  In 2.5, the bootblocks will be modified to use a new location.
  Hence, if you wish old kernels to boot on a new bootblock, those
  kernels will only work if they were linked with this patch.
! <a href="ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.4/i386/bootargv.patch">
  A source code patch exists which remedies this problem.</a><br>
  <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="ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.4/i386/trctrap.patch">
  A source code patch exists which remedies this problem.</a><br>
  <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.
! <a href="ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.4/i386/installboot.patch">
  A source code patch exists which remedies this problem.</a><br>
  Unfortunately, updated 2.4 install floppies are not available.  Just ensure
  that your root filesystem is below 4GB, for now.
--- 221,241 ----
  stage.  In 2.5, the bootblocks will be modified to use a new location.
  Hence, if you wish old kernels to boot on a new bootblock, those
  kernels will only work if they were linked with this patch.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/i386/bootargv.patch">
  A source code patch exists which remedies this problem.</a><br>
  <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><br>
  <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.
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.4/i386/installboot.patch">
  A source code patch exists which remedies this problem.</a><br>
  Unfortunately, updated 2.4 install floppies are not available.  Just ensure
  that your root filesystem is below 4GB, for now.
***************
*** 256,269 ****
  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
  bursting.  No sun4m machines support that.
! <a href="ftp://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="ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.4/sparc/le.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  </ul>
--- 256,269 ----
  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
  bursting.  No sun4m machines support that.
! <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>
  </ul>
***************
*** 354,360 ****
  <hr>
  <a href=index.html><img height=24 width=24 src=back.gif border=0 alt=OpenBSD></a> 
  <a href="mailto:www@openbsd.org">www@openbsd.org</a>
! <br><small>$OpenBSD: errata24.html,v 1.46 2010/03/08 21:53:37 deraadt Exp $</small>
  
  </body>
  </html>
--- 354,360 ----
  <hr>
  <a href=index.html><img height=24 width=24 src=back.gif border=0 alt=OpenBSD></a> 
  <a href="mailto:www@openbsd.org">www@openbsd.org</a>
! <br><small>$OpenBSD: errata24.html,v 1.47 2010/07/08 19:00:07 sthen Exp $</small>
  
  </body>
  </html>