========== 2. OOB read of XFRMA_MTIMER_THRESH nlattr ==========

[require privilege]: CAP_NET_ADMIN

[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 XFRMA_MTIMER_THRESH and described its type at compat_policy (net/xfrm/xfrm_compat.c). However, the author forgot to also describe it at xfrma_policy (net/xfrm/xfrm_user.c). Hence, this suppose NLA_U32 (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 netlink_sendmsg(...). According to the code, it will add another 0x140 skb_shared_info 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->mapping_maxage (see xfrm_update_ae_params(...)), and leak it to userspace via copy_to_user_state_extra(...).

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


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

@@ -3035,6 +3035,7 @@ const struct nla_policy xfrma_policy[XFRMA_MAX+1] = {
        [XFRMA_SET_MARK]        = { .type = NLA_U32 },
        [XFRMA_SET_MARK_MASK]   = { .type = NLA_U32 },
        [XFRMA_IF_ID]           = { .type = NLA_U32 },
+       [XFRMA_MTIMER_THRESH]   = { .type = NLA_U32 },
 };