11:39 a.m.
Nothing particularly exciting here -- mostly just a few patches cleaned
up for sending them upstream. There's a whole bunch of userspace stuff
in the yum repository too.
* Wed Jun 22 2005 David Woodhouse <dwmw2(a)redhat.com> audit.66
- Revamp backlog wait patch for upstream -- add gfp_mask
- Allow USER_AVC messages when audit_enabled == 0
- Clean up threaded listing of rules and watches
--
dwmw2
3:01 p.m.
On Wednesday 22 June 2005 12:39, David Woodhouse wrote:
Nothing particularly exciting here -- mostly just a few patches
cleaned
up for sending them upstream.
This Oopsed in about 5 minutes of testing.
Jun 22 15:39:21 localhost kernel: Unable to handle kernel NULL pointer dereference at
virtual address 00000000
Jun 22 15:39:21 localhost kernel: printing eip:
Jun 22 15:39:21 localhost kernel: c01430b1
Jun 22 15:39:21 localhost kernel: *pde = 00000000
Jun 22 15:39:21 localhost kernel: Oops: 0000 [#1]
Jun 22 15:39:21 localhost kernel: Modules linked in: tun parport_pc lp parport autofs4
i2c_dev i2c_core ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables dm_mod button
battery ac md5 ipv6 uhci_hcd snd_emu10k1 snd_rawmidi snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer snd_seq_device snd_ac97_codec snd_page_alloc snd_util_mem snd_hwdep snd
soundcore 3c59x floppy ext3 jbd
Jun 22 15:39:21 localhost kernel: CPU: 0
Jun 22 15:39:21 localhost kernel: EIP: 0060:[<c01430b1>] Not tainted VLI
Jun 22 15:39:21 localhost kernel: EFLAGS: 00210246 (2.6.9-11.EL.audit.66)
Jun 22 15:39:21 localhost kernel: EIP is at auditfs_attach_wdata+0x2c6/0x401
Jun 22 15:39:21 localhost kernel: eax: 0000000f ebx: db44af3c ecx: 00200246 edx:
e1cc73e8
Jun 22 15:39:21 localhost kernel: esi: 00000000 edi: e57aea04 ebp: e1cc73e8 esp:
d9c4aea0
Jun 22 15:39:21 localhost kernel: ds: 007b es: 007b ss: 0068
Jun 22 15:39:21 localhost kernel: Process auditctl (pid: 29062, threadinfo=d9c4a000
task=e14278b0)
Jun 22 15:39:21 localhost kernel: Stack: dd586498 00000001 da4bfe14 ee8ca408 da4bfe08
ee8ca408 00000001 d9c4af60
Jun 22 15:39:21 localhost kernel: c014538f fffffff5 ee8ca408 00000001 c0175c18
fffffff5 ee8ca408 0024a603
Jun 22 15:39:21 localhost kernel: d9c4af60 c01763db 00000000 c014d4a7 5a6ea9e0
ef6a2000 00000401 00000000
Jun 22 15:39:21 localhost kernel: Call Trace:
Jun 22 15:39:21 localhost kernel: [<c014538f>] audit_notify_watch+0x47/0x55
Jun 22 15:39:21 localhost kernel: [<c0175c18>] permission+0xf/0x4f
Jun 22 15:39:21 localhost kernel: [<c01763db>] link_path_walk+0x12c/0xd98
Jun 22 15:39:21 localhost kernel: [<c014d4a7>] poison_obj+0x1d/0x3d
Jun 22 15:39:21 localhost kernel: [<c01772c7>] path_lookup+0x104/0x135
Jun 22 15:39:21 localhost kernel: [<c017740c>] __user_walk+0x21/0x51
Jun 22 15:39:21 localhost kernel: [<c0165bc0>] sys_access+0x8f/0x134
Jun 22 15:39:21 localhost kernel: [<c010b757>] do_syscall_trace+0xc0/0xc9
Jun 22 15:39:21 localhost kernel: [<c030797f>] syscall_call+0x7/0xb
Jun 22 15:39:21 localhost kernel: Code: e9 38 fe ff ff 89 e8 e8 80 0b 00 00 8b 54 24 08 8b
32 85 f6 74 0e 8b 06 0f 18 00 90 8b 5f 08 8d 6e ec eb d8 89 e8 e8 61 0b 00 00 <8b>
36 85 f6 0f 85 ff fd ff ff 81 3d c8 69 35 c0 3c 4b 24 1d 74
Jun 22 15:39:21 localhost kernel: <0>Fatal exception: panic in 5 seconds
3:56 p.m.
On Wednesday 22 June 2005 16:50, David Woodhouse wrote:
What were you doing?
I was running my fs-torture script at the same time as running the enabler
script.
Can you reproduce on audit.65?
I tried and .65 never did it. I was using the new and improved auditctl which
is a little faster. Maybe .65 would have done it if I hit the problem just
right.
-Steve
5:15 p.m.
On Wednesday 22 June 2005 16:50, David Woodhouse wrote:
Can you reproduce on audit.65?
Yep...here it is:
Jun 22 18:08:58 localhost kernel: Unable to handle kernel NULL pointer dereference at
virtual address 00000000
Jun 22 18:08:58 localhost kernel: printing eip:
Jun 22 18:08:58 localhost kernel: c01430ad
Jun 22 18:08:58 localhost kernel: *pde = 00000000
Jun 22 18:08:58 localhost kernel: Oops: 0000 [#1]
Jun 22 18:08:58 localhost kernel: Modules linked in: tun parport_pc lp parport autofs4
i2c_dev i2c_core ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables dm_mod button
battery ac md5 ipv6 uhci_hcd snd_emu10k1 snd_rawmidi snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer snd_seq_device snd_ac97_codec snd_page_alloc snd_util_mem snd_hwdep snd
soundcore 3c59x floppy ext3 jbd
Jun 22 18:08:58 localhost kernel: CPU: 0
Jun 22 18:08:58 localhost kernel: EIP: 0060:[<c01430ad>] Not tainted VLI
Jun 22 18:08:58 localhost kernel: EFLAGS: 00210246 (2.6.9-11.EL.audit.65)
Jun 22 18:08:58 localhost kernel: EIP is at auditfs_attach_wdata+0x2c6/0x401
Jun 22 18:08:58 localhost kernel: eax: 0000000f ebx: d9f6be08 ecx: 00200246 edx:
e1ec4154
Jun 22 18:08:58 localhost kernel: esi: 00000000 edi: de61fbcc ebp: e1ec4154 esp:
da9e8e84
Jun 22 18:08:58 localhost kernel: ds: 007b es: 007b ss: 0068
Jun 22 18:08:58 localhost kernel: Process auditctl (pid: 19613, threadinfo=da9e8000
task=ddaecd50)
Jun 22 18:08:58 localhost kernel: Stack: e1f1438c 00000001 e01d22e8 ee893408 e01d22dc
ee893408 00000001 da9e8f58
Jun 22 18:08:58 localhost kernel: c0145313 fffffff5 ee893408 00000001 c0175b9c
fffffff5 ee893408 0024a603
Jun 22 18:08:58 localhost kernel: da9e8f58 c017635f 00a9b066 dfdab008 e0a59370
c0156eae 00000101 00000000
Jun 22 18:08:58 localhost kernel: Call Trace:
Jun 22 18:08:58 localhost kernel: [<c0145313>] audit_notify_watch+0x47/0x55
Jun 22 18:08:58 localhost kernel: [<c0175b9c>] permission+0xf/0x4f
Jun 22 18:08:58 localhost kernel: [<c017635f>] link_path_walk+0x12c/0xd98
Jun 22 18:08:58 localhost kernel: [<c0156eae>] handle_mm_fault+0xd5/0x1fd
Jun 22 18:08:58 localhost kernel: [<c017724b>] path_lookup+0x104/0x135
Jun 22 18:08:58 localhost kernel: [<c017793f>] open_namei+0x99/0x57e
Jun 22 18:08:58 localhost kernel: [<c01660c7>] filp_open+0x23/0x3c
Jun 22 18:08:58 localhost kernel: [<c03060a0>] __cond_resched+0x14/0x3b
Jun 22 18:08:58 localhost kernel: [<c01de50a>] direct_strncpy_from_user+0x3e/0x5d
Jun 22 18:08:58 localhost kernel: [<c016659e>] sys_open+0x31/0x7d
Jun 22 18:08:58 localhost kernel: [<c03078fb>] syscall_call+0x7/0xb
Jun 22 18:08:58 localhost kernel: Code: e9 38 fe ff ff 89 e8 e8 7b 0b 00 00 8b 54 24 08 8b
32 85 f6 74 0e 8b 06 0f 18 00 90 8b 5f 08 8d 6e ec eb d8 89 e8 e8 5c 0b 00 00 <8b>
36 85 f6 0f 85 ff fd ff ff 81 3d c8 69 35 c0 3c 4b 24 1d 74
Jun 22 18:08:58 localhost kernel: <0>Fatal exception: panic in 5 seconds
10:05 a.m.
On Wed, 2005-06-22 at 18:15 -0400, Steve Grubb wrote:
Jun 22 18:08:58 localhost kernel: EIP is at auditfs_attach_wdata
+0x2c6/0x401
OK, I think I have it. It was an error in my attempt to handle watches
going away while we're in auditfs_attach_wdata().
If that happens we start again at the beginning of the inode's watch
list, and jump back in to the main loop as soon as we find a watch which
hadn't already been dealt with.
But in the case where there _were_ no more watches to be dealt with, we
should break out of the main loop immediately. We were falling through
and ending up on the hlist_for_each_entry() loop with watch == NULL. It
was oopsing when it tried to fetch watch->w_watched.next.
Testing with this... will build audit.$next without the printk.
--- linux-2.6.9/kernel/auditsc.c 2005-06-24 15:20:38.000000000 +0100
+++ linux-2.6.9/kernel/auditsc.c 2005-06-24 15:51:32.000000000 +0100
@@ -1365,6 +1365,9 @@ void auditfs_attach_wdata(struct inode *
pick up where we left off. */
goto restart;
}
+ /* We'd actually covered every watch that still exists. */
+ printk("Fell off end. Would die. Shan't\n");
+ break;
}
audit_watch_put(watch);
}
--
dwmw2
7120
days inactive
7122
days old
linux-audit@lists.linux-audit.osci.io
5 comments
2 participants
participants (2)
-
David Woodhouse -
Steve Grubb