Freeze 2.4.32 + grsecurity

[stangred]

I upgraded kerenel to 2.4.32 + grsecurity and server freeze under 50% (about 2 hours) cpu usage ( 2xXeon 2.6GHz SMP). It it probably the same problem, what was described in http://forums.grsecurity.net/viewtopic.php?t=1283

Is there a chance that this problem will be solve in near future ??

[PaX Team]

I upgraded kerenel to 2.4.32 + grsecurity and server freeze under 50% (about 2 hours) cpu usage ( 2xXeon 2.6GHz SMP). It it probably the same problem, what was described in http://forums.grsecurity.net/viewtopic.php?t=1283

Is there a chance that this problem will be solve in near future ??

as you can see it there, we've been waiting for more information ever since. the 50% CPU usage means that one of the CPUs is spinning somewhere, probably in the kernel, would be nice to figure out which task triggered it and where in the kernel we are (sysrq+t).

[jom]

I've been away from grsecurity for quite a while...
Regarding andutt's case I sent Brad some more info in a mail. With the nmi-watchdog enabled we got an oops. It looked like it could be the tigon 3 driver and not grsecurity. However (I don't think I ever informed Brad of this) we never got the oops without grsecurity in the kernel. With grsecurity oops every couple of days. Without grsecurity not once for months (with 2.4.31).

Oops output (from what was visible on the screen) :
Trace; c02a7508 <ip_output+108/1b0>
Trace; c02c3529 <tcp_v4_rcv+609/860>
Trace; c02a78db <ip_queue_xmit+32b/5c0>
Trace; c02a131e <ip_route_input+4e/210>
Trace; c02a3d4c <ip_local_deliver+17c/200>
Trace; c02a3d4c <ip_local_deliver+17c/200>
Trace; c02a4125 <ip_rcv+355/490>
Trace; c028f483 <netif_receive_skb+e3/1b0>
Trace; f8906fae <[tg3]tg3_rx+2fe/3e0>
Trace; f890719f <[tg3]tg3_poll+10f/250>
Trace; c028f74f <net_rx_action+cf/180>
Trace; c016dff9 <do_softirq+d9/e0>
Trace; c0153a00 <do_IRQ+180/190>
Trace; c02b2756 <tcp_setsockopt+426/790>
Trace; c01567f8 <call_do_IRQ+5/d>
Trace; c0163c18 <schedule+448/710>
Trace; c015044b <sys_rt_sigsuspend+15b/190>
Trace; c0151633 <system_call+33/40>
Code; 00000000 Before first symbol
00000000 <_EIP>:
Code; 00000000 Before first symbol
0: f3 90 repz nop
Code; 00000002 Before first symbol
2: 7e f5 jle fffffff9 <_EIP+0xfffffff9>
Code; 00000004 Before first symbol
4: e9 f5 e6 ff ff jmp ffffe6fe <_EIP+0xffffe6fe>
Code; 00000009 Before first symbol
9: 80 3a 00 cmpb $0x0,(%edx)
Code; 0000000c Before first symbol
c: f3 90 repz nop
Code; 0000000e Before first symbol
e: 7e f9 jle 9 <_EIP+0x9>
Code; 00000010 Before first symbol
10: 22 e8 and %al,%ch
Code; 00000012 Before first symbol
12: ff 00 incl (%eax)

NMI Watchdog detected LOCKUP on CPU1, eip c02f26e1, registers:
CPU: 1
EFLAGS: 00000086
eax: 00006803 ebx: dc1c6000 ecx: f76587c0 edx: f77bc480
esi: dc1c6000 edi: dc1c661c ebp: dc1c7fb8 esp: dc1c7f70
ds: 0018 es: 0018 ss:0018
Process java (pid: 20201, stackpage=dc1c7000)
Stack: dc1c6000 092e25c0 dc1c661c e4ce403c 00004ee9 dc1c6000 00000000
c0164b69
dc1c6000 fffffffe 80000004 fffffff2 00000000 c015761a 00000002
dc1c6000
00004ee9 00000000 8bd01fec c0151633 00004ee9 00000000 092e26d8
00004ee9
Call Trace: [<c0164b69>] [<c015761a>] [<c0151633>]
Code: 7e f5 e9 d0 f6 ff ff e8 d7 d9 e5 ff e9 ee f7 ff ff e8 cd d9


>>ebx; dc1c6000 <_end+1bdbbd9c/384f5dfc>
>>ecx; f76587c0 <_end+3724e55c/384f5dfc>
>>edx; f77bc480 <_end+373b221c/384f5dfc>
>>esi; dc1c6000 <_end+1bdbbd9c/384f5dfc>
>>edi; dc1c661c <_end+1bdbc3b8/384f5dfc>
>>ebp; dc1c7fb8 <_end+1bdbdd54/384f5dfc>
>>esp; dc1c7f70 <_end+1bdbdd0c/384f5dfc>

Trace; c0164b69 <setscheduler+f9/280>
Trace; c015761a <call_reschedule_interrupt+5/b>
Trace; c0151633 <system_call+33/40>

Code; 00000000 Before first symbol
00000000 <_EIP>:
Code; 00000000 Before first symbol
0: 7e f5 jle fffffff7 <_EIP+0xfffffff7>
Code; 00000002 Before first symbol
2: e9 d0 f6 ff ff jmp fffff6d7 <_EIP+0xfffff6d7>
Code; 00000007 Before first symbol
7: e8 d7 d9 e5 ff call ffe5d9e3 <_EIP+0xffe5d9e3>
Code; 0000000c Before first symbol
c: e9 ee f7 ff ff jmp fffff7ff <_EIP+0xfffff7ff>
Code; 00000011 Before first symbol
11: e8 cd d9 00 00 call d9e3 <_EIP+0xd9e3>


Speaking of hangs I have another long standing issue that occurs rarerly on some of my systems (not tested with 2.4.32 but present from at least 2.4.27 until 2.4.31). The system hangs when running cron.daily (redhat).

magic sysrq gives me this:
>>EIP; c02f46c2 <gr_cap_rtnetlink+12f2/60e0> <=====

>>ESI; f776ef60 <_end+37376fcc/385080cc>
>>edi; f5c17360 <_end+3581f3cc/385080cc>

Trace; c02f6870 <gr_cap_rtnetlink+34a0/60e0>
Trace; c02f690d <gr_cap_rtnetlink+353d/60e0>
Trace; c02f69a6 <gr_cap_rtnetlink+35d6/60e0>
Trace; c02f7073 <gr_cap_rtnetlink+3ca3/60e0>
Trace; c02fd416 <gr_task_is_capable+16e6/3030>
Trace; c01aec50 <lock_may_write+1a0/220>
Trace; c01a3e13 <follow_down+a73/1080>
Trace; c01d37de <journal_dirty_metadata+de/250>
Trace; c01d2f9c <journal_unlock_updates+75c/7d0>
Trace; c01a7847 <vfs_readlink+7/80>
Trace; c01a3e7d <follow_down+add/1080>

[stangred]

I have one server in the same configuration like the server which hangs, where i can make some tests, if you can give me advices how to get informations which you need to solve this bug.

[spender]

Can you try the latest patch in http://grsecurity.net/~spender? I believe I've fixed this problem.

-Brad