Re: [PATCH net-next v2 1/7] af_iucv: take socket lock around SO_MSGSIZE getsockopt

[Breno Leitao <leitao@debian.org>]

On Sat, May 16, 2026 at 08:34:33AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] The commit message incorrectly claims the bug is unexploitable and targets the patch to `net-next` without a `Fixes` tag, bypassing stable backports for a reachable NULL pointer dereference or use-after-free.
> --
> 
> commit 2d366eacb5715c7a757195706a39c7382bd391e0
> Author: Breno Leitao <leitao@debian.org>
> af_iucv: take socket lock around SO_MSGSIZE getsockopt
> 
> This commit adds socket locking around the SO_MSGSIZE case in
> iucv_sock_getsockopt() to prevent concurrent modifications to hs_dev.
> The commit message states this is purely defensive and targets net-next.
> 
> > This is not an exploitable bug. iucv_sock_close() is the only writer
> > of iucv->hs_dev and only runs from the protocol release callback,
> > which the socket layer invokes after the last file reference drops.
> > The getsockopt() syscall holds an fd reference for its entire
> > duration via fdget()/fdput(), so iucv_sock_close() cannot run
> > concurrently with the SO_MSGSIZE read on the same socket.
> 
> Is it strictly true that iucv_sock_close() only runs from the release
> callback?
> 
> Looking at iucv_sock_recvmsg(), it appears to directly invoke
> iucv_sock_close() when the message limit is exceeded:
> 
> net/iucv/af_iucv.c:iucv_sock_recvmsg() {
>         ...
>         if (atomic_read(&iucv->msg_recv) > iucv->msglimit) {
>                 ...
>                 iucv_sock_close(sk);
>                 ...
>         }
>         ...
> }
> 
> Since recvmsg() executes with an active file descriptor reference, could
> this path be triggered concurrently with a getsockopt() call evaluating
> SO_MSGSIZE on the same socket?
> 
> If so, evaluating iucv->hs_dev and then dereferencing iucv->hs_dev->mtu
> in getsockopt() before this patch could be vulnerable to a race with
> iucv_sock_close(), potentially leading to a null pointer dereference or
> use-after-free.

You are right. iucv_sock_recvmsg() does call iucv_sock_close() directly
on the AF_IUCV_TRANS_HIPER msglimit-exceeded branch, in syscall context
on a live fd. Two threads sharing an fd (or two fds for the same struct
sock after dup/fork) can then run recvmsg() and getsockopt(SO_MSGSIZE)
concurrently, if the dev_put() drops the last reference, A can be left
dereferencing a freed netdev.

That said, I will separate this patch and send it to 'net'.