article.xml revision 112874
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 112874 2003-03-31 18:12:56Z 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]]>
58112874Sbmah      containing significant information discovered after the release
59112874Sbmah      or too late in the release cycle to be otherwise included in the
60112874Sbmah      release documentation.
6192295Sbmah      This information includes security advisories, as well as news
6292295Sbmah      relating to the software or documentation that could affect its
6392295Sbmah      operation or usability.  An up-to-date version of this document
6492295Sbmah      should always be consulted before installing this version of
6592295Sbmah      &os;.</para>
6677914Sbmah
67109307Sbmah    <para>This errata document for &os; 
68109543Sbmah<![ %release.type.snapshot [
69109543Sbmah      &release.prev;
70109543Sbmah]]>
71109543Sbmah<![ %release.type.release [
72109543Sbmah      &release.current;
73109543Sbmah]]>
74109308Sbmah      will be maintained until the release of &os; 5.1-RELEASE.</para>
7577914Sbmah  </abstract>
7677914Sbmah
77109143Sroam  <sect1 id="intro">
7876082Sbmah    <title>Introduction</title>
7976082Sbmah
8079807Sbmah    <para>This errata document contains <quote>late-breaking news</quote>
8192295Sbmah      about &os;
82109543Sbmah<![ %release.type.snapshot [
83109543Sbmah      &release.prev;.
84109543Sbmah]]>
85109543Sbmah<![ %release.type.release [
86109543Sbmah      &release.current;.
87109543Sbmah]]>
8892295Sbmah      Before installing this version, it is important to consult this
8992295Sbmah      document to learn about any post-release discoveries or problems
9092295Sbmah      that may already have been found and fixed.</para>
9179807Sbmah
9292295Sbmah    <para>Any version of this errata document actually distributed
9392295Sbmah      with the release (for example, on a CDROM distribution) will be
9492295Sbmah      out of date by definition, but other copies are kept updated on
9592295Sbmah      the Internet and should be consulted as the <quote>current
9692295Sbmah      errata</quote> for this release.  These other copies of the
9792295Sbmah      errata are located at <ulink
9892295Sbmah      url="http://www.FreeBSD.org/releases/"></ulink>, plus any sites
9992295Sbmah      which keep up-to-date mirrors of this location.</para>
10076082Sbmah
10179807Sbmah    <para>Source and binary snapshots of &os; &release.branch; also
10292295Sbmah      contain up-to-date copies of this document (as of the time of
10392295Sbmah      the snapshot).</para>
10476082Sbmah
10577914Sbmah    <para>For a list of all &os; CERT security advisories, see <ulink
10692295Sbmah      url="http://www.FreeBSD.org/security/"></ulink> or <ulink
10792295Sbmah      url="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/"></ulink>.</para>
10892295Sbmah
10976082Sbmah  </sect1>
11076082Sbmah
111109143Sroam  <sect1 id="security">
11276082Sbmah    <title>Security Advisories</title>
113109309Sbmah
114110463Sbmah    <para>Remotely exploitable vulnerabilities in
115110463Sbmah      <application>CVS</application> could allow an attacker to
116110463Sbmah      execute arbitrary comands on a CVS server.  More details can be
117110463Sbmah      found in security advisory <ulink
118110463Sbmah      url="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:01.cvs.asc">FreeBSD-SA-03:01</ulink>.</para>
119109309Sbmah
120111435Sbmah    <para>A timing-based attack on <application>OpenSSL</application>,
121111435Sbmah      could allow a very powerful attacker access to plaintext
122111435Sbmah      under certain circumstances.  This problem has been corrected in
123111435Sbmah      &os; &release.current; with an upgrade
124111435Sbmah      to <application>OpenSSL</application> 0.9.7.  On supported
125111435Sbmah      security fix branches, this problem has been corrected with the
126111435Sbmah      import of <application>OpenSSL</application> 0.9.6i.  See security
127111435Sbmah      advisory <ulink
128111435Sbmah      url="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:02.openssl.asc">FreeBSD-SA-03:02</ulink>
129111435Sbmah      for more details.</para>
130111435Sbmah
131111435Sbmah    <para>It may be possible to recover the shared secret key used by
132111435Sbmah      the implementation of the <quote>syncookies</quote> feature.
133111435Sbmah      This reduces its effectiveness in dealing with TCP SYN flood
134111435Sbmah      denial-of-service attacks.  Workaround information and fixes are
135111435Sbmah      given in security advisory <ulink
136111435Sbmah      url="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:03.syncookies.asc">FreeBSD-SA-03:03</ulink>.</para>
137111435Sbmah
138112873Sbmah    <para>Due to buffer overflows in header parsing in <application>sendmail</application>, a remote
139111835Sbmah      attacker can create a specially-crafted message that may cause
140111835Sbmah      &man.sendmail.8; to execute arbitrary code
141111835Sbmah      with the privileges of the user running it, typically
142111834Sbmah      <username>root</username>.  More information, including pointers
143112873Sbmah      to patches, can be found in security advisories <ulink
144112873Sbmah      url="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:04.sendmail.asc">FreeBSD-SA-03:04</ulink>
145112873Sbmah      and <ulink
146112873Sbmah      url="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:07.sendmail.asc">FreeBSD-SA-03:07</ulink>.</para>
147111834Sbmah
148112435Sbmah    <para>The XDR encoder/decoder does incorrect bounds-checking,
149112435Sbmah      which could allow a remote attacker to cause a
150112435Sbmah      denial-of-service.  For bugfix information, see security
151112435Sbmah      advisory <ulink
152112435Sbmah      url="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:05.xdr.asc">FreeBSD-SA-03:05</ulink>.</para>
153112435Sbmah
154112477Sbmah    <para><application>OpenSSL</application> has been found
155112477Sbmah      vulnerable to two recently-disclosed attacks.  Information
156112477Sbmah      on workarounds and patches for supported security branches is
157112477Sbmah      contained in security advisory <ulink
158112477Sbmah      url="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:06.openssl.asc">FreeBSD-SA-03:06</ulink>.</para>
159112477Sbmah
16076082Sbmah  </sect1>
16176082Sbmah
162109309Sbmah  <sect1 id="late-news">
163109309Sbmah    <title>Late-Breaking News</title>
164109309Sbmah
165109583Schris    <bridgehead renderas="sect3">GEOM</bridgehead>
166109583Schris
167109309Sbmah    <para>The &man.geom.4;-based disk partitioning code in the kernel
168109309Sbmah      will not allow an open partition to be overwritten.  This
169109309Sbmah      usually prevents the use of <command>disklabel -B</command> to
170109309Sbmah      update the boot blocks on a disk because the
171109309Sbmah      <literal>a</literal> partition overlaps the space where the boot
172109309Sbmah      blocks are stored.  A suggested workaround is to boot from an
173109309Sbmah      alternate disk, a CDROM, or a fixit floppy.</para>
174109309Sbmah
175109583Schris    <bridgehead renderas="sect3">&man.dump.8;</bridgehead>
176109583Schris
177109309Sbmah    <para>When using disk media with sector sizes larger than 512
178109309Sbmah      bytes (for instance, &man.gbde.4; encrypted disks), the
179109309Sbmah      &man.dump.8; program fails to respect the larger sector size and
180109309Sbmah      cannot dump the partition.  One possible workaround is to copy
181109309Sbmah      the entire file system in raw format and dump the copy.  It is,
182109309Sbmah      for instance, possible to dump a file system stored in a regular
183109309Sbmah      file:</para>
184109309Sbmah
185109309Sbmah      <screen>&prompt.root; <userinput>dd if=/dev/ad0s1d.bde of=/junk/ad0.dd bs=1m</userinput>
186109309Sbmah&prompt.root; <userinput>dump 0f - /junk/ad0.dd | ...</userinput></screen>
187109309Sbmah
188109309Sbmah    <para>A simpler workaround is to use &man.tar.1; or &man.cpio.1;
189109309Sbmah      to make backup copies.</para>
190109309Sbmah
191109583Schris    <bridgehead renderas="sect3">&man.mly.4;</bridgehead>
192109583Schris
193110514Sbmah    <para>Hangs were reported during &os; 5.0 snapshot
194109309Sbmah      installations when installing to &man.mly.4;-supported RAID
195109309Sbmah      arrays, in hardware configurations that appear to work fine
196110514Sbmah      under &os; 4.7-RELEASE.  These problems have been corrected
197110514Sbmah      in &os; &release.current;.</para>
198109309Sbmah
199109583Schris    <bridgehead renderas="sect3">NETNCP/Netware File System
200109583Schris      Support</bridgehead>
201109583Schris
202109309Sbmah    <para>NETNCP and nwfs appear to be as-yet unadapted for KSE, and
203111706Sbmah      hence not working.  These have been fixed in &os;
204111706Sbmah      &release.current;.</para>
205109309Sbmah
206109583Schris    <bridgehead renderas="sect3">&man.iir.4; controller</bridgehead>
207109583Schris
208109309Sbmah    <para>During installation, the &man.iir.4; controller appears to
209109309Sbmah      probe correctly, but finds no disk devices.</para>
210109309Sbmah
211109583Schris    <bridgehead renderas="sect3">&man.truss.1; race condition</bridgehead>
212109583Schris
213109309Sbmah    <para>&man.truss.1; appears to contain a race condition during the
214109309Sbmah      start-up of debugging, which can result in &man.truss.1; failing
215109309Sbmah      to attach to the process before it exists.  The symptom is that
216109309Sbmah      &man.truss.1; reports that it cannot open the &man.procfs.5;
217109309Sbmah      node supporting the process being debugged.  A bug also appears
218109309Sbmah      to exist wherein &man.truss.1; will hang if &man.execve.2;
219109309Sbmah      returns <literal>ENOENT</literal> A further race appears to
220109309Sbmah      exist in which &man.truss.1; will return <errorname>PIOCWAIT:
221109309Sbmah      Input/output error</errorname> occasionally on startup.  The fix
222109309Sbmah      for this sufficiently changes process execution handling that it
223109309Sbmah      has been deferred until after 5.0.</para>
224109309Sbmah
225109583Schris    <bridgehead renderas="sect3">Disk Partitioning in Installer</bridgehead>
226109583Schris
227109309Sbmah    <para>Some bugs have been reported in &man.sysinstall.8; disk
228109309Sbmah      partitioning.  One observed problem on the i386 is that
229109309Sbmah      &man.sysinstall.8; cannot recalculate the free space left on a
230109309Sbmah      disk after changing the type of an FDISK-type partition.</para>
231109309Sbmah
232109583Schris    <bridgehead renderas="sect3">Stale Documentation</bridgehead>
233109583Schris
234109309Sbmah    <para>In some case, documentation (such as the FAQ or Handbook)
235109543Sbmah      has not been updated to take into account &os; &release.prev;
236109309Sbmah      features.  Examples of areas where documentation is still
237109309Sbmah      needed include &man.gbde.8; and the new <quote>fast
238109309Sbmah      IPsec</quote> implementation.</para>
239109309Sbmah
240109583Schris    <bridgehead renderas="sect3">SMB File System</bridgehead>
241109583Schris
242109338Sbmah    <para>Attempting to unmount smbfs shares may fail with
243109338Sbmah      <errorname>Device busy</errorname> errors even when the
244109338Sbmah      mount-point is not really busy.  A workaround is to keep trying
245109338Sbmah      to unmount the share until it eventually succeeds.  This bug has
246109543Sbmah      been fixed in &release.current;.</para>
247109338Sbmah
248109338Sbmah    <para>Forcefully unmounting (<command>umount -f</command>) smbfs
249109338Sbmah      shares may cause a kernel panic.  This bug has been fixed in
250109543Sbmah      &release.current;.</para>
251109338Sbmah
252109583Schris    <bridgehead renderas="sect3">&man.fstat.2;</bridgehead>
253109583Schris
254109338Sbmah    <para>When called on a connected socket file descriptor,
255109338Sbmah      &man.fstat.2; is supposed to return the number of bytes
256109338Sbmah      available to read in the <varname>st_size</varname> member of
257109338Sbmah      <varname>struct stat</varname>. However,
258109338Sbmah      <varname>st_size</varname> is always erroneously reported as
259109338Sbmah      <literal>0</literal> on TCP sockets.  This bug has been fixed in
260109543Sbmah      &release.current;.</para>
261109338Sbmah
262109583Schris    <bridgehead renderas="sect3">Kernel Event Queues</bridgehead>
263109583Schris
264109338Sbmah    <para>The &man.kqueue.2; <literal>EVFILT_READ</literal> filter
265109338Sbmah      erroneously indicates that <literal>0</literal> bytes are
266109338Sbmah      available to be read on TCP sockets, regardless of the number of
267109338Sbmah      bytes that are actually available. The
268109338Sbmah      <literal>NOTE_LOWAT</literal> flag for
269109338Sbmah      <literal>EVFILT_READ</literal> is also broken on TCP sockets.
270109543Sbmah      This bug has been fixed in &release.current;.</para>
271109338Sbmah
272109583Schris    <bridgehead renderas="sect3">POSIX Named Semaphores</bridgehead>
273109583Schris
274109543Sbmah    <para>&os; &release.prev; introduced support for POSIX named semaphores
275109338Sbmah      but the implementation contains a critical bug that causes
276109338Sbmah      &man.sem.open.3; to incorrectly handle the opening of the same
277109338Sbmah      semaphore multiple times by the same process, and that causes
278109338Sbmah      &man.sem.close.3; to crash calling programs.  This bug has been
279109543Sbmah      fixed in &release.current;.</para>
280109338Sbmah
281109583Schris    <bridgehead renderas="sect3"><filename>/dev/tty</filename>
282109583Schris      Permissions</bridgehead>
283109583Schris
284109543Sbmah    <para>&os; &release.prev; has a minor bug in how the permissions of
285109339Sbmah      <filename>/dev/tty</filename> are handled.  This can be
286109339Sbmah      triggered by logging in as a non-<username>root</username>,
287109339Sbmah      non-<groupname>tty</groupname> group user, and using &man.su.1;
288109339Sbmah      to switch to a second non-<username>root</username>,
289109339Sbmah      non-<groupname>tty</groupname> group user.  &man.ssh.1; will
290109339Sbmah      fail because it cannot open <filename>/dev/tty</filename>.  This
291109543Sbmah      bug has been fixed in &release.current;.</para>
292109339Sbmah
293109583Schris    <bridgehead renderas="sect3">&man.growfs.8;</bridgehead>
294109583Schris
295109400Sbmah    <para>&man.growfs.8; no longer works on &man.vinum.4; volumes (and
296109400Sbmah      presumably, on &man.geom.4; entities) since these subsystems no
297109400Sbmah      longer fake disklabels, but &man.growfs.8; insists on examining
298109400Sbmah      a label.</para>
299109400Sbmah
300109612Sbmah    <bridgehead renderas="sect3">IPFW</bridgehead>
301109612Sbmah
302109612Sbmah    <para>&man.ipfw.4; <literal>skipto</literal> rules do not work
303111706Sbmah      when coupled with the <literal>log</literal> keyword.
304111706Sbmah      &man.ipfw.4; <literal>uid</literal> rules also do not work
305111706Sbmah      properly.  These bugs
306111706Sbmah      have been fixed in &release.current;.</para>
307109689Sbmah
308109689Sbmah    <bridgehead renderas="sect3">Passwords and &man.adduser.8;</bridgehead>
309109689Sbmah
310109689Sbmah    <para>&man.adduser.8; does not correctly handle setting user
311109689Sbmah      passwords containing special shell characters.  This problem has
312109689Sbmah      been corrected in &release.current;.</para>
313109689Sbmah
314109692Sbmah    <bridgehead renderas="sect3">&man.xl.4;</bridgehead>
315109692Sbmah
316109692Sbmah    <para>The &man.xl.4; driver has a timing bug that may cause a
317109692Sbmah      kernel panic (or other problems) when attempting to configure an
318109692Sbmah      interface.  This bug has been fixed in &release.current;.</para>
319109692Sbmah
320109791Sbmah    <bridgehead renderas="sect3">ISC DHCP</bridgehead>
321109791Sbmah
322109791Sbmah    <para><application>ISC DHCP</application> was updated to
323109791Sbmah      3.0.1rc11.  This update was actually a part of &os;
324109791Sbmah      &release.prev;, but was not documented in the release
325109791Sbmah      notes.</para>
326109791Sbmah
327110124Sbmah    <bridgehead renderas="sect3">&man.amd.8;
328110124Sbmah      Interoperability</bridgehead>
329110124Sbmah
330110124Sbmah    <para>&release.prev; contains some bugs in its non-blocking RPC
331110124Sbmah      code.  The most noticeable side-effect of these bugs was that
332110124Sbmah      &man.amd.8; users were not able to mount volumes from a
333110124Sbmah      &release.prev; server.  This bug has been fixed in
334110124Sbmah      &release.current;.</para>
335110124Sbmah
33676082Sbmah  </sect1>
33776082Sbmah</article>
338