diff --git a/en/releases/4.5R/errata.html b/en/releases/4.5R/errata.html
index e303d95c57..613f24ef9f 100644
--- a/en/releases/4.5R/errata.html
+++ b/en/releases/4.5R/errata.html
@@ -22,7 +22,7 @@
 
         <p class="PUBDATE">$FreeBSD:
         src/release/doc/en_US.ISO8859-1/errata/article.sgml,v
-        1.1.2.48 2002/02/05 18:59:23 bmah Exp $<br>
+        1.1.2.50 2002/02/06 17:04:41 bmah Exp $<br>
         </p>
         <hr>
       </div>
@@ -83,13 +83,29 @@
         <h1 class="SECT1"><a name="AEN25">2 Security
         Advisories</a></h1>
 
-        <p>No active security advisories.</p>
+        <p>A race condition existed whereby a file could be removed
+        between a <a href=
+        "http://www.FreeBSD.org/cgi/man.cgi?query=fstatfs&sektion=2&manpath=FreeBSD+4.5-stable">
+        <span class="CITEREFENTRY"><span class=
+        "REFENTRYTITLE">fstatfs</span>(2)</span></a> call and the
+        point where the file is accessed, causing a kernel panic.
+        Only the <a href=
+        "http://www.FreeBSD.org/cgi/man.cgi?query=procfs&sektion=5&manpath=FreeBSD+4.5-stable">
+        <span class="CITEREFENTRY"><span class=
+        "REFENTRYTITLE">procfs</span>(5)</span></a> filesystem was
+        known to be vulnerable to this attack. This bug was fixed
+        in FreeBSD 4.5-RELEASE, but the security advisory
+        describing the bug was issued after the release. For more
+        information, including a workaround and bug fix, see
+        security advisory <a href=
+        "ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:09.fstatfs.asc"
+         target="_top">FreeBSD-SA-02:09</a>.</p>
       </div>
 
       <div class="SECT1">
         <hr>
 
-        <h1 class="SECT1"><a name="AEN28">3 System Update
+        <h1 class="SECT1"><a name="AEN35">3 System Update
         Information</a></h1>
 
         <p>Certain SSH clients, when attempting to connect to a
@@ -98,13 +114,47 @@
         "http://www.FreeBSD.org/cgi/man.cgi?query=sshd&sektion=8&manpath=FreeBSD+4.5-stable">
         <span class="CITEREFENTRY"><span class=
         "REFENTRYTITLE">sshd</span>(8)</span></a> on the server has
-        not been configured for <b class="APPLICATION">S/Key</b>
-        authentication. As a workaround, uncomment the <tt class=
-        "LITERAL">ChallengeResponseAuthentication no</tt> line in
-        <tt class="FILENAME">/etc/ssh/sshd_config</tt> (on the
-        server host). This behavior has been observed with the <b
-        class="APPLICATION">OpenSSH</b> 3.0.1 and 3.0.2 clients, as
-        well as with PuTTY.</p>
+        not been later explicitly configured for <b class=
+        "APPLICATION">S/Key</b> authentication. This is due to the
+        default settings of clients having changed (e.g. use of SSH
+        protocol version 2 where it was not used before), or from a
+        change from the client's old default authentication
+        sequence. There are a number of ways to disable this
+        behavior:</p>
+
+        <ul>
+          <li>
+            <p>On newer <b class="APPLICATION">OpenSSH</b> clients,
+            add the following line to your <tt class=
+            "FILENAME">~/.ssh/config</tt> file:</p>
+<pre class="PROGRAMLISTING">
+    PreferredAuthentications publickey,password,keyboard-interactive
+</pre>
+            <br>
+            <br>
+          </li>
+
+          <li>
+            <p>For <b class="APPLICATION">PuTTY</b> clients, the
+            authentication sequence order cannot be changed, but
+            keyboard-interactive authentication can be disabled in
+            the settings.</p>
+          </li>
+
+          <li>
+            <p>To disable keyboard-interactive authentication in
+            the server, uncomment the following line in the <tt
+            class="FILENAME">/etc/ssh/sshd_config</tt> file (on the
+            server host):</p>
+<pre class="PROGRAMLISTING">
+    ChallengeResponseAuthentication no
+</pre>
+            <br>
+            <br>
+          </li>
+        </ul>
+        <br>
+        <br>
 
         <p>The release notes mentioned the new sbni device driver,
         but gave an incorrect reference to the program in the