Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 06 May 2005 11:56:22 +0200
From:      Uwe Doering <gemini@geminix.org>
To:        freebsd-security@freebsd.org
Subject:   Re: FreeBSD Security Advisory FreeBSD-SA-05:08.kmem
Message-ID:  <427B3F46.8050607@geminix.org>
In-Reply-To: <200505060303.j4633Nif089160@freefall.freebsd.org>
References:  <200505060303.j4633Nif089160@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
FreeBSD Security Advisories wrote:
> [...]

> a) Download the relevant patch from the location below, and verify the
> detached PGP signature using your PGP utility.
> 
> [FreeBSD 4.x]
> # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:08/kmem4.patch
> # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:08/kmem4.patch.asc

Among other things 'kmem4.patch' deals with zeroing a "struct xinpcb" 
variable, allocated on the stack, in div_pcblist(), rip_pcblist() and 
udp_pcblist().  Identical code in all three cases:

                 inp = inp_list[i];
                 if (inp->inp_gencnt <= gencnt) {
                         struct xinpcb xi;
+                       bzero(&xi, sizeof(xi));
                         xi.xi_len = sizeof xi;
                         /* XXX should avoid extra copy */
                         bcopy(inp, &xi.xi_inp, sizeof *inp);

However, isn't there a similar case in tcp_pcblist()?  Only that this 
time a "struct xtcpcb" variable is concerned.  It isn't guaranteed to be 
completely initialized, either.  Especially since it has the same kind 
of explicit alignment padding at the end as "struct xinpcb" which cannot 
be expected to become initialized in the course of data assignment in 
any case.

Here's the relevant part at line 897 in 'tcp_subr.c' (RELENG_4):

                 inp = inp_list[i];
                 if (inp->inp_gencnt <= gencnt) {
                         struct xtcpcb xt;
                         caddr_t inp_ppcb;
                         xt.xt_len = sizeof xt;
                         /* XXX should avoid extra copy */
                         bcopy(inp, &xt.xt_inp, sizeof *inp);

I'd think that the appropriate patch would therefore look like this:

                 inp = inp_list[i];
                 if (inp->inp_gencnt <= gencnt) {
                         struct xtcpcb xt;
                         caddr_t inp_ppcb;
+                       bzero(&xt, sizeof(xt));
                         xt.xt_len = sizeof xt;
                         /* XXX should avoid extra copy */
                         bcopy(inp, &xt.xt_inp, sizeof *inp);

If my analysis is correct the release of an additional or updated 
security advisory might be called for.

    Uwe
-- 
Uwe Doering         |  EscapeBox - Managed On-Demand UNIX Servers
gemini@geminix.org  |  http://www.escapebox.net



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?427B3F46.8050607>