Re: [PATCH] netnode.c : fix sel_netnode_hash be destroyed

[hui yang]

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@xxxxxxxxxxxxxx> ä2019å12æ20æåä äå9:48åéï
>
> On Fri, Dec 20, 2019 at 5:07 AM hui yang <yanghui.def@xxxxxxxxx> wrote:
> > From: YangHui <yanghui.def@xxxxxxxxx>
> >
> > 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@xxxxxxxxx>
> > ---
> >  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