grsecurity forums

architecture: x86
kernel: linux-2.6.19.7 patched with grsecurity-2.1.10-2.6.19.2-200701222307.patch
compiler: gcc-4.1.2 with glibc-2.5.1
os: LFS

I am building LFS patched with grsecurity for a project I am working on. For the most part, things are working well. However, twice now, I have ended up with a kernel panic when running ssh. I have not managed to reproduce it a third time.

Below is the information I captured from the first crash. The second crash was almost identical.

First PAX reports a "suspicious general protextion fault". Then there is a kernel panic in the gr_update_task_in_ip_table function. It seems that something has gone wrong in kernel space with the socket connect handling that results in the GPF followed by a panic.

I'm not sure if this is enough information for anyone to help. But if anyone has suggestions, that would be great.

Code: Select all

PAX: suspicious general protection fault: d770 [#1]
SMP
Modules linked in: nfp
CPU:    1
EIP:    0060:[<000df47e>]    Not tainted VLI
EFLAGS: 00210213   (2.6.19.7-grsec-orig #1)
EIP is at gr_update_task_in_ip_table+0x5e/0xe0
eax: 00000000   ebx: 8c8817ac   ecx: 0a102f58   edx: 00000000
esi: f7d4e240   edi: f7d52040   ebp: f7a70500   esp: f7a81d98
ds: 0068   es: 0068   ss: 0068
Process ssh (pid: 2529, ti=f7a80000 task=c1983560 task.ti=f7a80000)
Stack: f7c3d770 f7c00000 c1bceca0 f7d52040 002bcbe6 00000000 00000000 00000000
       00000000 c0c39ec0 00009d94 c0c7ac00 00008000 00006e48 00000001 0000009d
       6bc4171c 00000000 f76c87c0 00000000 7d8817ac f7d52040 002d05d5 00000000
Call Trace:
 =======================
Code: b8 60 04 c1 c0 e8 e3 1b 24 00 89 f0 e8 bc fe ff ff 8b 9f 5c 01 00 00 89 9e
 5c 01 00 00 8b 8f 58 01 00 00 89 8e 60 01 00 00 01 d9 <1f> b7 87 70 01 00 00 66
 89 86 64 01 00 00 0f b7 87 60 01 00 00
EIP: [<000df47e>] gr_update_task_in_ip_table+0x5e/0xe0 SS:ESP 0068:f7a81d98
 <0>Kernel panic - not syncing: Fatal exception in interrupt


Results from paxtest-0.9.7-pre4.

Code: Select all

PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
Released under the GNU Public Licence version 2 or later

Mode: kiddie
Linux lfs 2.6.19.7-grsec-orig #1 SMP Sat Apr 12 22:12:21 BST 2008 i686 i686 i386 GNU/Linux

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Executable stack (mprotect)              : Killed
Anonymous mapping randomisation test     : 9 bits (guessed)
Heap randomisation test (ET_EXEC)        : No randomisation
Heap randomisation test (ET_DYN)         : No randomisation
Main executable randomisation (ET_EXEC)  : 10 bits (guessed)
Main executable randomisation (ET_DYN)   : 10 bits (guessed)
Shared library randomisation test        : 10 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 11 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 11 bits (guessed)
Return to function (strcpy)              : paxtest: return address contains a NULL byte.
Return to function (strcpy, RANDEXEC)    : paxtest: return address contains a NULL byte.
Return to function (memcpy)              : Killed
Return to function (memcpy, RANDEXEC)    : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed
Writable text segments                   : Killed


jerry wrote:Below is the information I captured from the first crash. The second crash was almost identical.

First PAX reports a "suspicious general protextion fault". Then there is a kernel panic in the gr_update_task_in_ip_table function. It seems that something has gone wrong in kernel space with the socket connect handling that results in the GPF followed by a panic.

the suspicious gpf and the panic are one and the same event. decoding the code bytes shows that you have a single bit error in memory, i don't know if it's bad RAM or a memory corruption bug although the latter is quite unlikely given that you use KERNEXEC that maps the kernel code area as read-only.

this is the decoded bytes

Code: Select all

1F                           pop         ds
B787                         mov         bh,087 ;'ç'
7001                         jo          000000020
0000                         add         [eax],al
66898664010000               mov         [esi][00000164],ax
0FB78760010000               movzx       eax,w,[edi][00000160]


and if i 'fix' the first byte to be 0F (single bit flip), it becomes:

Code: Select all

0FB78770010000               movzx       eax,w,[edi][00000170]
66898664010000               mov         [esi][00000164],ax
0FB78760010000               movzx       eax,w,[edi][00000160]

makes a whole lot more sense, doesn't it .

Thank you very much.