linux-kernel - Re: [PATCH] netnode.c : fix sel_netnode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sat, 21 Dec 2019 10:02:38 -0500
From:   Paul Moore <paul@...l-moore.com>
To:     hui yang <yanghui.def@...il.com>
Cc:     Stephen Smalley <sds@...ho.nsa.gov>,
        Eric Paris <eparis@...isplace.org>, selinux@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] netnode.c : fix sel_netnode_hash be destroyed

On Fri, Dec 20, 2019 at 9:37 PM hui yang <yanghui.def@...il.com> wrote:
> 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.

Looking at netnode.c again somewhat quickly I don't see anything
obvious, but it sounds like this is an Android kernel, yes?  I don't
have a copy of the Android kernel sources to inspect, but given that
kernel v4.9 is quite old compared to upstream I suspect the Android
kernel has a number of backports, making this difficult to diagnose.

If this is an Android kernel, I would suggest talking with the Android
kernel developers.

> Paul Moore <paul@...l-moore.com> 于2019年12月20日周五 下午9:48写道：
> >
> > On Fri, Dec 20, 2019 at 5:07 AM hui yang <yanghui.def@...il.com> wrote:
> > > From: YangHui <yanghui.def@...il.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@...il.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



-- 
paul moore
www.paul-moore.com