From owner-freebsd-security@FreeBSD.ORG Fri May 6 09:56:26 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F02F16A4CE for ; Fri, 6 May 2005 09:56:26 +0000 (GMT) Received: from gen129.n001.c02.escapebox.net (gen129.n001.c02.escapebox.net [213.73.91.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFBD143D67 for ; Fri, 6 May 2005 09:56:25 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <427B3F46.8050607@geminix.org> Date: Fri, 06 May 2005 11:56:22 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050501 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-security@freebsd.org References: <200505060303.j4633Nif089160@freefall.freebsd.org> In-Reply-To: <200505060303.j4633Nif089160@freefall.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DTzZH-000Eeq-NZ; Fri, 06 May 2005 11:56:24 +0200 Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:08.kmem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2005 09:56:26 -0000 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