===================================================================
RCS file: /cvsrepo/anoncvs/cvs/www/errata24.html,v
retrieving revision 1.83
retrieving revision 1.84
diff -u -r1.83 -r1.84
--- www/errata24.html	2019/05/27 22:55:19	1.83
+++ www/errata24.html	2019/05/28 16:32:41	1.84
@@ -84,126 +84,158 @@
 <hr>
 
 <ul>
+
 <li id="bmap">
-<strong>RELIABILITY FIX</strong>
+<strong>001: RELIABILITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 A local user can crash the system by reading a file larger than 64meg
 from an ext2fs partition.
+<br>
 <a href="https://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">
-<strong>RELIABILITY FIX</strong>
+<strong>002: RELIABILITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 A local user can crash the system because of a bug in the vfs layer.
+<br>
 <a href="https://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">
-<strong>SECURITY FIX</strong>
+<strong>003: SECURITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 A machine crash is possible when playing with poll(2).
+<br>
 <a href="https://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">
-<strong>SECURITY FIX</strong>
+<strong>004: SECURITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 A machine crash is possible when playing with link(2) on FFS.
+<br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/nlink.patch">
 A source code patch exists which remedies this problem.</a>
 This is version four of the patch.
 <p>
+
 <li id="ping">
-<strong>SECURITY FIX</strong>
+<strong>005: SECURITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 A buffer overflow existed in ping(8), which may have a security issue.
+<br>
 <a href="https://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">
-<strong>SECURITY FIX</strong>
+<strong>006: SECURITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 A race condition in IP ipq handling could permit a remote crash.
+<br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/ipqrace.patch">
 A source code patch exists which remedies this problem.</a>
+<br>
 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">
-<strong>SECURITY FIX</strong>
+<strong>007: SECURITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 A race condition existed between accept(2) and select(2) which could
 permit an attacker to hang sockets from remote.
+<br>
 <a href="https://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">
-<strong>SECURITY FIX</strong>
+<strong>008: SECURITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 IP fragment assembly can bog the machine excessively and cause problems.
+<br>
 <a href="https://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">
-<strong>FUNCTIONALITY FIX</strong>
+<strong>009: FUNCTIONALITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 The readv(2) and writev(2) system calls would not accept a <em>struct iovec</em>
 with an <b>iov_len</b> of 0.  This causes a db test in perl to fail.
+<br>
 <a href="https://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">
-<strong>SECURITY FIX</strong>
+<strong>010: SECURITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 TCP/IP RST handling was too sloppy.
+<br>
 <a href="https://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">
-<strong>FUNCTIONALITY FIX</strong>
+<strong>011: FUNCTIONALITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 During bootup, kvm_mkdb may exit with the error "kvm_mkdb: cannot allocate
 memory".
+<br>
 <a href="https://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">
-<strong>FUNCTIONALITY FIX</strong>
+<strong>012: FUNCTIONALITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 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".
+<br>
 <a href="https://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">
-<strong>FUNCTIONALITY FIX</strong>
+<strong>013: FUNCTIONALITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 A problem with NFS version 3 mounts on big endian machines (m68k, sparc
 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.
+<br>
 <a href="https://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">
-<strong>SECURITY FIX</strong>
+<strong>014: SECURITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 A security problem exists in the curses and ocurses libraries that affect
 setuid programs linked with -lcurses or -locurses.
+<br>
 <a href="https://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
+<br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.4/i386/curses.tar.gz">i386</a>
 platform.  Unpack it in /usr/lib.
 <p>
+
 <li id="terminfo">
-<strong>FUNCTIONALITY FIX</strong>
+<strong>015: FUNCTIONALITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 A workaround for an xterm problem that causes <b>vi</b> to not
 restore the correct cursor position on exit.
+<br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/terminfo.src.patch">
 A source code patch exists which remedies this problem.</a>
 <br>
@@ -215,38 +247,47 @@
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.4/common/terminfo.db-BE.tar.gz">
 big endian</a> version.
 <p>
+
 <li id="userdir">
-<strong>FUNCTIONALITY FIX</strong>
+<strong>016: FUNCTIONALITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 <b>userdir</b> support was accidentally left out of httpd(8).
+<br>
 <a href="https://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">
-<strong>SECURITY FIX</strong>
+<strong>017: SECURITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 A remotely exploitable problem exists in bootpd(8).  bootpd is disabled
 by default, but some people may actually be using it.
+<br>
 <a href="https://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 id="tcpfix">
-<strong>SECURITY FIX</strong>
+<strong>018: SECURITY FIX</strong>
 &nbsp; <i>All architectures</i><br>
 A remote machine lockup problem exists in the TCP decoding code.
+<br>
 <a href="https://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">
-<strong>SECURITY FIX</strong><br>
+<strong>019: SECURITY FIX</strong><br>
 This is another fix for a kernel crash caused by the
 <b>crashme</b> program.
+<br>
 <a href="https://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">
-<strong>FUNCTIONALITY FIX</strong><br>
+<strong>020: FUNCTIONALITY FIX</strong><br>
 The kernel was using a fixed and hard-coded location for the arguments
 vector passed from the <b>/boot</b> loader.  This prevented
 <b>/boot</b> from placing the boot arguments vector at any
@@ -254,42 +295,52 @@
 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.
+<br>
 <a href="https://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">
-<strong>SECURITY FIX</strong><br>
+<strong>021: SECURITY FIX</strong><br>
 i386 trace-trap handling when DDB was configured could cause a system
 crash.
+<br>
 <a href="https://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">
-<strong>FUNCTIONALITY FIX</strong><br>
+<strong>022: FUNCTIONALITY FIX</strong><br>
 i386 installboot had a sign extension bug which prevented proper bootblock
 initialization when the root filesystem was placed beyond 4GB.
+<br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.4/i386/installboot.patch">
 A source code patch exists which remedies this problem.</a>
 Unfortunately, updated 2.4 install floppies are not available.  Just ensure
 that your root filesystem is below 4GB, for now.
 <p>
+
 <li id="hme">
-<strong>DRIVER FIX</strong><br>
+<strong>023: DRIVER FIX</strong><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
 bursting.  No sun4m machines support that.
+<br>
 <a href="https://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">
-<strong>DRIVER FIX</strong><br>
+<strong>024: DRIVER FIX</strong><br>
 The sparc le(4) driver does media changes incorrectly on one type of
 sbus le(4) card.
+<br>
 <a href="https://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">
-<strong>FUNCTIONALITY FIX</strong><br>
+<strong>025: FUNCTIONALITY FIX</strong><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.
 <p>