[gentoo-hardened] shutting down grsecurity acl causes a kernel panic (free_variables slab issue, i think)

[gentoo-hardened] shutting down grsecurity acl causes a kernel panic (free_variables slab issue, i think)

[Andrew Griffiths]

Hello,

I'm using the gentoo hardened sources (specifically, 2.6.14-hardened-r7)
and I'm getting a reproducable kernel panic everytime I disable the acl
system. I've had this iss on 2.6.14-hardened-r5 before, however, it
hasn't been an issue up till now (as now I want to use the acl interface
properly)

dmesg gives the following:

<6>grsec: (admin:S:/) exec of /sbin/gradm (/sbin/gradm -D ) by
bin/bash[bash:
20173] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:18492]
uid/euid:0/0 gid/
egid:0/0
<1>grsec: shutdown auth success for /sbin/gradm[gradm:20173]
uid/euid:0/0 gid/
egid:0/0, parent /bin/bash[bash:18492] uid/euid:0/0 gid/egid:0/0
<1>Unable to handle kernel paging request at virtual address 6b6b6c37
<1> printing eip:
<4>000f01c0
<1>*pgd =    0
<1>*pmd =    0
<1>Oops: 0000 [#1]
<4>Modules linked in:
<4>CPU:    0
<4>EIP:    0060:[<000f01c0>]    Not tainted VLI
<4>EFLAGS: 00010202   (2.6.14-hardened-r7-y0) 
<4>EIP is at free_variables+0x24e/0x2b8
<4>eax: cba8c2fc   ebx: cf1c9b00   ecx: 00000007   edx: 00000007
<4>esi: 00000000   edi: 6b6b6b6b   ebp: cb6f5f2c   esp: cb6f5f10
<4>ds: 007b   es: 007b   ss: 0068
<4>Process gradm (pid: 20173, threadinfo=cb6f4000 task=cfcfb570)
<4>Stack: 7e9143b5 8c875d91 72b80524 00000007 0000000c 00000000
00000000 cb6f5
f6c 
<4>       000f32ac 00000002 c069b034 00000007 cb648d00 ce981000
17509d50 17509
d50 
<4>       1751ca38 00000218 0000011c 00000001 c0c0ef00 cb648d00
1751cb58 cb6f5
f8c 
<4>Call Trace:
<4> [<000033a7>] show_stack+0x7a/0x90
<4> [<0000352d>] show_registers+0x157/0x1d9
<4> [<00003706>] die+0xc6/0x152
<4> [<0026b7ea>] do_page_fault+0x580/0x860
<4> [<0000305f>] error_code+0x4f/0x60
<4> [<000f32ac>] write_grsec_handler+0x74c/0x7d6
<4> [<0004d2a9>] vfs_write+0x165/0x16a
<4> [<0004d34f>] sys_write+0x3d/0x64
<4> [<00002d89>] syscall_call+0x7/0xb
<4>Code: 3d 00 10 00 00 77 57 8b 43 30 e8 63 95 f4 ff 83 45 f0 01 8b 15 b4 a7 
cb c0 3b 55 f0 e9 7b fe ff ff 8b 43 30 8b 3c b0 85 ff 74 60 
<8b> 8f cc 00 00 00 
85 c9 2e 0f 84 73 ff ff ff 8b 87 d0 00 00 00 
<4> 

Disassembling the free_variables gives:

0x000f01c0 <free_variables+590>:        mov    0xcc(%edi),%ecx

and edi is 6b6b6b6b (ascii 'k', which is #define POISON_FREE     0x6b
/* for use-after-free poisoning */))

The gcc version is 3.4.5 (gentoo hardened 3.4.5-r1, ssp-3.4.5-1.0,
pie-8.7.9).

To reproduce this issue, I generally do:

gradm -E -L blah3
su - andrewg
/sbin/gradm -a admin
su - 
/sbin/gradm -D 
(which then prompts me for the password, then goes b00m):

I've been talking to a guy about debugging this, who recommended I
enable slab debugging (i also enabled other debugging stuff such as ebp
/ extra info). When slab debugging is turned off, it dies inside the
a kernel thread, to quote "that thread is used to free unused slab pages back
to the main buddy allocator". After turning on slab debugging, it dies
in free_variables.

The vmlinux image, system.map, .config and acl rules I'm using can be 
downloaded from http://felinemenace.org/~andrewg/acl-crash.tgz, or
alternatively individually from
http://felinemenace.org/~andrewg/acl-crash/ 

I'm using kdb on the kernel, and can use that to further debug if need
be. 

Not sure which list this message is best suited towards, so I've cross
posted, though I suspect a lot of people will be reading the message
twice, so sorry about that.

Thanks,
Andrew Griffiths
-- 
gentoo-hardened@gentoo.org mailing list

[gentoo-hardened] Re: [grsec] shutting down grsecurity acl causes a kernel panic (free_variables slab issue, i think)

[Andrew Griffiths]

> The vmlinux image, system.map, .config and acl rules I'm using can be 
> downloaded from http://felinemenace.org/~andrewg/acl-crash.tgz, or
> alternatively individually from
> http://felinemenace.org/~andrewg/acl-crash/ 
> 

After playing around with the acl rules, I isolated it down to the
domain line which seems to cause the problems.. take a default policy
line from the gradm2 tarball, add  (probably with other users)

domain wargamers ul level0 level1 level2 level3 level4 level5 level6 
level7 level8 level9 level10 

then gradm -E -L /etc/grsec/blah, then gradm -D

The kernel should then panic as before (with edi ==  0x6b6b6b6b)

Hope this helps,
Andrew Griffiths

-- 
gentoo-hardened@gentoo.org mailing list