diff options
author | Eric Paris <eparis@redhat.com> | 2009-09-20 21:21:10 -0400 |
---|---|---|
committer | James Morris <jmorris@namei.org> | 2009-09-23 11:16:20 -0700 |
commit | 5224ee086321fec78970e2f2805892d2b34e8957 (patch) | |
tree | 3b7eef40c92b07ed75d8585c51333b8e87a33a2b | |
parent | 606531c316d30e9639473a6da09ee917125ab467 (diff) | |
download | linux-stable-5224ee086321fec78970e2f2805892d2b34e8957.tar.gz linux-stable-5224ee086321fec78970e2f2805892d2b34e8957.tar.bz2 linux-stable-5224ee086321fec78970e2f2805892d2b34e8957.zip |
SELinux: do not destroy the avc_cache_nodep
The security_ops reset done when SELinux is disabled at run time is done
after the avc cache is freed and after the kmem_cache for the avc is also
freed. This means that between the time the selinux disable code destroys
the avc_node_cachep another process could make a security request and could
try to allocate from the cache. We are just going to leave the cachep around,
like we always have.
SELinux: Disabled at runtime.
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff81122537>] kmem_cache_alloc+0x9a/0x185
PGD 0
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
last sysfs file:
CPU 1
Modules linked in:
Pid: 12, comm: khelper Not tainted 2.6.31-tip-05525-g0eeacc6-dirty #14819
System Product Name
RIP: 0010:[<ffffffff81122537>] [<ffffffff81122537>]
kmem_cache_alloc+0x9a/0x185
RSP: 0018:ffff88003f9258b0 EFLAGS: 00010086
RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000078c0129e
RDX: 0000000000000000 RSI: ffffffff8130b626 RDI: ffffffff81122528
RBP: ffff88003f925900 R08: 0000000078c0129e R09: 0000000000000001
R10: 0000000000000000 R11: 0000000078c0129e R12: 0000000000000246
R13: 0000000000008020 R14: ffff88003f8586d8 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff880002b00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000001001000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: ffffffff827bd420 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process khelper (pid: 12, threadinfo ffff88003f924000, task
ffff88003f928000)
Stack:
0000000000000246 0000802000000246 ffffffff8130b626 0000000000000001
<0> 0000000078c0129e 0000000000000000 ffff88003f925a70 0000000000000002
<0> 0000000000000001 0000000000000001 ffff88003f925960 ffffffff8130b626
Call Trace:
[<ffffffff8130b626>] ? avc_alloc_node+0x36/0x273
[<ffffffff8130b626>] avc_alloc_node+0x36/0x273
[<ffffffff8130b545>] ? avc_latest_notif_update+0x7d/0x9e
[<ffffffff8130b8b4>] avc_insert+0x51/0x18d
[<ffffffff8130bcce>] avc_has_perm_noaudit+0x9d/0x128
[<ffffffff8130bf20>] avc_has_perm+0x45/0x88
[<ffffffff8130f99d>] current_has_perm+0x52/0x6d
[<ffffffff8130fbb2>] selinux_task_create+0x2f/0x45
[<ffffffff81303bf7>] security_task_create+0x29/0x3f
[<ffffffff8105c6ba>] copy_process+0x82/0xdf0
[<ffffffff81091578>] ? register_lock_class+0x2f/0x36c
[<ffffffff81091a13>] ? mark_lock+0x2e/0x1e1
[<ffffffff8105d596>] do_fork+0x16e/0x382
[<ffffffff81091578>] ? register_lock_class+0x2f/0x36c
[<ffffffff810d9166>] ? probe_workqueue_execution+0x57/0xf9
[<ffffffff81091a13>] ? mark_lock+0x2e/0x1e1
[<ffffffff810d9166>] ? probe_workqueue_execution+0x57/0xf9
[<ffffffff8100cdb2>] kernel_thread+0x82/0xe0
[<ffffffff81078b1f>] ? ____call_usermodehelper+0x0/0x139
[<ffffffff8100ce10>] ? child_rip+0x0/0x20
[<ffffffff81078aea>] ? __call_usermodehelper+0x65/0x9a
[<ffffffff8107a5c7>] run_workqueue+0x171/0x27e
[<ffffffff8107a573>] ? run_workqueue+0x11d/0x27e
[<ffffffff81078a85>] ? __call_usermodehelper+0x0/0x9a
[<ffffffff8107a7bc>] worker_thread+0xe8/0x10f
[<ffffffff810808e2>] ? autoremove_wake_function+0x0/0x63
[<ffffffff8107a6d4>] ? worker_thread+0x0/0x10f
[<ffffffff8108042e>] kthread+0x91/0x99
[<ffffffff8100ce1a>] child_rip+0xa/0x20
[<ffffffff8100c754>] ? restore_args+0x0/0x30
[<ffffffff8108039d>] ? kthread+0x0/0x99
[<ffffffff8100ce10>] ? child_rip+0x0/0x20
Code: 0f 85 99 00 00 00 9c 58 66 66 90 66 90 49 89 c4 fa 66 66 90 66 66 90
e8 83 34 fb ff e8 d7 e9 26 00 48 98 49 8b 94 c6 10 01 00 00 <48> 8b 1a 44
8b 7a 18 48 85 db 74 0f 8b 42 14 48 8b 04 c3 ff 42
RIP [<ffffffff81122537>] kmem_cache_alloc+0x9a/0x185
RSP <ffff88003f9258b0>
CR2: 0000000000000000
---[ end trace 42f41a982344e606 ]---
Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
-rw-r--r-- | security/selinux/avc.c | 19 |
1 files changed, 15 insertions, 4 deletions
diff --git a/security/selinux/avc.c b/security/selinux/avc.c index 1ed0f076aadc..b4b5da1c0a42 100644 --- a/security/selinux/avc.c +++ b/security/selinux/avc.c @@ -868,8 +868,19 @@ u32 avc_policy_seqno(void) void avc_disable(void) { - avc_flush(); - synchronize_rcu(); - if (avc_node_cachep) - kmem_cache_destroy(avc_node_cachep); + /* + * If you are looking at this because you have realized that we are + * not destroying the avc_node_cachep it might be easy to fix, but + * I don't know the memory barrier semantics well enough to know. It's + * possible that some other task dereferenced security_ops when + * it still pointed to selinux operations. If that is the case it's + * possible that it is about to use the avc and is about to need the + * avc_node_cachep. I know I could wrap the security.c security_ops call + * in an rcu_lock, but seriously, it's not worth it. Instead I just flush + * the cache and get that memory back. + */ + if (avc_node_cachep) { + avc_flush(); + /* kmem_cache_destroy(avc_node_cachep); */ + } } |