9:09 a.m.
* Thu May 25 2005 David Woodhouse <dwmw2(a)redhat.com> audit.50
- Defer freeing of aux items to audit_free_aux()
- Remove items from hlist in audit_list_watches()
- Abolish inode->i_audit in favour of hash table
--
dwmw2
9:40 a.m.
On Thursday 26 May 2005 10:09, David Woodhouse wrote:
* Thu May 25 2005 David Woodhouse <dwmw2(a)redhat.com> audit.50
This oopsed in about 10 seconds. I started my script from yesterday and let it run for a
few seconds and opened kmail. Immediately oopsed.
May 26 10:27:12 localhost kernel: Unable to handle kernel NULL pointer dereference at
virtual address 00000008
May 26 10:27:12 localhost kernel: printing eip:
May 26 10:27:12 localhost kernel: c0141fc8
May 26 10:27:12 localhost kernel: *pde = 1fe22067
May 26 10:27:12 localhost kernel: Oops: 0000 [#1]
May 26 10:27:12 localhost kernel: Modules linked in: 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
May 26 10:27:12 localhost kernel: CPU: 0
May 26 10:27:12 localhost kernel: EIP: 0060:[<c0141fc8>] Not tainted VLI
May 26 10:27:12 localhost kernel: EFLAGS: 00210246 (2.6.9-5.0.3.EL.audit.50)
May 26 10:27:12 localhost kernel: EIP is at audit_update_watch+0x26c/0x2c5
May 26 10:27:12 localhost kernel: eax: 00000000 ebx: e615d630 ecx: e615d6b4 edx:
00000000
May 26 10:27:12 localhost kernel: esi: e5089ee0 edi: e615d6a8 ebp: 00000000 esp:
e18cae80
May 26 10:27:12 localhost kernel: ds: 007b es: 007b ss: 0068
May 26 10:27:12 localhost kernel: Process kded (pid: 2779, threadinfo=e18ca000
task=e18a11e0)
May 26 10:27:12 localhost kernel: Stack: 00000000 00000000 00000000 e615d630 e18caf60
e615d6a8 e615d6d8 c017eddb
May 26 10:27:12 localhost kernel: e615d630 c16928e4 ef07e022 cd0f9ab0 00000007
e18caf10 cd0f9ab0 e18caf60
May 26 10:27:12 localhost kernel: 00000000 e18caf10 c01730c3 eff02aa0 e18caf08
cd0f9ab0 e6dd8284 cd0f9ab0
May 26 10:27:12 localhost kernel: Call Trace:
May 26 10:27:12 localhost kernel: [<c017eddb>] __d_lookup+0x145/0x1ef
May 26 10:27:12 localhost kernel: [<c01730c3>] do_lookup+0x1f/0x8f
May 26 10:27:12 localhost kernel: [<c0173b6c>] link_path_walk+0xa39/0xd98
May 26 10:27:12 localhost kernel: [<c016ee1d>] cp_new_stat64+0x124/0x139
May 26 10:27:12 localhost kernel: [<c0174145>] path_lookup+0xfe/0x12c
gdb says:
(gdb) list *0xc0141fc8
0xc0141fc8 is in audit_update_watch (kernel/auditfs.c:542).
537 kernel/auditfs.c: No such file or directory.
in kernel/auditfs.c
9:56 a.m.
On Thu, 2005-05-26 at 10:40 -0400, Steve Grubb wrote:
0xc0141fc8 is in audit_update_watch (kernel/auditfs.c:542).
Hm. That's the first time we deference the inode's audit data after
calling audit_inode_data() to fetch it from the hash table. For some
reason it's not being found.
Can you build you a kernel with this in, or should I build it?
--- linux-2.6.9/kernel/auditfs.c~ 2005-05-26 12:50:13.000000000 +0100
+++ linux-2.6.9/kernel/auditfs.c 2005-05-26 15:51:51.000000000 +0100
@@ -75,6 +75,16 @@ struct audit_inode_data *inode_audit_dat
if (*list && (*list)->inode == inode)
ret = *list;
+ if (!ret) {
+ /* Hm. At the moment, we should never see an inode which doesn't have audit data
*/
+ printk("Hm. No audit data for inode %p. Hash bucket for hash %d
follows...\n", inode, h);
+ list = &auditfs_hash_table[h];
+ while (*list) {
+ printk("ino=%p data=%p\n", (*list)->inode, *list);
+ list = &(*list->next_hash);
+ }
+ }
+
spin_unlock(&auditfs_hash_lock);
return ret;
}
@@ -525,6 +535,11 @@ void audit_update_watch(struct dentry *d
return;
data = inode_audit_data(dentry->d_inode);
+ if (!data) {
+ printk(KERN_WARNING "Hmmm. No audit data for inode #%lu at %p. name %s\n",
+ dentry->d_inode->i_ino, dentry->d_inode, dentry->d_name.name);
+ return;
+ }
parent = inode_audit_data(dentry->d_parent->d_inode);
wentry = audit_wentry_fetch_lock(dentry->d_name.name, parent);
--
dwmw2
9:54 a.m.
Is the .50 kernel based on this:
Posted is the latest U1 candidate kernel to the partners.redhat.com
site.
As far as I know, this is the final kernel pending a disaster occurring.
10:06 a.m.
On Thursday 26 May 2005 09:09, David Woodhouse wrote:
* Thu May 25 2005 David Woodhouse <dwmw2(a)redhat.com> audit.50
- Defer freeing of aux items to audit_free_aux()
- Remove items from hlist in audit_list_watches()
- Abolish inode->i_audit in favour of hash table
Ok, well... I should just defer my changes to this kernel then since we're
going to have to go with the hash table anyway. Thanks for doing this by the
way.
-tim
10:07 a.m.
On Thu, 2005-05-26 at 10:06 -0500, Timothy R. Chavez wrote:
Ok, well... I should just defer my changes to this kernel then since
we're
going to have to go with the hash table anyway. Thanks for doing this by the
way.
I didn't merge the patches though -- I can still apply the hash table
thing afterwards. I was sort of expecting to have to keep that separate.
--
dwmw2
10:50 a.m.
On Thursday 26 May 2005 10:07, David Woodhouse wrote:
On Thu, 2005-05-26 at 10:06 -0500, Timothy R. Chavez wrote:
> Ok, well... I should just defer my changes to this kernel then since we're
> going to have to go with the hash table anyway. Thanks for doing this by the
> way.
I didn't merge the patches though -- I can still apply the hash table
thing afterwards. I was sort of expecting to have to keep that separate.
Well... you're building RPMs with the hash table stuff... so did you want to branch?
Because I need to be able to test and fix bugs so that I can submit to LKML. Maybe
I'm not following ya. You want one implementation (the hash table) for Redhat-only
kernels and a separate (i_audit) implementation for mainline?
-tim
10:56 a.m.
On Thu, 2005-05-26 at 10:50 -0500, Timothy R. Chavez wrote:
Well... you're building RPMs with the hash table stuff... so did
you want to branch?
Because I need to be able to test and fix bugs so that I can submit to LKML. Maybe
I'm not following ya. You want one implementation (the hash table) for Redhat-only
kernels and a separate (i_audit) implementation for mainline?
Well the theory was the hash table stuff wouldn't really affect the
testing much. So having it as an addon only in the RPM would be at least
feasible.
In fact I think it might be useful to use the hash table in the mainline
version too, and allocate each inode's audit data only on demand --
we're currently allocating it for _every_ inode at the moment when in
fact it's rarely going to be used. But I was going to make that
suggestion in 'diff -up' form instead of just waffling about it ;)
--
dwmw2
11:11 a.m.
On Thursday 26 May 2005 10:56, David Woodhouse wrote:
On Thu, 2005-05-26 at 10:50 -0500, Timothy R. Chavez wrote:
> Well... you're building RPMs with the hash table stuff... so did you want to
branch?
> Because I need to be able to test and fix bugs so that I can submit to LKML. Maybe
> I'm not following ya. You want one implementation (the hash table) for
Redhat-only
> kernels and a separate (i_audit) implementation for mainline?
Well the theory was the hash table stuff wouldn't really affect the
testing much. So having it as an addon only in the RPM would be at least
feasible.
In fact I think it might be useful to use the hash table in the mainline
version too, and allocate each inode's audit data only on demand --
we're currently allocating it for _every_ inode at the moment when in
fact it's rarely going to be used. But I was going to make that
suggestion in 'diff -up' form instead of just waffling about it ;)
I'm fine with the hash table piece. It will require more testing, yes. However,
I'd just like to get the i_audit implementation to a state where Steve can run
it and not crash ;-)... ya know, make sure I address those bugs first and
not allow them to burrow deeper.
-tim
11:19 a.m.
On Thu, 2005-05-26 at 11:11 -0500, Timothy R. Chavez wrote:
I'm fine with the hash table piece. It will require more
testing, yes. However,
I'd just like to get the i_audit implementation to a state where Steve can run
it and not crash ;-)... ya know, make sure I address those bugs first and
not allow them to burrow deeper.
OK, let's just do it then. I've asked Steve to try my debugging patch
because I can't reproduce the problem myself -- I get other memory
corruption which might in fact turn out to be related. Once I enable
CONFIG_DEBUG_SLAB I start to see problems when _all_ I do is add one
watch...
passion /root # auditctl -w /var/run/dbus/system_bus_socket -k dbus-test -p rwea
audit(1117124301.017:2): auid=4294967295 inserted watch
slab error in cache_free_debugcheck(): cache `size-32': double free, or memory outside
object was overwritten
[<c014503a>] cache_free_debugcheck+0xc7/0x1b1
[<c0145b47>] kfree+0x4f/0x83
[<c013cd37>] audit_receive_watch+0x3c3/0x3ec
[<c0132f90>] kthread_create+0xed/0xf8
[<c011c2d6>] recalc_task_prio+0x128/0x133
[<c011c7f6>] try_to_wake_up+0x225/0x230
[<c013a4ee>] audit_receive_msg+0x2b1/0x30b
[<c0143fe4>] check_poison_obj+0x28/0x177
[<c013a57a>] audit_receive_skb+0x32/0x70
[<c013a5e1>] audit_receive+0x29/0x80
[<c02886d7>] netlink_data_ready+0x14/0x44
[<c0287d9b>] netlink_sendskb+0x52/0x6c
[<c02884f2>] netlink_sendmsg+0x269/0x278
[<c026e459>] sock_sendmsg+0xdb/0xf7
[<c0141060>] buffered_rmqueue+0x17d/0x1a5
[<c011f6ee>] autoremove_wake_function+0x0/0x2d
[<c026f723>] sys_sendto+0xc7/0xe2
[<c011a65b>] do_page_fault+0x1ae/0x5b6
[<c01a1c17>] avc_has_perm_noaudit+0x2d/0xda
[<c026e1a6>] sock_map_file+0x98/0x107
[<c014cc71>] __vma_link+0x59/0x66
[<c014ccc2>] vma_link+0x44/0xbc
[<c026ff3a>] sys_socketcall+0x16a/0x1fb
[<c02c9f3b>] syscall_call+0x7/0xb
e9c168dc: redzone 1: 0x170fc2a5, redzone 2: 0x170fc200.
No rules
AUDIT_WATCH_LIST: dev=3:1, path=/var/run/dbus/system_bus_socket, filterkey=dbus-test,
perms=rwea, valid=0
passion /root #
--
dwmw2
11:39 a.m.
On Thu, 2005-05-26 at 17:19 +0100, David Woodhouse wrote:
slab error in cache_free_debugcheck(): cache `size-32': double
free,
or memory outside object was overwritten
--- linux-2.6.9/kernel/auditfs.c~ 2005-05-26 12:50:13.000000000 +0100
+++ linux-2.6.9/kernel/auditfs.c 2005-05-26 17:28:19.000000000 +0100
@@ -168,18 +178,18 @@ static inline struct audit_watch *audit_
watch->perms = t->perms;
offset = sizeof(struct watch_transport);
- watch->filterkey = kmalloc(t->fklen, GFP_KERNEL);
+ watch->filterkey = kmalloc(t->fklen+1, GFP_KERNEL);
if (!watch->filterkey)
goto audit_to_watch_fail;
- watch->filterkey[0] = 0;
- strncat(watch->filterkey, memblk + offset, t->fklen);
+ watch->filterkey[t->fklen] = 0;
+ memcpy(watch->filterkey, memblk + offset, t->fklen);
offset += t->fklen;
- watch->path = kmalloc(t->pathlen, GFP_KERNEL);
+ watch->path = kmalloc(t->pathlen+1, GFP_KERNEL);
if (!watch->path)
goto audit_to_watch_fail;
- watch->path[0] = 0;
- strncat(watch->path, memblk + offset, t->pathlen);
+ watch->path[t->pathlen] = 0;
+ memcpy(watch->path, memblk + offset, t->pathlen);
goto audit_to_watch_exit;
--
dwmw2
1:31 p.m.
On Thursday 26 May 2005 12:43, Steve Grubb wrote:
On Thursday 26 May 2005 12:39, David Woodhouse wrote:
> - watch->filterkey = kmalloc(t->fklen, GFP_KERNEL);
> + watch->filterkey = kmalloc(t->fklen+1, GFP_KERNEL);
Tim, this was in my patch from May 8. How did it get dropped? Did anything
else get dropped?
-Steve
Steve, I'm not sure how it got dropped. Eek. *slaps head*
-tim
1:40 p.m.
On Thursday 26 May 2005 13:31, Timothy R. Chavez wrote:
On Thursday 26 May 2005 12:43, Steve Grubb wrote:
> On Thursday 26 May 2005 12:39, David Woodhouse wrote:
> > - watch->filterkey = kmalloc(t->fklen, GFP_KERNEL);
> > + watch->filterkey = kmalloc(t->fklen+1, GFP_KERNEL);
>
> Tim, this was in my patch from May 8. How did it get dropped? Did anything
> else get dropped?
>
> -Steve
Steve, I'm not sure how it got dropped. Eek. *slaps head*
I'll be sure to carefully look at the code paths that include audit_to_watch()
-tim
7158
days inactive
7158
days old
linux-audit@lists.linux-audit.osci.io
13 comments
4 participants
participants (4)
-
David Woodhouse -
Kris Wilson -
Steve Grubb -
Timothy R. Chavez