grsecurity forums

Hi,

Some time ago, I have come across (possibly) grsec related bug in x86_64 kernel. It happens very rarely (once in some previous version of kernel and grsec I was using, I'm not sure which it was, and now twice with 2.6.21.6 with grsecurity-2.1.10-2.6.21.5-200706182032.patch). I have found some reports here about similar bugs (but for x86, and they may not be related at all, it's just my wild guess), but no apparent solution.

Code: Select all

------------[ cut here ]------------
kernel BUG at mm/mmap.c:2209!
invalid opcode: 0000 [1]
CPU 0
Modules linked in: kqemu
Pid: 24213, comm: sshd Not tainted 2.6.21.6-grsec #1
RIP: 0010:[<ffffffff802336d8>]  [<ffffffff802336d8>]
RSP: 0000:ffff810004125d28  EFLAGS: 00010202
RAX: 0000000000000000 RBX: ffff810004125d30 RCX: 000000000000000b
RDX: 0000000000000068 RSI: ffff810012e14348 RDI: ffff810001eb3cc0
RBP: 0000000000000000 R08: 0000000000000000 R09: ffff81003b6cca40
R10: 000000000000001e R11: ffff81002693c820 R12: ffff81003b6cca40
R13: 000000000000000b R14: ffff810004125ef8 R15: ffff81002693cde8
FS:  00003aaa21c2a8c0(0000) GS:ffffffff8079d000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000037572000 CR4: 00000000000006e0
Process sshd (pid: 24213, threadinfo ffff810004124000, task ffff81002693c820)
Stack:  00000000000000ef ffffffff807f9aa0 ffff81003b6cca40 ffff81002693c820
 0000000000000001 ffffffff80235530 000000000000000b ffffffff8021385e
 ffff810004125d60 0000749701fda9d0 ffff81002693c820 000000000000000b
Call Trace:
 [<ffffffff80235530>]
 [<ffffffff8021385e>]
 [<ffffffff802402d5>]
 [<ffffffff802275b0>]
 [<ffffffff8024f77d>]
 [<ffffffff8020a3c8>]
 [<ffffffff802814f9>]
 [<ffffffff80252978>]


Code: 0f 0b eb fe 5e 5f 5b 5d 41 5c c3 53 48 89 fb 0f ba 37 11 19
RIP  [<ffffffff802336d8>]
 RSP <ffff810004125d28>
Fixing recursive fault but reboot is needed!


And after a while, another bug, but that may be fallout from previous issue...

Code: Select all

------------[ cut here ]------------
kernel BUG at mm/rmap.c:609!
invalid opcode: 0000 [2]
CPU 0
Modules linked in: kqemu
Pid: 22049, comm: sshd Not tainted 2.6.21.6-grsec #1
RIP: 0010:[<ffffffff8020a46e>]  [<ffffffff8020a46e>]
RSP: 0018:ffff81003a515e08  EFLAGS: 00010296
RAX: 0000000000000026 RBX: ffff810001011950 RCX: 0000000000000000
RDX: 0000000000000092 RSI: ffffffff8069f0b3 RDI: ffff810039dfd7a0
RBP: 0000000000506600 R08: 0000000000000000 R09: 0000000000000010
R10: 000000000000001e R11: 0000000000000000 R12: 0000323370c00000
R13: ffff810011976000 R14: 0000323370cb7000 R15: 0000323370cb7000
FS:  00003233709998c0(0000) GS:ffffffff8079d000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000008fd948 CR3: 00000000189a4000 CR4: 00000000000006e0
Process sshd (pid: 22049, threadinfo ffff81003a514000, task ffff8100098dc7a0)
Stack:  ffff810001011950 ffffffff802078df ffff810021de9800 0000000000000000
 ffff81003a515ee8 ffffffffffffffff 0000000000000000 ffff81000513dc38
 ffff81003a515ef0 000000000018b9fe 0000000000000000 0000000100000000
Call Trace:
 [<ffffffff802078df>]
 [<ffffffff80233672>]
 [<ffffffff80235530>]
 [<ffffffff8021385e>]
 [<ffffffff802402d5>]
 [<ffffffff8025239e>]


Code: 0f 0b eb fe 48 8b 17 8b 47 18 48 c1 ea 3e 83 e0 01 48 69 d2
RIP  [<ffffffff8020a46e>]
 RSP <ffff81003a515e08>
Fixing recursive fault but reboot is needed!


Interesting thing is that that this issue happened always in sshd process, both previously and now, but I'm not sure that it means anything. Damaged process remains in "Ds" state. Does anyone know how to fix this? Or how can I help to fix it?

I have forgotten to add that this is not qemu related, because it happened without it previously...

fissie wrote:I have found some reports here about similar bugs (but for x86, and they may not be related at all, it's just my wild guess), but no apparent solution.

can you upgrade to 2.6.23 and see if you still have the problem?

PaX Team wrote:

fissie wrote:I have found some reports here about similar bugs (but for x86, and they may not be related at all, it's just my wild guess), but no apparent solution.

can you upgrade to 2.6.23 and see if you still have the problem?

I can try that, but it is so rare that it may appear after another month or two...

PaX Team wrote:can you upgrade to 2.6.23 and see if you still have the problem?

Before I do it... Is there reason to believe this will really help, such as some related bugfix, or will it be just blind attempt?

Other option:
it saves the maintainer the trouble of maintaining an old patch with known errors.
(If no errors in pax than perhaps in the vanilla kernel.)

fissie wrote:

PaX Team wrote:can you upgrade to 2.6.23 and see if you still have the problem?

Before I do it... Is there reason to believe this will really help, such as some related bugfix, or will it be just blind attempt?

the main reason is that we don't support such an older kernel anymore, there has been just too many changes on both our side and in mainline as well, the effort of trying to figure out what goes wrong in .21 is better spent on .23 now.

PaX Team wrote:

fissie wrote:

PaX Team wrote:can you upgrade to 2.6.23 and see if you still have the problem?

Before I do it... Is there reason to believe this will really help, such as some related bugfix, or will it be just blind attempt?

the main reason is that we don't support such an older kernel anymore, there has been just too many changes on both our side and in mainline as well, the effort of trying to figure out what goes wrong in .21 is better spent on .23 now.

Why do you support the "newest" vanilla kernel ?

Why don't you support rather (?) 2.6.16.x, or 2.6.20.x or a kernel of a "stable" linux distribution ?

Oscon wrote:Why do you support the "newest" vanilla kernel ?

Why don't you support rather (?) 2.6.16.x, or 2.6.20.x or a kernel of a "stable" linux distribution ?

because we have only so much free time for this.