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: [email protected] Signed-off-by: Andrea Parri <[email protected]> ---
oops, thanks! Reviewed-by: Luigi Leonardi <[email protected]> Luigi
