i386/138613: Kernel memory corruption, kernel panic as a result

[Archer]

>Number:         138613
>Category:       i386
>Synopsis:       Kernel memory corruption, kernel panic as a result
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-i386
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Sep 07 16:00:02 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator:     Archer
>Release:        8.0-BETA3
>Organization:
none
>Environment:
FreeBSD serv 8.0-BETA3 FreeBSD 8.0-BETA3 #1: Sat Sep  5 09:33:03 MSD 2009     root at 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, 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:
I suppose we should allocate memory for our pointer before using it so recklessly. And I suggest to review the code that works with this pointer, the same mistake may happen elsewhere.

>Release-Note:
>Audit-Trail:
>Unformatted: