Re: [BUG] KASAN: slab-use-after-free in __sk_msg_recvmsg

[Kuniyuki Iwashima <kuniyu@google.com>]

From: Eulgyu Kim <eulgyukim@snu.ac.kr>
Date: Mon,  4 May 2026 16:23:25 +0900
> Hello,
> 
> We encountered a "KASAN: slab-use-after-free in __sk_msg_recvmsg"
> on kernel version v7.1.0-rc1.
> 
> As this issue was identified via fuzzing and we have limited background,
> we find it challenging to identify the exact root cause or propose a correct fix.
> Therefore, please consider the following analysis as a best-effort guess,
> which may still be incomplete or incorrect.
> 
> The issue is that sk_psock_peek_msg() only protects the list lookup; after it
> drops ingress_lock, the returned sk_msg can be concurrently consumed and freed
> by another recvmsg caller.
> 
> Following is the harmful sequence:
> 
> 1. Thread A calls recvmmsg() on the socket and reaches __sk_msg_recvmsg()
> through udp_bpf_recvmsg() -> sk_msg_recvmsg() -> __sk_msg_recvmsg().
> 
> 2. __sk_msg_recvmsg() calls sk_psock_peek_msg() and obtains msg_rx, the
> first struct sk_msg on psock->ingress_msg. The ingress_lock is dropped
> immediately after the peek.
> 
> 3. Thread A copies data to userspace and still holds local pointers to
> msg_rx and sge = sk_msg_elem(msg_rx, i), but has not yet updated
> sge->offset/sge->length or dequeued the message.
> 
> 4. Thread B concurrently calls recvmmsg() on the same socket.
> 
> 5. Because udp_bpf_recvmsg() does not hold a per-socket receive lock,

This reminds me that I forgot to respin this series.
https://lore.kernel.org/bpf/20260221233234.3814768-1-kuniyu@google.com/

I'll rebase and respin it.