> syzbot reported use-after-free of struct sk_msg in sk_msg_recvmsg(). [0]
>
> sk_msg_recvmsg() peeks sk_msg from psock->ingress_msg under a lock,
> but its processing is lockless.
>
> Thus, sk_msg_recvmsg() must be serialised by callers, otherwise
> multiple threads could touch the same sk_msg.
>
> For example, TCP uses lock_sock(), and AF_UNIX uses unix_sk(sk)->iolock.
>
> Initially, udp_bpf_recvmsg() had used lock_sock(), but the cited
> commit accidentally removed it.
Is "accidentally removed it" the right wording here?
The cited commit 9f2470fbc4cb ("skmsg: Improve udp_bpf_recvmsg() accuracy")
removed the lock_sock()/release_sock() pair deliberately, and its own message
argues for it:
UDP does not lock the sock during BH Rx path, it makes no sense for its
->recvmsg() to lock the sock.
So the removal looks like an intentional change that overlooked the lock's
role in serialising sk_msg_recvmsg() against concurrent recvmsg(), rather
than an accidental deletion. Would something like "inadvertently dropped the
serialisation" describe it more precisely?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27347782396
