> diff --git a/include/linux/skmsg.h b/include/linux/skmsg.h
> index 49847888c..87772846f 100644
> --- a/include/linux/skmsg.h
> +++ b/include/linux/skmsg.h
[ ... ]
> +static inline ssize_t sk_psock_get_msg_size(struct sk_psock *psock)
> +{
> + return psock->ingress_size;
> +}
[ ... ]
> +static inline ssize_t sk_psock_msg_inq(struct sock *sk)
> +{
> + struct sk_psock *psock;
> + ssize_t inq = 0;
> +
> + psock = sk_psock_get(sk);
> + if (likely(psock)) {
> + inq = sk_psock_get_msg_size(psock);
> + sk_psock_put(sk, psock);
> + }
> + return inq;
> +}
Does this create a data race on ingress_size? The field is read here
without holding ingress_lock, but all modifications happen under that
lock in sk_psock_queue_msg(), sk_psock_dequeue_msg(), and
sk_msg_recvmsg().
When ioctl(FIONREAD) executes concurrently with recv(), one thread
reads ingress_size locklessly in sk_psock_msg_inq() while another
thread modifies it under lock in sk_msg_recvmsg(). On 32-bit systems
with 32-bit ssize_t, this could produce torn reads.
Would READ_ONCE/WRITE_ONCE be needed for the lockless access?
> +/* for udp */
> +static inline ssize_t sk_msg_first_length(struct sock *sk)
> +{
> + struct sk_psock *psock;
> + struct sk_msg *msg;
> + ssize_t inq = 0;
> +
> + psock = sk_psock_get(sk);
> + if (likely(psock)) {
> + msg = sk_psock_peek_msg(psock);
> + if (msg)
> + inq = msg->sg.size;
> + sk_psock_put(sk, psock);
> + }
> + return inq;
> +}
Can msg be freed between sk_psock_peek_msg() and reading msg->sg.size?
The peek function releases ingress_lock before returning the pointer.
If another thread in sk_msg_recvmsg() fully consumes the message after
the peek but before the size read, won't sk_psock_dequeue_msg() free
the message, leading to a use-after-free when we read msg->sg.size?
The call chain would be:
Thread A: udp_bpf_ioctl()->sk_msg_first_length()->sk_psock_peek_msg()
returns msg, releases lock, then reads msg->sg.size
Thread B: udp_bpf_recvmsg()->sk_msg_recvmsg() consumes msg fully,
calls sk_psock_dequeue_msg() which frees msg
---
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/19573628679
