2.6.22x Oops caused by ident server

felosi · 09-16-2007, 06:13 AM

I searched up on this, seems a new issue with servers running ident daemons.
Here is the oops I get, Im running oidentd as user proc, grsecurity kernel

Code:

[245167.306141] BUG: unable to handle kernel NULL pointer dereference<1>BUG: unable to handle kernel NULL pointer dereference at virtual address 00000054
[245167.306147]  printing eip:
[245167.306148] c05a8beb
[245167.306149] *pde = 00000000
[245167.306151] Oops: 0000 [#1]
[245167.306152] SMP
[245167.306154] Modules linked in: loop nf_conntrack_ipv4 ipt_owner xt_conntrack iptable_mangle nf_conntrack_ftp ipt_REJECT ipt_LOG xt_limit xt_multiport xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables autofs4 ipv6 dm_mirror dm_mod shpchp i2c_i801 i2c_core e1000 piix ide_generic ext3 jbd ide_disk ide_core ata_piix libata sd_mod scsi_mod
[245167.306172] CPU:    0
[245167.306172] EIP:    0060:[<c05a8beb>]    Not tainted VLI
[245167.306173] EFLAGS: 00010296   (2.6.22.2-grsec #1)
[245167.306178] EIP is at netlink_run_queue+0x2b/0x110
[245167.306180] eax: 00000000   ebx: c9a7dc00   ecx: 00000000   edx: 00000292
[245167.306182] esi: f3161c00   edi: ce121cf0   ebp: f7f53c6c   esp: ce121cd8
[245167.306183] ds: 0068   es: 007b   fs: 00d8  gs: 0033  ss: 0068
[245167.306185] Process oidentd (pid: 15114, ti=ce120000 task=d9e55030 task.ti=ce120000)
[245167.306187] Stack: c05e86c0 f7f53c00 0000004c 00000000 ce121f40 c05e7bce 00000001 f7f53c00
[245167.306190]        0000004c c05a91d2 0000004c f7f53c00 c05a7e01 00000000 ce121ee0 c05a90d7
[245167.306194]        00000000 f7f43558 ce121e60 f30c4e00 00000000 00000000 f3161cc0 ce121df0
[245167.306197] Call Trace:
[245167.306199]  [<c05e86c0>] inet_diag_rcv_msg+0x0/0x5a0
[245167.306208]  [<c05e7bce>] inet_diag_rcv+0x1e/0x30
[245167.306214]  [<c05a91d2>] netlink_data_ready+0x12/0x50
[245167.306218]  [<c05a7e01>] netlink_sendskb+0x21/0x40
[245167.306223]  [<c05a90d7>] netlink_sendmsg+0x227/0x310
[245167.306246]  [<c0587082>] sock_sendmsg+0x112/0x130
[245167.306269]  [<c0433e20>] autoremove_wake_function+0x0/0x50
[245167.306277]  [<c05ffe88>] _spin_lock_bh+0x8/0x20
[245167.306286]  [<c05ffe88>] _spin_lock_bh+0x8/0x20
[245167.306289]  [<c0589562>] release_sock+0x12/0xa0
[245167.306295]  [<c05bea16>] tcp_recvmsg+0x3d6/0xb40
[245167.306319]  [<c0587201>] sys_sendmsg+0x161/0x270
[245167.306355]  [<c0451620>] find_get_page+0x20/0x60
[245167.306360]  [<c0453fc2>] filemap_nopage+0x182/0x330
[245167.306377]  [<c045f0bf>] __handle_mm_fault+0x22f/0x940
[245167.306382]  [<c0433e20>] autoremove_wake_function+0x0/0x50
[245167.306408]  [<c05889e4>] sys_socketcall+0x284/0x2b0
[245167.306426]  [<c0402ed9>] sysenter_past_esp+0x66/0x95
[245167.306439]  [<c0600000>] unlock_kernel+0x30/0x40
[245167.306451]  =======================
[245167.306452] Code: 55 57 89 d7 56 53 89 c3 83 ec 04 89 0c 24 8b 02 85 c0 0f 84 b3 00 00 00 3b 43 74 8d 6b 6c 0f 87 a7 00 00 00 89 e8 e8 a5 3d fe ff <8b> 50 54 89 c6 83 fa 0f 76 4b 8b 98 a4 00 00 00 8b 03 83 f8 0f
[245167.306468] EIP: [<c05a8beb>] netlink_run_queue+0x2b/0x110 SS:ESP 0068:ce121cd8
[245167.307475]  at virtual address 00000054
[245167.307506]  printing eip:
[245167.307536] c05a8beb
[245167.307566] *pde = 00000000
[245167.308169] Oops: 0000 [#2]
[245167.308199] SMP
[245167.308264] Modules linked in: loop nf_conntrack_ipv4 ipt_owner xt_conntrack iptable_mangle nf_conntrack_ftp ipt_REJECT ipt_LOG xt_limit xt_multiport xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables autofs4 ipv6 dm_mirror dm_mod shpchp i2c_i801 i2c_core e1000 piix ide_generic ext3 jbd ide_disk ide_core ata_piix libata sd_mod scsi_mod
[245167.309156] CPU:    1
[245167.309157] EIP:    0060:[<c05a8beb>]    Not tainted VLI
[245167.309158] EFLAGS: 00010296   (2.6.22.2-grsec #1)
[245167.309268] EIP is at netlink_run_queue+0x2b/0x110
[245167.309306] eax: 00000000   ebx: ec35b000   ecx: 00000000   edx: 00000292
[245167.309342] esi: f3161cc0   edi: d89cbcf0   ebp: f7f53c6c   esp: d89cbcd8
[245167.309389] ds: 0068   es: 007b   fs: 00d8  gs: 0033  ss: 0068
[245167.309426] Process oidentd (pid: 15113, ti=d89ca000 task=c22da560 task.ti=d89ca000)
[245167.309467] Stack: c05e86c0 f7f53c00 0000004c 00000000 d89cbf40 c05e7bce 00000001 f7f53c00
[245167.309719]        0000004c c05a91d2 0000004c f7f53c00 c05a7e01 00000000 d89cbee0 c05a90d7
[245167.309967]        00000000 f7f43558 d89cbe60 f30c4e00 00000000 00000000 f3161c00 d89cbdf0
[245167.310219] Call Trace:
[245167.310286]  [<c05e86c0>] inet_diag_rcv_msg+0x0/0x5a0
[245167.310349]  [<c05e7bce>] inet_diag_rcv+0x1e/0x30
[245167.310416]  [<c05a91d2>] netlink_data_ready+0x12/0x50
[245167.310474]  [<c05a7e01>] netlink_sendskb+0x21/0x40
[245167.310529]  [<c05a90d7>] netlink_sendmsg+0x227/0x310
[245167.310602]  [<c0587082>] sock_sendmsg+0x112/0x130
[245167.310670]  [<c0433e20>] autoremove_wake_function+0x0/0x50
[245167.310741]  [<c05ffe88>] _spin_lock_bh+0x8/0x20
[245167.310804]  [<c05ffe88>] _spin_lock_bh+0x8/0x20
[245167.310863]  [<c0589562>] release_sock+0x12/0xa0
[245167.310929]  [<c05bea16>] tcp_recvmsg+0x3d6/0xb40
[245167.311008]  [<c0587201>] sys_sendmsg+0x161/0x270
[245167.311090]  [<c0451620>] find_get_page+0x20/0x60
[245167.311143]  [<c0453fc2>] filemap_nopage+0x182/0x330
[245167.311208]  [<c045f0bf>] __handle_mm_fault+0x22f/0x940
[245167.311260]  [<c0433e20>] autoremove_wake_function+0x0/0x50
[245167.311335]  [<c05889e4>] sys_socketcall+0x284/0x2b0
[245167.311401]  [<c0402ed9>] sysenter_past_esp+0x66/0x95
[245167.311462]  [<c0600000>] unlock_kernel+0x30/0x40
[245167.311521]  =======================
[245167.311551] Code: 55 57 89 d7 56 53 89 c3 83 ec 04 89 0c 24 8b 02 85 c0 0f 84 b3 00 00 00 3b 43 74 8d 6b 6c 0f 87 a7 00 00 00 89 e8 e8 a5 3d fe ff <8b> 50 54 89 c6 83 fa 0f 76 4b 8b 98 a4 00 00 00 8b 03 83 f8 0f
[245167.312793] EIP: [<c05a8beb>] netlink_run_queue+0x2b/0x110 SS:ESP 0068:d89cbcd8

osor · 09-17-2007, 05:56 PM

Does it work without grsecurity? If so, the bug most likely lies in grsec itself, and the best approach is to take it up at the fora/ml there or email spender.

felosi · 09-23-2007, 03:29 AM

Quote:

Originally Posted by osor

Does it work without grsecurity? If so, the bug most likely lies in grsec itself, and the best approach is to take it up at the fora/ml there or email spender.

Sorry for late reply. Well the oddest thing is it doesnt do this on centos 5 which there is a lot less ident lookups on my centos 5 boxes.

It finally just stopped doing it for some reason. I didnt have the ident user set right under grsec, thought it just didnt work but i made a mistake so I had oidentd running as user proc with ownership or proc, like someone had posted on grsec forums.

So this may have been causing this.

But I tell you what, on the centos 4 boxes these 2.6.22x kernels just havent cut it, lots of errors, Well mainly the ident oops and there was a problem with quotacheck and quotaon that would nearly crash teh box when ran.

So I reverted back to grsec2.6.19.2 and everything has been fine. Maybe some libs or something in centos 5 not agreeing with the new kernel.