CVE-2023-3773: Kernel: xfrm: out-of-bounds read of xfrma_mtimer_thresh nlattr

========== 2. OOB read of XFRMAMTIMERTHRESH nlattr ==========

[require privilege]: CAPNETADMIN

[effects]: information leak

[crash stack]: Interesting enough as this OOB read will not be detected by KASan (perhaps why this bug is not detected by the fuzzer), see the details below.

[buggy commit]: 4e484b3e969b ("xfrm: rate limit SA mapping change message to user space")

[root cause]: The mentioned commit above added one additional attribute named XFRMAMTIMERTHRESH and described its type at compatpolicy (net/xfrm/xfrmcompat.c). However, the author forgot to also describe it at xfrmapolicy (net/xfrm/xfrmuser.c). Hence, this suppose NLAU32 (4 bytes) value can be faked as empty (0 bytes) by a malicious user, which lead to 4 bytes overflow read when parsing nlattrs.

The overall buffer skb is created at netlinksendmsg(...). According to the code, it will add another 0x140 skbsharedinfo data behind the skb data so this OOB will not be detected by KASan.

To exploit this (see PoC part), one malicious user can spray the SLUB objects and then leverage this 4 bytes OOB read to leak the heap data into x->mappingmaxage (see xfrmupdateaeparams(...)), and leak it to userspace via copytouserstateextra(...).

[PoC code]: see attachment poc2.c. I have tested it in latest Linux with QEMU. (no effects in ubuntu thanks to CONFIGINITONALLOCDEFAULTON)

[suggest fix]: Just add the type description like below

@@ -3035,6 +3035,7 @@ const struct nlapolicy xfrmapolicy[XFRMAMAX+1] = { [XFRMASETMARK] = { .type = NLAU32 }, [XFRMASETMARKMASK] = { .type = NLAU32 }, [XFRMAIFID] = { .type = NLAU32 }, + [XFRMAMTIMERTHRESH] = { .type = NLAU32 }, };