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

From: Eulgyu Kim <redacted>
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/ (local)

I'll rebase and respin it.