[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20221020134453.3pacvts4gfbxcygo@intra2net.com>
Date: Thu, 20 Oct 2022 15:44:53 +0200
From: Thomas Jarosch <thomas.jarosch@...ra2net.com>
To: Leon Romanovsky <leon@...nel.org>
Cc: Antony Antony <antony.antony@...unet.com>,
Steffen Klassert <steffen.klassert@...unet.com>,
netdev@...r.kernel.org, Tobias Brunner <tobias@...ongswan.org>
Subject: Re: [PATCH RFC ipsec] xfrm: fix panic in xfrm_delete from userspace
on ARM 32
You wrote on Thu, Oct 20, 2022 at 03:16:02PM +0200:
> > We all know that it can't be a fix. It is hard to judge by this
> > calltrace, but it looks like something in x->km is not set. It is
> > probably ".all" field.
small update: I'm not sure if I can trust the output of my disassembly,
but I just recompiled the kernel rpm under test with CONFIG_DEBUG_INFO
and when I do this with the address from the backtrace:
(gdb) list *__xfrm_state_delete+0xc9
0x2269 is in __xfrm_state_delete (./include/linux/list.h:856).
851 static inline void __hlist_del(struct hlist_node *n)
852 {
853 struct hlist_node *next = n->next;
854 struct hlist_node **pprev = n->pprev;
855
856 WRITE_ONCE(*pprev, next);
857 if (next)
858 WRITE_ONCE(next->pprev, pprev);
859 }
860
which seems to match the suspected "list_del(&x->km.all)"
call from the code in 5.15.73:
*******************************
int __xfrm_state_delete(struct xfrm_state *x)
{
struct net *net = xs_net(x);
int err = -ESRCH;
if (x->km.state != XFRM_STATE_DEAD) {
x->km.state = XFRM_STATE_DEAD;
spin_lock(&net->xfrm.xfrm_state_lock);
list_del(&x->km.all);
hlist_del_rcu(&x->bydst);
hlist_del_rcu(&x->bysrc);
if (x->km.seq)
hlist_del_rcu(&x->byseq);
if (x->id.spi)
hlist_del_rcu(&x->byspi);
net->xfrm.state_num--;
spin_unlock(&net->xfrm.xfrm_state_lock);
if (x->encap_sk)
sock_put(rcu_dereference_raw(x->encap_sk));
xfrm_dev_state_delete(x);
/* All xfrm_state objects are created by xfrm_state_alloc.
* The xfrm_state_alloc call gives a reference, and that
* is what we are dropping here.
*/
xfrm_state_put(x);
err = 0;
}
return err;
}
*******************************
I'll still wait for another crash to appear using
a CONFIG_DEBUG_INFO enabled kernel to be sure.
HTH,
Thomas
Powered by blists - more mailing lists