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
| ||
|
Message-ID: <20221029170857.jvjuogigbgf7sk2s@intra2net.com> Date: Sat, 29 Oct 2022 19:08:57 +0200 From: Thomas Jarosch <thomas.jarosch@...ra2net.com> To: Zhihao Chen <chenzhihao@...zu.com> Cc: netdev@...r.kernel.org, baihaowen@...zu.com, steffen.klassert@...unet.com, Chonglong Xu <xuchonglong@...zu.com> Subject: Re: [PATCH] xfrm:fix access to the null pointer in __xfrm_state_delete() Hi Chen, You wrote on Thu, Oct 27, 2022 at 02:24:55PM +0000: > Validate the byseq node before removing it from the hlist of state_byseq. > km.seq cannot be used to determine whether the SA is in the byseq hlist > because xfrm_add_sa() may initialize km.seq to 0 and the SA is not inserted > into hlist. In later network communication, the seq field will increase > after the valid packet is received. > > In the above case, the NULL pointer will be accessed and cause a kernel > panic when the SA is being removed from hlist by checking km.seq field in > __xfrm_state_delete(). thanks for your patch! The solution is pretty close already, it's pfkey_send_new_mapping() from af_key.c messing with "x->km.seq" if a new NAT-T mapping is detected. I'll send a patch for the root cause on Monday, the commit message will be the most delicate thing. I already checked different PF_KEYv2 based IPSec implementations how they behave regarding SADB_X_NAT_T_NEW_MAPPING. Some details are public here already: https://github.com/strongswan/strongswan/issues/992#issuecomment-1294651331 If you are using a modern IPSec userspace application like strongswan 5.x, one can use the netlink xfrm interface and disable CONFIG_NET_KEY in the kernel to completely avoid the issue with PF_KEYv2. Also unloading the "af_key" kernel module helps. Perhaps it might make sense to extend your patch to WARN_ON in case we run into this situation again in the future? Then we would not sweep the issue under the rug. Cheers, Thomas
Powered by blists - more mailing lists