Bug 230144 - LSPP: panic in audit_receive filter
LSPP: panic in audit_receive filter
Status: CLOSED DUPLICATE of bug 228366
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Paris
Brian Brock
:
Depends On:
Blocks: RHEL5LSPPCertTracker
  Show dependency treegraph
 
Reported: 2007-02-26 15:56 EST by Eric Paris
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-05 16:54:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eric Paris 2007-02-26 15:56:08 EST
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.
Comment 1 Eric Paris 2007-02-26 15:57:08 EST
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
Comment 2 Eric Paris 2007-02-26 16:08:30 EST
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
Comment 3 Eric Paris 2007-02-26 16:19:22 EST
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
Comment 4 Eric Paris 2007-02-27 15:08:05 EST
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.
Comment 5 Eric Paris 2007-02-27 15:26:38 EST
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.
Comment 6 Eric Paris 2007-03-05 16:54:55 EST
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 ***

Note You need to log in before you can comment on or make changes to this bug.