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

[sashiko-bot@kernel.org]

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.

> Note: For the reason above, it doesn't contain a "Fixes" tag, and is
> aiming at net-next instead of net.

If the concurrent recvmsg() path is reachable, does this patch actually fix
an exploitable issue rather than being a purely defensive cleanup?

If it does fix a reachable crash, should it include a Fixes tag and be
targeted at the net tree so it gets backported to stable kernels?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260515-getsock_four-v2-0-0d8eed952627@debian.org?part=1