Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 230144

Summary:	LSPP: panic in audit_receive filter
Product:	Red Hat Enterprise Linux 5	Reporter:	Eric Paris <eparis>
Component:	kernel	Assignee:	Eric Paris <eparis>
Status:	CLOSED DUPLICATE	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.0	CC:	amy.griffis, iboverma, krisw, linda.knippers, sgrubb
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-03-05 21:54:55 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	224041

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 ***