LSPP kernel.67 panics when 2 audit rules are added to audit.rules -w /etc/localtime -a always,exit -S sethostname Working on why right now, but it is reproducable. I expect this is going to be related to some of the audit changes since GA, but I don't know yet and I don't want to forget about this bug.
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: *pde = 2d4e9001 Oops: 0000 [#1] SMP last sysfs file: /class/net/eth0/address Modules linked in: video sbs i2c_ec button battery asus_acpi ac parport_pc lp parport floppy sg i2c_piix4 pcspkr i2c_core pcnet32 mii ide_cd cdrom serio_raw dm_snapshot dm_zero dm_mirror dm_mod mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd CPU: 1 EIP: 0060:[<c044a7ba>] Not tainted VLI EFLAGS: 00010246 (2.6.18-8.el5.lspp.67PAE #1) EIP is at audit_receive_filter+0x62f/0x9d1 eax: ffffffff ebx: 00000000 ecx: 00000000 edx: 00000000 esi: f0650488 edi: 00000001 ebp: ed9bcb78 esp: ed9a0cb0 ds: 007b es: 007b ss: 0068 Process auditctl (pid: 1327, ti=ed9a0000 task=ef40d530 task.ti=ed9a0000) Stack: ed9bcb88 0000052f ed9a0d08 ed9bcb78 ecdab838 ecdab8c4 ecfff854 ed9a0cd0 00000003 00000000 0000001e ecfff854 00000004 00000000 00000000 00000000 f036e32c 00000430 000503f3 000003f3 c0448754 00000005 f036e33c 00000420 Call Trace: [<c0448754>] audit_receive+0x6be/0x823 [<c05a8a40>] skb_queue_tail+0x11/0x2d [<c0608031>] _spin_unlock_irqrestore+0x34/0x39 [<c05c1458>] netlink_data_ready+0xf/0x4a [<c05c04ee>] netlink_sendskb+0x1c/0x33 [<c05c143c>] netlink_sendmsg+0x277/0x284 [<c05a43a9>] sock_sendmsg+0xce/0xe8 [<c043a482>] find_usage_backwards+0x64/0x88 [<c0435ef3>] autoremove_wake_function+0x0/0x2d [<c0607fd7>] _spin_unlock_irq+0x20/0x23 [<c045eafb>] __handle_mm_fault+0xb5b/0xb93 [<c04e72b2>] copy_from_user+0x40/0x6c [<c05a55c8>] sys_sendto+0x116/0x140 [<c043b8a0>] __lock_acquire+0x927/0x970 [<c05a5eef>] sys_socketcall+0x106/0x19e [<c0403f7b>] syscall_call+0x7/0xb ======================= Code: 83 7c 24 30 05 0f 95 c0 01 05 60 a6 9b c0 8b 35 40 a6 9b c0 31 c9 31 d2 8b 1d 44 a6 9b c0 8b 6c 24 0c 8b 44 2a 20 85 04 32 75 05 <85> 04 1a 74 06 ff 05 64 a6 9b c0 41 83 c2 04 83 f9 40 75 df b8 EIP: [<c044a7ba>] audit_receive_filter+0x62f/0x9d1 SS:ESP 0068:ed9a0cb0 <0>Kernel panic - not syncing: Fatal exception
appears to be between /usr/src/debug/kernel-2.6.18/linux-2.6.18.i686/kernel/auditfilter.c: 1227 /usr/src/debug/kernel-2.6.18/linux-2.6.18.i686/kernel/auditfilter.c: 1229 /usr/src/debug/kernel-2.6.18/linux-2.6.18.i686/kernel/auditfilter.c: 1227 0xc044a7ad <audit_receive_filter+1570>: mov 0xc(%esp),%ebp 0xc044a7b1 <audit_receive_filter+1574>: mov 0x20(%edx,%ebp,1),%eax 0xc044a7b5 <audit_receive_filter+1578>: test %eax,(%edx,%esi,1) 0xc044a7b8 <audit_receive_filter+1581>: jne 0xc044a7bf <audit_receive_filter+1588> 0xc044a7ba <audit_receive_filter+1583>: test %eax,(%edx,%ebx,1) 0xc044a7bd <audit_receive_filter+1586>: je 0xc044a7c5 <audit_receive_filter+1594> /usr/src/debug/kernel-2.6.18/linux-2.6.18.i686/kernel/auditfilter.c: 1229 0xc044a7bf <audit_receive_filter+1588>: incl 0xc09ba664 /usr/src/debug/kernel-2.6.18/linux-2.6.18.i686/kernel/auditfilter.c: 1226
1225: #ifdef CONFIG_AUDITSYSCALL 1226: if (!dont_count) 1227: audit_n_rules++; 1228: 1229: for (i = 0; i < AUDIT_BITMASK_SIZE; i++) 1230: if ((entry->rule.mask[i] & classes[AUDIT_CLASS_SIGNAL][i]) || 1231: (entry->rule.mask[i] & classes[AUDIT_CLASS_SIGNAL_32][i])) 1232: audit_signals++; 1233: #endif
Not sure how the line numbers in crash are off, but it doesn't really matter. Looks like the crash is actually happening on the following line: 1231: (entry->rule.mask[i] & classes[AUDIT_CLASS_SIGNAL_32][i])) 0xc044a7b8 appears to me to be the previous line with AUDIT_CLASS_SIGNAL On a 32 bit arch is both AUDIT_CLASS_SIGNAL and AUDIT_CLASS_SIGNAL_32 defined? I believe they would be defined on all arches with both 64/32 options, such as ppc, x86_64, ia64 and such, but i don't remember if both exist on a 32 bit only arch. Going to look now.
Looks like audit_classes_init in lib/audit.c is what is used by i686. And it doesn't define all the _32 classes. I'll go to look at how the other things like this are used.
Closing as a dupe of 228366 It's not a dup, but it is caused by that patch. So closing. *** This bug has been marked as a duplicate of 228366 ***