Re: [PATCH net] hv_sock: Report no unread data before a channel is available

[Stefano Garzarella <sgarzare@redhat.com>]

On Fri, Nov 06, 2026 at 01:39:18PM +0100, Andrea Parri wrote:
>The Hyper-V transport is assigned before the asynchronous VMBus channel
>offer completes.  Its zero-initialized hvsock therefore has a NULL chan
>until hvs_open_connection() associates the channel with the socket.
>
>SIOCINQ can query the assigned transport while the socket is connecting,
>or after connect() fails once the transport has been assigned.  Unlike
>poll(), that path does not check stream_is_active() before calling the
>transport's stream_has_data callback.  hvs_stream_has_data() then 
>passes
>the NULL channel to hvs_channel_readable_payload(), and any user in the
>guest can trigger an oops:
>
>  BUG: kernel NULL pointer dereference, address: 0000000000000178
>  RIP: 0010:hvs_stream_has_data+0x23/0x120
>  Call Trace:
>   <TASK>
>   ? vsock_ioctl+0x74/0xf0
>   sock_do_ioctl+0x42/0xf0
>   sock_ioctl+0x27d/0x310
>   do_vfs_ioctl+0x700/0x810
>   __x64_sys_ioctl+0x7d/0xf0
>
>Return zero unread bytes when no channel is available, before accessing
>the receive state or ring.  Leave the existing channel-backed receive
>handling unchanged.
>
>The oops was reproduced on an unmodified v7.4-rc1 kernel in a WSL2
>guest with a small user-space program, available on request.  With this
>patch, the program reports zero unread bytes and the kernel logs nothing.
>Other vsock_test cases were not run, as most of them need a host-side
>peer.
>
>AI assistance was used to identify the issue and develop the fix.
>
>Fixes: f7c722659275 ("vsock: Add support for SIOCINQ ioctl")
>Cc: stable@vger.kernel.org
>Signed-off-by: Andrea Parri <parri.andrea@gmail.com>
>---
>An alternative is to check stream_is_active() in vsock_do_ioctl(), as
>vsock_poll() does.  That would also change SIOCINQ on VMCI sockets that
>are not connected yet, from -ENOENT to 0.  I kept this fix in hv_sock to
>limit it to the crash, and can send the generic check separately for
>net-next.

Yeah, I was going to suggest the same, but I agree that for net this is 
a better and self contained fix:

Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>

>
>The reproducer is a new vsock_test case.  I have not posted it, as
>Documentation/process/security-bugs.rst asks for reproducers of bugs
>found with AI assistance.  I can send it privately, and will post it
>once this fix is merged.

Yes please, post it upstream when merged.

Thanks,
Stefano