article.xml revision 112477
176082Sbmah<!-- 276082Sbmah FreeBSD errata document. Unlike some of the other RELNOTESng 376082Sbmah files, this file should remain as a single SGML file, so that 476082Sbmah the dollar FreeBSD dollar header has a meaningful modification 576082Sbmah time. This file is all but useless without a datestamp on it, 676082Sbmah so we'll take some extra care to make sure it has one. 776082Sbmah 876082Sbmah (If we didn't do this, then the file with the datestamp might 976082Sbmah not be the one that received the last change in the document.) 1076082Sbmah 1176082Sbmah--> 1276082Sbmah 1376082Sbmah<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [ 1476082Sbmah<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN"> 1576082Sbmah%man; 1676082Sbmah<!ENTITY % authors PUBLIC "-//FreeBSD//ENTITIES DocBook Author Entities//EN"> 1776082Sbmah%authors; 1876082Sbmah<!ENTITY % mlists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//EN"> 1976082Sbmah%mlists; 2076082Sbmah<!ENTITY % release PUBLIC "-//FreeBSD//ENTITIES Release Specification//EN"> 2176082Sbmah%release; 2276082Sbmah]> 2376082Sbmah 2476082Sbmah<article> 2576082Sbmah <articleinfo> 26109307Sbmah <title>&os; 27109543Sbmah<![ %release.type.snapshot [ 28109543Sbmah &release.prev; 29109543Sbmah]]> 30109543Sbmah<![ %release.type.release [ 31109543Sbmah &release.current; 32109543Sbmah]]> 33109307Sbmah Errata</title> 3477914Sbmah 3576082Sbmah <corpauthor> 3676082Sbmah The &os; Project 3776082Sbmah </corpauthor> 3876082Sbmah 3976082Sbmah <pubdate>$FreeBSD: head/release/doc/en_US.ISO8859-1/errata/article.sgml 112477 2003-03-21 22:31:44Z bmah $</pubdate> 4076082Sbmah 4176082Sbmah <copyright> 4276082Sbmah <year>2000</year> 4376082Sbmah <year>2001</year> 4488820Sbmah <year>2002</year> 45108829Sbmah <year>2003</year> 4676082Sbmah <holder role="mailto:doc@FreeBSD.org">The FreeBSD Documentation Project</holder> 4776082Sbmah </copyright> 4876082Sbmah </articleinfo> 4976082Sbmah 5077914Sbmah <abstract> 5179807Sbmah <para>This document lists errata items for &os; 52109543Sbmah<![ %release.type.snapshot [ 53109543Sbmah &release.prev;, 54109543Sbmah]]> 55109543Sbmah<![ %release.type.release [ 56109543Sbmah &release.current;, 57109543Sbmah]]> 5892295Sbmah containing significant information discovered after the release. 5992295Sbmah This information includes security advisories, as well as news 6092295Sbmah relating to the software or documentation that could affect its 6192295Sbmah operation or usability. An up-to-date version of this document 6292295Sbmah should always be consulted before installing this version of 6392295Sbmah &os;.</para> 6477914Sbmah 65109307Sbmah <para>This errata document for &os; 66109543Sbmah<![ %release.type.snapshot [ 67109543Sbmah &release.prev; 68109543Sbmah]]> 69109543Sbmah<![ %release.type.release [ 70109543Sbmah &release.current; 71109543Sbmah]]> 72109308Sbmah will be maintained until the release of &os; 5.1-RELEASE.</para> 7377914Sbmah </abstract> 7477914Sbmah 75109143Sroam <sect1 id="intro"> 7676082Sbmah <title>Introduction</title> 7776082Sbmah 7879807Sbmah <para>This errata document contains <quote>late-breaking news</quote> 7992295Sbmah about &os; 80109543Sbmah<![ %release.type.snapshot [ 81109543Sbmah &release.prev;. 82109543Sbmah]]> 83109543Sbmah<![ %release.type.release [ 84109543Sbmah &release.current;. 85109543Sbmah]]> 8692295Sbmah Before installing this version, it is important to consult this 8792295Sbmah document to learn about any post-release discoveries or problems 8892295Sbmah that may already have been found and fixed.</para> 8979807Sbmah 9092295Sbmah <para>Any version of this errata document actually distributed 9192295Sbmah with the release (for example, on a CDROM distribution) will be 9292295Sbmah out of date by definition, but other copies are kept updated on 9392295Sbmah the Internet and should be consulted as the <quote>current 9492295Sbmah errata</quote> for this release. These other copies of the 9592295Sbmah errata are located at <ulink 9692295Sbmah url="http://www.FreeBSD.org/releases/"></ulink>, plus any sites 9792295Sbmah which keep up-to-date mirrors of this location.</para> 9876082Sbmah 9979807Sbmah <para>Source and binary snapshots of &os; &release.branch; also 10092295Sbmah contain up-to-date copies of this document (as of the time of 10192295Sbmah the snapshot).</para> 10276082Sbmah 10377914Sbmah <para>For a list of all &os; CERT security advisories, see <ulink 10492295Sbmah url="http://www.FreeBSD.org/security/"></ulink> or <ulink 10592295Sbmah url="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/"></ulink>.</para> 10692295Sbmah 10776082Sbmah </sect1> 10876082Sbmah 109109143Sroam <sect1 id="security"> 11076082Sbmah <title>Security Advisories</title> 111109309Sbmah 112110463Sbmah <para>Remotely exploitable vulnerabilities in 113110463Sbmah <application>CVS</application> could allow an attacker to 114110463Sbmah execute arbitrary comands on a CVS server. More details can be 115110463Sbmah found in security advisory <ulink 116110463Sbmah url="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:01.cvs.asc">FreeBSD-SA-03:01</ulink>.</para> 117109309Sbmah 118111435Sbmah <para>A timing-based attack on <application>OpenSSL</application>, 119111435Sbmah could allow a very powerful attacker access to plaintext 120111435Sbmah under certain circumstances. This problem has been corrected in 121111435Sbmah &os; &release.current; with an upgrade 122111435Sbmah to <application>OpenSSL</application> 0.9.7. On supported 123111435Sbmah security fix branches, this problem has been corrected with the 124111435Sbmah import of <application>OpenSSL</application> 0.9.6i. See security 125111435Sbmah advisory <ulink 126111435Sbmah url="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:02.openssl.asc">FreeBSD-SA-03:02</ulink> 127111435Sbmah for more details.</para> 128111435Sbmah 129111435Sbmah <para>It may be possible to recover the shared secret key used by 130111435Sbmah the implementation of the <quote>syncookies</quote> feature. 131111435Sbmah This reduces its effectiveness in dealing with TCP SYN flood 132111435Sbmah denial-of-service attacks. Workaround information and fixes are 133111435Sbmah given in security advisory <ulink 134111435Sbmah url="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:03.syncookies.asc">FreeBSD-SA-03:03</ulink>.</para> 135111435Sbmah 136111835Sbmah <para>Due to a buffer overflow in header parsing in <application>sendmail</application>, a remote 137111835Sbmah attacker can create a specially-crafted message that may cause 138111835Sbmah &man.sendmail.8; to execute arbitrary code 139111835Sbmah with the privileges of the user running it, typically 140111834Sbmah <username>root</username>. More information, including pointers 141111834Sbmah to patches, can be found in security advisory <ulink 142111834Sbmah url="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:04.sendmail.asc">FreeBSD-SA-03:04</ulink>.</para> 143111834Sbmah 144112435Sbmah <para>The XDR encoder/decoder does incorrect bounds-checking, 145112435Sbmah which could allow a remote attacker to cause a 146112435Sbmah denial-of-service. For bugfix information, see security 147112435Sbmah advisory <ulink 148112435Sbmah url="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:05.xdr.asc">FreeBSD-SA-03:05</ulink>.</para> 149112435Sbmah 150112477Sbmah <para><application>OpenSSL</application> has been found 151112477Sbmah vulnerable to two recently-disclosed attacks. Information 152112477Sbmah on workarounds and patches for supported security branches is 153112477Sbmah contained in security advisory <ulink 154112477Sbmah url="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:06.openssl.asc">FreeBSD-SA-03:06</ulink>.</para> 155112477Sbmah 15676082Sbmah </sect1> 15776082Sbmah 158109309Sbmah <sect1 id="late-news"> 159109309Sbmah <title>Late-Breaking News</title> 160109309Sbmah 161109583Schris <bridgehead renderas="sect3">GEOM</bridgehead> 162109583Schris 163109309Sbmah <para>The &man.geom.4;-based disk partitioning code in the kernel 164109309Sbmah will not allow an open partition to be overwritten. This 165109309Sbmah usually prevents the use of <command>disklabel -B</command> to 166109309Sbmah update the boot blocks on a disk because the 167109309Sbmah <literal>a</literal> partition overlaps the space where the boot 168109309Sbmah blocks are stored. A suggested workaround is to boot from an 169109309Sbmah alternate disk, a CDROM, or a fixit floppy.</para> 170109309Sbmah 171109583Schris <bridgehead renderas="sect3">&man.dump.8;</bridgehead> 172109583Schris 173109309Sbmah <para>When using disk media with sector sizes larger than 512 174109309Sbmah bytes (for instance, &man.gbde.4; encrypted disks), the 175109309Sbmah &man.dump.8; program fails to respect the larger sector size and 176109309Sbmah cannot dump the partition. One possible workaround is to copy 177109309Sbmah the entire file system in raw format and dump the copy. It is, 178109309Sbmah for instance, possible to dump a file system stored in a regular 179109309Sbmah file:</para> 180109309Sbmah 181109309Sbmah <screen>&prompt.root; <userinput>dd if=/dev/ad0s1d.bde of=/junk/ad0.dd bs=1m</userinput> 182109309Sbmah&prompt.root; <userinput>dump 0f - /junk/ad0.dd | ...</userinput></screen> 183109309Sbmah 184109309Sbmah <para>A simpler workaround is to use &man.tar.1; or &man.cpio.1; 185109309Sbmah to make backup copies.</para> 186109309Sbmah 187109583Schris <bridgehead renderas="sect3">&man.mly.4;</bridgehead> 188109583Schris 189110514Sbmah <para>Hangs were reported during &os; 5.0 snapshot 190109309Sbmah installations when installing to &man.mly.4;-supported RAID 191109309Sbmah arrays, in hardware configurations that appear to work fine 192110514Sbmah under &os; 4.7-RELEASE. These problems have been corrected 193110514Sbmah in &os; &release.current;.</para> 194109309Sbmah 195109583Schris <bridgehead renderas="sect3">NETNCP/Netware File System 196109583Schris Support</bridgehead> 197109583Schris 198109309Sbmah <para>NETNCP and nwfs appear to be as-yet unadapted for KSE, and 199111706Sbmah hence not working. These have been fixed in &os; 200111706Sbmah &release.current;.</para> 201109309Sbmah 202109583Schris <bridgehead renderas="sect3">&man.iir.4; controller</bridgehead> 203109583Schris 204109309Sbmah <para>During installation, the &man.iir.4; controller appears to 205109309Sbmah probe correctly, but finds no disk devices.</para> 206109309Sbmah 207109583Schris <bridgehead renderas="sect3">&man.truss.1; race condition</bridgehead> 208109583Schris 209109309Sbmah <para>&man.truss.1; appears to contain a race condition during the 210109309Sbmah start-up of debugging, which can result in &man.truss.1; failing 211109309Sbmah to attach to the process before it exists. The symptom is that 212109309Sbmah &man.truss.1; reports that it cannot open the &man.procfs.5; 213109309Sbmah node supporting the process being debugged. A bug also appears 214109309Sbmah to exist wherein &man.truss.1; will hang if &man.execve.2; 215109309Sbmah returns <literal>ENOENT</literal> A further race appears to 216109309Sbmah exist in which &man.truss.1; will return <errorname>PIOCWAIT: 217109309Sbmah Input/output error</errorname> occasionally on startup. The fix 218109309Sbmah for this sufficiently changes process execution handling that it 219109309Sbmah has been deferred until after 5.0.</para> 220109309Sbmah 221109583Schris <bridgehead renderas="sect3">Disk Partitioning in Installer</bridgehead> 222109583Schris 223109309Sbmah <para>Some bugs have been reported in &man.sysinstall.8; disk 224109309Sbmah partitioning. One observed problem on the i386 is that 225109309Sbmah &man.sysinstall.8; cannot recalculate the free space left on a 226109309Sbmah disk after changing the type of an FDISK-type partition.</para> 227109309Sbmah 228109583Schris <bridgehead renderas="sect3">Stale Documentation</bridgehead> 229109583Schris 230109309Sbmah <para>In some case, documentation (such as the FAQ or Handbook) 231109543Sbmah has not been updated to take into account &os; &release.prev; 232109309Sbmah features. Examples of areas where documentation is still 233109309Sbmah needed include &man.gbde.8; and the new <quote>fast 234109309Sbmah IPsec</quote> implementation.</para> 235109309Sbmah 236109583Schris <bridgehead renderas="sect3">SMB File System</bridgehead> 237109583Schris 238109338Sbmah <para>Attempting to unmount smbfs shares may fail with 239109338Sbmah <errorname>Device busy</errorname> errors even when the 240109338Sbmah mount-point is not really busy. A workaround is to keep trying 241109338Sbmah to unmount the share until it eventually succeeds. This bug has 242109543Sbmah been fixed in &release.current;.</para> 243109338Sbmah 244109338Sbmah <para>Forcefully unmounting (<command>umount -f</command>) smbfs 245109338Sbmah shares may cause a kernel panic. This bug has been fixed in 246109543Sbmah &release.current;.</para> 247109338Sbmah 248109583Schris <bridgehead renderas="sect3">&man.fstat.2;</bridgehead> 249109583Schris 250109338Sbmah <para>When called on a connected socket file descriptor, 251109338Sbmah &man.fstat.2; is supposed to return the number of bytes 252109338Sbmah available to read in the <varname>st_size</varname> member of 253109338Sbmah <varname>struct stat</varname>. However, 254109338Sbmah <varname>st_size</varname> is always erroneously reported as 255109338Sbmah <literal>0</literal> on TCP sockets. This bug has been fixed in 256109543Sbmah &release.current;.</para> 257109338Sbmah 258109583Schris <bridgehead renderas="sect3">Kernel Event Queues</bridgehead> 259109583Schris 260109338Sbmah <para>The &man.kqueue.2; <literal>EVFILT_READ</literal> filter 261109338Sbmah erroneously indicates that <literal>0</literal> bytes are 262109338Sbmah available to be read on TCP sockets, regardless of the number of 263109338Sbmah bytes that are actually available. The 264109338Sbmah <literal>NOTE_LOWAT</literal> flag for 265109338Sbmah <literal>EVFILT_READ</literal> is also broken on TCP sockets. 266109543Sbmah This bug has been fixed in &release.current;.</para> 267109338Sbmah 268109583Schris <bridgehead renderas="sect3">POSIX Named Semaphores</bridgehead> 269109583Schris 270109543Sbmah <para>&os; &release.prev; introduced support for POSIX named semaphores 271109338Sbmah but the implementation contains a critical bug that causes 272109338Sbmah &man.sem.open.3; to incorrectly handle the opening of the same 273109338Sbmah semaphore multiple times by the same process, and that causes 274109338Sbmah &man.sem.close.3; to crash calling programs. This bug has been 275109543Sbmah fixed in &release.current;.</para> 276109338Sbmah 277109583Schris <bridgehead renderas="sect3"><filename>/dev/tty</filename> 278109583Schris Permissions</bridgehead> 279109583Schris 280109543Sbmah <para>&os; &release.prev; has a minor bug in how the permissions of 281109339Sbmah <filename>/dev/tty</filename> are handled. This can be 282109339Sbmah triggered by logging in as a non-<username>root</username>, 283109339Sbmah non-<groupname>tty</groupname> group user, and using &man.su.1; 284109339Sbmah to switch to a second non-<username>root</username>, 285109339Sbmah non-<groupname>tty</groupname> group user. &man.ssh.1; will 286109339Sbmah fail because it cannot open <filename>/dev/tty</filename>. This 287109543Sbmah bug has been fixed in &release.current;.</para> 288109339Sbmah 289109583Schris <bridgehead renderas="sect3">&man.growfs.8;</bridgehead> 290109583Schris 291109400Sbmah <para>&man.growfs.8; no longer works on &man.vinum.4; volumes (and 292109400Sbmah presumably, on &man.geom.4; entities) since these subsystems no 293109400Sbmah longer fake disklabels, but &man.growfs.8; insists on examining 294109400Sbmah a label.</para> 295109400Sbmah 296109612Sbmah <bridgehead renderas="sect3">IPFW</bridgehead> 297109612Sbmah 298109612Sbmah <para>&man.ipfw.4; <literal>skipto</literal> rules do not work 299111706Sbmah when coupled with the <literal>log</literal> keyword. 300111706Sbmah &man.ipfw.4; <literal>uid</literal> rules also do not work 301111706Sbmah properly. These bugs 302111706Sbmah have been fixed in &release.current;.</para> 303109689Sbmah 304109689Sbmah <bridgehead renderas="sect3">Passwords and &man.adduser.8;</bridgehead> 305109689Sbmah 306109689Sbmah <para>&man.adduser.8; does not correctly handle setting user 307109689Sbmah passwords containing special shell characters. This problem has 308109689Sbmah been corrected in &release.current;.</para> 309109689Sbmah 310109692Sbmah <bridgehead renderas="sect3">&man.xl.4;</bridgehead> 311109692Sbmah 312109692Sbmah <para>The &man.xl.4; driver has a timing bug that may cause a 313109692Sbmah kernel panic (or other problems) when attempting to configure an 314109692Sbmah interface. This bug has been fixed in &release.current;.</para> 315109692Sbmah 316109791Sbmah <bridgehead renderas="sect3">ISC DHCP</bridgehead> 317109791Sbmah 318109791Sbmah <para><application>ISC DHCP</application> was updated to 319109791Sbmah 3.0.1rc11. This update was actually a part of &os; 320109791Sbmah &release.prev;, but was not documented in the release 321109791Sbmah notes.</para> 322109791Sbmah 323110124Sbmah <bridgehead renderas="sect3">&man.amd.8; 324110124Sbmah Interoperability</bridgehead> 325110124Sbmah 326110124Sbmah <para>&release.prev; contains some bugs in its non-blocking RPC 327110124Sbmah code. The most noticeable side-effect of these bugs was that 328110124Sbmah &man.amd.8; users were not able to mount volumes from a 329110124Sbmah &release.prev; server. This bug has been fixed in 330110124Sbmah &release.current;.</para> 331110124Sbmah 33276082Sbmah </sect1> 33376082Sbmah</article> 334