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