grsecurity forums

Just tried the grsecurity-2.1.12-2.6.27.4-200811011834 test patch after using interdiff to update the PaX component from test10 to test13 so that it boots under xen. Restarting snmpd seems to keep triggering a kernel oops.

Code: Select all

BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
IP: [<ffffffff8039b0e9>] 0xffffffff8039b0e9
PGD 0
Oops: 0000 [1] SMP
CPU 0
Pid: 17333, comm: snmpd Not tainted 2.6.27.4-grsec #1
RIP: e030:[<ffffffff8039b0e9>]  [<ffffffff8039b0e9>] 0xffffffff8039b0e9
RSP: e02b:ffff8800087cbbb8  EFLAGS: 00010202
RAX: 0000000000000000 RBX: ffff88000edd7598 RCX: ffffffffffffffff
RDX: ffff88000e662740 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8800087cbe08
R10: 00000000ffffffec R11: ffffffff8037797b R12: ffff88000edd7400
R13: 0000000000000001 R14: ffff88000deeb000 R15: ffffffff805afcc4
FS:  000072ba325f76d0(0000) GS:ffffffff80628340(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 00000000087ab000 CR4: 0000000000002620
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process snmpd (pid: 17333, threadinfo ffff8800087ca000, task ffff8800086d33c0)
Stack:  ffffffff802706fa 0000000000000200 ffff88000edb30f8 ffffffff807268a0
 000000004913b6a2 000000002b16c3ad ffff88000f595098 ffffffff802adb78
 ffff88000edb30f8 ffffffff80287840 ffff88000edb30f8 ffff88000f5952f0
Call Trace:
 [<ffffffff802706fa>] 0xffffffff802706fa
 [<ffffffff802adb78>] 0xffffffff802adb78
 [<ffffffff80287840>] 0xffffffff80287840
 [<ffffffff8051af15>] 0xffffffff8051af15
 [<ffffffff802b470a>] 0xffffffff802b470a
 [<ffffffff8027cdb0>] 0xffffffff8027cdb0
 [<ffffffff8027d211>] 0xffffffff8027d211
 [<ffffffff80204255>] 0xffffffff80204255
 [<ffffffff8027dbfd>] 0xffffffff8027dbfd
 [<ffffffff802706fa>] 0xffffffff802706fa
 [<ffffffff8027dd43>] 0xffffffff8027dd43
 [<ffffffff8027e0d1>] 0xffffffff8027e0d1
 [<ffffffff803a0277>] 0xffffffff803a0277
 [<ffffffff802786ff>] 0xffffffff802786ff
 [<ffffffff80278a8b>] 0xffffffff80278a8b
 [<ffffffff8051af15>] 0xffffffff8051af15
 [<ffffffff8051af46>] 0xffffffff8051af46
 [<ffffffff803a459d>] 0xffffffff803a459d
 [<ffffffff8051b320>] 0xffffffff8051b320
 [<ffffffff8020811a>] 0xffffffff8020811a


Code: 24 68 89 44 24 68 65 8b 04 25 24 00 00 00 89 c0 4c 8b 34 c2 4d 85 c0 74 20 49 8b 78 08 48 83 c9 ff 31 c0 fc 4d 8b 40 28 41 ff c5 <f2> ae 48 f7 d1 48 ff c9 8d 74 0e 01 eb db 41 0f b7 c5 49 83 cc
RIP  [<ffffffff8039b0e9>] 0xffffffff8039b0e9
 RSP <ffff8800087cbbb8>
CR2: 0000000000000000
Kernel panic - not syncing: Fatal exception

The System.map can be found here: http://www.ayuda.com.au/grsec/System.ma ... 0811011834

Is anything else required to debug the issue?

Forgot to mention that the problem does not occur with a PaX only kernel or vanilla kernel. The system is also a guest VM using xen/paravirt_ops.

bplant wrote:Forgot to mention that the problem does not occur with a PaX only kernel or vanilla kernel.

that's no wonder because the oops occured in gr_handle_sysctl which is grsec specific. guess spender needs to look at it some more .

I've fixed the problem in the latest test patch. I've also rolled in the most recent PaX changes.

-Brad

spender wrote:I've fixed the problem in the latest test patch. I've also rolled in the most recent PaX changes.

I'll give it a spin and report back.

Cheers, Brad

bplant wrote:

spender wrote:I've fixed the problem in the latest test patch. I've also rolled in the most recent PaX changes.

I'll give it a spin and report back.

It's now been running for about a day on 18 xen guests without incident. Previously I was getting several panics per hour. So it looks like it's now all fixed. Well done!