CVE-2025-21854

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sockmap, vsock: For connectible sockets allow only connected<br /> <br /> sockmap expects all vsocks to have a transport assigned, which is expressed<br /> in vsock_proto::psock_update_sk_prot(). However, there is an edge case<br /> where an unconnected (connectible) socket may lose its previously assigned<br /> transport. This is handled with a NULL check in the vsock/BPF recv path.<br /> <br /> Another design detail is that listening vsocks are not supposed to have any<br /> transport assigned at all. Which implies they are not supported by the<br /> sockmap. But this is complicated by the fact that a socket, before<br /> switching to TCP_LISTEN, may have had some transport assigned during a<br /> failed connect() attempt. Hence, we may end up with a listening vsock in a<br /> sockmap, which blows up quickly:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000120-0x0000000000000127]<br /> CPU: 7 UID: 0 PID: 56 Comm: kworker/7:0 Not tainted 6.14.0-rc1+<br /> Workqueue: vsock-loopback vsock_loopback_work<br /> RIP: 0010:vsock_read_skb+0x4b/0x90<br /> Call Trace:<br /> sk_psock_verdict_data_ready+0xa4/0x2e0<br /> virtio_transport_recv_pkt+0x1ca8/0x2acc<br /> vsock_loopback_work+0x27d/0x3f0<br /> process_one_work+0x846/0x1420<br /> worker_thread+0x5b3/0xf80<br /> kthread+0x35a/0x700<br /> ret_from_fork+0x2d/0x70<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> For connectible sockets, instead of relying solely on the state of<br /> vsk-&gt;transport, tell sockmap to only allow those representing established<br /> connections. This aligns with the behaviour for AF_INET and AF_UNIX.