From owner-freebsd-bugs@FreeBSD.ORG Wed Sep 9 09:10:03 2009 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A11C61065670 for ; Wed, 9 Sep 2009 09:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC1B8FC12 for ; Wed, 9 Sep 2009 09:10:03 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n899A33f080501 for ; Wed, 9 Sep 2009 09:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n899A3R3080500; Wed, 9 Sep 2009 09:10:03 GMT (envelope-from gnats) Resent-Date: Wed, 9 Sep 2009 09:10:03 GMT Resent-Message-Id: <200909090910.n899A3R3080500@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Archer Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C272106566C for ; Wed, 9 Sep 2009 09:07:05 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 8D4C88FC17 for ; Wed, 9 Sep 2009 09:07:05 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n89975Za042944 for ; Wed, 9 Sep 2009 09:07:05 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n89975Fg042932; Wed, 9 Sep 2009 09:07:05 GMT (envelope-from nobody) Message-Id: <200909090907.n89975Fg042932@www.freebsd.org> Date: Wed, 9 Sep 2009 09:07:05 GMT From: Archer To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/138657: Kernel memory corruption, kernel panic as a result X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 09:10:03 -0000 >Number: 138657 >Category: kern >Synopsis: Kernel memory corruption, kernel panic as a result >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 09 09:10:03 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Archer >Release: FreeBSD 8.0-BETA4 >Organization: n/a >Environment: FreeBSD serv 8.0-BETA4 FreeBSD 8.0-BETA4 #1: Sat Sep 8 19:20:53 MSD 2009 root@serv:/usr/obj/usr/src/sys/MYKERN i386 >Description: Lets take a look at this code in ufs_vnops.c file: refcount_init(&ucred.cr_ref, 1); ucred.cr_uid = ip->i_uid; ucred.cr_ngroups = 1; ucred.cr_groups[0] = dp->i_gid;<---problem here ucp = &ucred; ucred structure variable is used here. It's a local structure so it's allocated on stack. Now lets take a look at the structure definition: struct ucred { --skipped... gid_t *cr_groups; --skipped... }; As we see we've got a pointer. But this pointer is not initialized at the point of usage. So it contains some arbitrary value from the stack. And then that memory gets overwritten. Lets take a look at the assembly listing: mov edx, [esi+6Ch] mov eax, [ebp+var_140]<---here we read some arbitrary pointer from the stack mov [eax], edx<---and here we smash the data at our arbitrary pointer In my case some memory around ufs_lookup was overwritten. >How-To-Repeat: Enable QUOTA and SUIDDIR at the kernel options, set them on some partition and try to create a directory there. For me worked tar -xvjf phpMyAdmin-3.2.1-all-languages.tar.bz2 which also calls mkdir when extracting files. >Fix: In FreeBSD 7.1 ucred structure was defined with cr_groups array instead or pointer. So at some places in 8.0 version this was fixed by creating local gid_t and assigning it's address to the pointer. And some places (and described above is one of them was missed for unknown reason). I suppose we should allocate memory for our pointer before using it so recklessly. It's also possible to create a local gid_t and assigning it's address to the pointer (this is done a bit lower at ufs_vnops.c file). And I suggest to review the code that works with this pointer, the same mistake may happen elsewhere. >Release-Note: >Audit-Trail: >Unformatted: