lkml.org 
[lkml]   [2019]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Date
SubjectRe: [PATCH] netnode.c : fix sel_netnode_hash be destroyed
Dear Paul Moore :
When the phone is power on about 30 second. it happened kernel
panic . The probability of kerner panic is about 4/10000。
I used Android Q base kerner-4.9. I can't reproduce it, it
happened four times on different phone. all message is Unable to
handle kernel paging request at virtual address fffffffffffffffc , x0
: ffffffffffffffe8
In our code ,we did not change the code in netnode.c.
sel_netnode_find code line is 114.
list_for_each_entry_rcu(node, &sel_netnode_hash[idx].list, list) is 131.
if (node->nsec.family == family) is 132 .
The backtrace is :
[ 31.152983] [<00000000584f97e1>] sel_netnode_find+0x6c/0xf0
[ 31.157670] [<00000000d1009c50>] sel_netnode_sid+0x3c/0x248
[ 31.163225] [<00000000c6ff20a5>] selinux_socket_bind+0x204/0x230
[ 31.168777] [<0000000080a7de33>] security_socket_bind+0x64/0x94
[ 31.180679] [<00000000a01eb02b>] SyS_bind+0x10c/0x164
[ 31.187269] [<00000000c7a460e5>] el0_svc_naked+0x34/0x38

please help to check more . I think there is a bug in netnode.c
Thank you so much.


Paul Moore <paul@paul-moore.com> 于2019年12月20日周五 下午9:48写道:
>
> On Fri, Dec 20, 2019 at 5:07 AM hui yang <yanghui.def@gmail.com> wrote:
> > From: YangHui <yanghui.def@gmail.com>
> >
> > we often find below error :
> > [ 30.729718] Unable to handle kernel paging request at virtual address fffffffffffffffc
> > [ 30.747478] Kernel BUG at sel_netnode_find+0x6c/0xf0 [verbose debug info unavailable]
> > [ 30.818858] PC is at sel_netnode_find+0x6c/0xf0
> > [ 30.824671] LR is at sel_netnode_sid+0x3c/0x248
> > [ 30.829170] pc : [<ffffff8008428094>] lr : [<ffffff8008428154>] pstate: a0400145
> > [ 30.833701] sp : ffffffc026f27c50
> > [ 30.841319] x29: ffffffc026f27c50 x28: ffffffc026f27e40
> > [ 30.849634] x27: ffffff8009132000 x26: 0000000000000000
> > [ 30.854932] x25: ffffffc016f0aa80 x24: 0000000000000000
> > [ 30.860224] x23: ffffffc026f27e38 x22: ffffffc026f27d34
> > [ 30.865520] x21: 000000000000000a x20: ffffffc026f27e40
> > [ 30.870818] x19: 000000000000000a x18: 0000007a13b48000
> > [ 30.876118] x17: 0000007a16ca93c0 x16: ffffff8008e56b2c
> > [ 30.881406] x15: 0000000000000020 x14: 002dc6bffa5d9e00
> > [ 30.886701] x13: 203a644974654e4c x12: 00000000000017c1
> > [ 30.891997] x11: 0000000000000000 x10: 0000000000000001
> > [ 30.897292] x9 : 0000000000000002 x8 : ffffff8009933090
> > [ 30.902588] x7 : ffffffc0725fd090 x6 : 0000000004fd9f2c
> > [ 30.907881] x5 : 0000000000000000 x4 : 0000000000000000
> > [ 30.913176] x3 : 00000001ffffffff x2 : 0000000000000000
> > [ 30.918475] x1 : ffffff800a10ca80 x0 : ffffffffffffffe8
> > some sel_netnode_hash[idx].list==NULL,so happend this.
> > I add spin_lock_bh on sel_netnode_init.
> >
> > Signed-off-by: YangHui <yanghui.def@gmail.com>
> > ---
> > security/selinux/netnode.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/security/selinux/netnode.c b/security/selinux/netnode.c
> > index 9ab84ef..aa0eeb7 100644
> > --- a/security/selinux/netnode.c
> > +++ b/security/selinux/netnode.c
> > @@ -293,11 +293,12 @@ static __init int sel_netnode_init(void)
> >
> > if (!selinux_enabled)
> > return 0;
> > -
> > + spin_lock_bh(&sel_netnode_lock);
> > for (iter = 0; iter < SEL_NETNODE_HASH_SIZE; iter++) {
> > INIT_LIST_HEAD(&sel_netnode_hash[iter].list);
> > sel_netnode_hash[iter].size = 0;
> > }
> > + spin_unlock_bh(&sel_netnode_lock);
> >
> > return 0;
> > }
>
> I'm confused as to why this patch solved your problem. The
> sel_netnode_init() function is only run once during early boot and
> there shouldn't be any other threads trying to access the netnode
> cache at this point.
>
> Can you explain the conditions under which you see this problem? What
> kernel are you using (stock distro kernel? upstream? Android?)? Can
> you reproduce this problem? Can you provide source code line numbers
> associated with the func/offset lines in the backtrace above?
>
> --
> paul moore
> www.paul-moore.com

\
 
 \ /
  Last update: 2019-12-21 03:37    [W:0.053 / U:9.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site