[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y2IXTc1M6K7KaQwW@gondor.apana.org.au>
Date: Wed, 2 Nov 2022 15:07:57 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Antony Antony <antony.antony@...unet.com>
Cc: Thomas Jarosch <thomas.jarosch@...ra2net.com>,
Steffen Klassert <steffen.klassert@...unet.com>,
Sabrina Dubroca <sd@...asysnail.net>,
Leon Romanovsky <leon@...nel.org>, Roth Mark <rothm@...l.com>,
Zhihao Chen <chenzhihao@...zu.com>,
Tobias Brunner <tobias@...ongswan.org>, netdev@...r.kernel.org
Subject: Re: [PATCH] xfrm: Fix oops in __xfrm_state_delete()
On Tue, Nov 01, 2022 at 08:10:21PM +0100, Antony Antony wrote:
>
> xfrm_user sets msg_seq to zero in mapping change message. seq is only useful for
Oh I had misread the patch and thought this was send_acquire.
> acquire message. I think setting to zero would be a better fix.
>
> - hdr->sadb_msg_seq = x->km.seq = get_acqseq();
> + hdr->sadb_msg_seq = 0;
>
> While increasing x->km.seq in every call to pfkey_send_new_mapping()
> could be an issue, would it alone explan the crash?
Probably, if you change the state without moving it to the right
hash slot then the xfrm state hash table will be inconsistent.
We should copy the xfrm_user behaviour which is to leave x->km.seq
alone. So the patch should change the above line to
hdr->sadb_msg_seq = x->km.seq;
Thanks,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists