From: Paul Moore <paul@paul-moore.com> Date: 2011-10-03 21:32:29
On Monday, October 03, 2011 02:58:24 PM David Howells wrote:
Fix the following bug in sel_netport_insert() where rcu_dereference() should
be rcu_dereference_protected() as sel_netport_lock is held.
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
security/selinux/netport.c:127 invoked rcu_dereference_check() without
protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
1 lock held by ossec-rootcheck/3323:
#0: (sel_netport_lock){+.....}, at: [<ffffffff8117d775>]
sel_netport_sid+0xbb/0x226
stack backtrace:
Pid: 3323, comm: ossec-rootcheck Not tainted 3.1.0-rc8-fsdevel+ #1095
Call Trace:
[<ffffffff8105cfb7>] lockdep_rcu_dereference+0xa7/0xb0
[<ffffffff8117d871>] sel_netport_sid+0x1b7/0x226
[<ffffffff8117d6ba>] ? sel_netport_avc_callback+0xbc/0xbc
[<ffffffff8117556c>] selinux_socket_bind+0x115/0x230
[<ffffffff810a5388>] ? might_fault+0x4e/0x9e
[<ffffffff810a53d1>] ? might_fault+0x97/0x9e
[<ffffffff81171cf4>] security_socket_bind+0x11/0x13
[<ffffffff812ba967>] sys_bind+0x56/0x95
[<ffffffff81380dac>] ? sysret_check+0x27/0x62
[<ffffffff8105b767>] ? trace_hardirqs_on_caller+0x11e/0x155
[<ffffffff81076fcd>] ? audit_syscall_entry+0x17b/0x1ae
[<ffffffff811b5eae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff81380d7b>] system_call_fastpath+0x16/0x1b
Signed-off-by: David Howells <dhowells@redhat.com>
---
security/selinux/netport.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
We should probably do the same for the security/selinux/netif.c as it uses the
same logic; David is this something you want to tackle?
Acked-by: Paul Moore <paul@paul-moore.com>
if (sel_netport_hash[idx].size == SEL_NETPORT_HASH_BKT_LIMIT) {
struct sel_netport *tail;
tail = list_entry(
- rcu_dereference(sel_netport_hash[idx].list.prev),
+ rcu_dereference_protected(
+ sel_netport_hash[idx].list.prev,
+ spin_is_locked(&sel_netport_lock)),
struct sel_netport, list);
list_del_rcu(&tail->list);
kfree_rcu(tail, rcu);
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Eric Dumazet <hidden> Date: 2011-10-04 04:23:03
Le lundi 03 octobre 2011 à 17:30 -0400, Paul Moore a écrit :
On Monday, October 03, 2011 02:58:24 PM David Howells wrote:
quoted
Fix the following bug in sel_netport_insert() where rcu_dereference() should
be rcu_dereference_protected() as sel_netport_lock is held.
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
security/selinux/netport.c:127 invoked rcu_dereference_check() without
protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
1 lock held by ossec-rootcheck/3323:
#0: (sel_netport_lock){+.....}, at: [<ffffffff8117d775>]
sel_netport_sid+0xbb/0x226
stack backtrace:
Pid: 3323, comm: ossec-rootcheck Not tainted 3.1.0-rc8-fsdevel+ #1095
Call Trace:
[<ffffffff8105cfb7>] lockdep_rcu_dereference+0xa7/0xb0
[<ffffffff8117d871>] sel_netport_sid+0x1b7/0x226
[<ffffffff8117d6ba>] ? sel_netport_avc_callback+0xbc/0xbc
[<ffffffff8117556c>] selinux_socket_bind+0x115/0x230
[<ffffffff810a5388>] ? might_fault+0x4e/0x9e
[<ffffffff810a53d1>] ? might_fault+0x97/0x9e
[<ffffffff81171cf4>] security_socket_bind+0x11/0x13
[<ffffffff812ba967>] sys_bind+0x56/0x95
[<ffffffff81380dac>] ? sysret_check+0x27/0x62
[<ffffffff8105b767>] ? trace_hardirqs_on_caller+0x11e/0x155
[<ffffffff81076fcd>] ? audit_syscall_entry+0x17b/0x1ae
[<ffffffff811b5eae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff81380d7b>] system_call_fastpath+0x16/0x1b
Signed-off-by: David Howells <dhowells@redhat.com>
---
security/selinux/netport.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
We should probably do the same for the security/selinux/netif.c as it uses the
same logic; David is this something you want to tackle?
Acked-by: Paul Moore <paul@paul-moore.com>
From: David Howells <dhowells@redhat.com> Date: 2011-10-05 13:32:59
Paul Moore [off-list ref] wrote:
We should probably do the same for the security/selinux/netif.c as it uses
the same logic; David is this something you want to tackle?
netif.c doesn't use any rcu_dereference*() function directly, though it does
use list_for_each_entry_rcu(). However, I'm not sure that's a problem. What
is it you're referring to?
David
From: Paul Moore <paul@paul-moore.com> Date: 2011-10-06 22:51:25
On Wednesday, October 05, 2011 02:32:03 PM David Howells wrote:
Paul Moore [off-list ref] wrote:
quoted
We should probably do the same for the security/selinux/netif.c as it
uses the same logic; David is this something you want to tackle?
netif.c doesn't use any rcu_dereference*() function directly, though it does
use list_for_each_entry_rcu(). However, I'm not sure that's a problem.
What is it you're referring to?
My apologies, the netport.c and netif.c code is very, very similar and
whenever I see a patch just for one of the two it causes a reaction that you
saw above. While netif.c has a similar function, sel_netif_insert(), it is
slightly different and doesn't need a rcu_dereference() ad the netport.c code
does.
Sorry for the confusion.
--
paul moore
www.paul-moore.com