Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 230144 - LSPP: panic in audit_receive filter
Summary: LSPP: panic in audit_receive filter
Keywords:
Status: CLOSED DUPLICATE of bug 228366
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Eric Paris
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: RHEL5LSPPCertTracker
TreeView+ depends on / blocked
 
Reported: 2007-02-26 20:56 UTC by Eric Paris
Modified: 2007-11-30 22:07 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-03-05 21:54:55 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Eric Paris 2007-02-26 20:56:08 UTC
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 20:57:08 UTC
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 21:08:30 UTC
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 21:19:22 UTC
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 20:08:05 UTC
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 20:26:38 UTC
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 21:54:55 UTC
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.