In the Linux kernel, the following vulnerability has been resolved:

virtio/vsock: Fix uninit-value in virtiotransportrecv_pkt()

KMSAN reported the following uninit-value access issue:

===================================================== BUG: KMSAN: uninit-value in virtiotransportrecvpkt+0x1dfb/0x26a0 net/vmwvsock/virtiotransportcommon.c:1421 virtiotransportrecvpkt+0x1dfb/0x26a0 net/vmwvsock/virtiotransportcommon.c:1421 vsockloopbackwork+0x3bb/0x5a0 net/vmwvsock/vsockloopback.c:120 processonework kernel/workqueue.c:2630 [inline] processscheduledworks+0xff6/0x1e60 kernel/workqueue.c:2703 workerthread+0xeca/0x14d0 kernel/workqueue.c:2784 kthread+0x3cc/0x520 kernel/kthread.c:388 retfromfork+0x66/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x11/0x20 arch/x86/entry/entry_64.S:304

Uninit was stored to memory at: virtiotransportspaceupdate net/vmwvsock/virtiotransportcommon.c:1274 [inline] virtiotransportrecvpkt+0x1ee8/0x26a0 net/vmwvsock/virtiotransportcommon.c:1415 vsockloopbackwork+0x3bb/0x5a0 net/vmwvsock/vsockloopback.c:120 processonework kernel/workqueue.c:2630 [inline] processscheduledworks+0xff6/0x1e60 kernel/workqueue.c:2703 workerthread+0xeca/0x14d0 kernel/workqueue.c:2784 kthread+0x3cc/0x520 kernel/kthread.c:388 retfromfork+0x66/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x11/0x20 arch/x86/entry/entry_64.S:304

Uninit was created at: slabpostallochook+0x105/0xad0 mm/slab.h:767 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x5a2/0xaf0 mm/slub.c:3523 kmallocreserve+0x13c/0x4a0 net/core/skbuff.c:559 _allocskb+0x2fd/0x770 net/core/skbuff.c:650 allocskb include/linux/skbuff.h:1286 [inline] virtiovsockallocskb include/linux/virtiovsock.h:66 [inline] virtiotransportallocskb+0x90/0x11e0 net/vmwvsock/virtiotransportcommon.c:58 virtiotransportresetnosock net/vmwvsock/virtiotransportcommon.c:957 [inline] virtiotransportrecvpkt+0x1279/0x26a0 net/vmwvsock/virtiotransportcommon.c:1387 vsockloopbackwork+0x3bb/0x5a0 net/vmwvsock/vsockloopback.c:120 processonework kernel/workqueue.c:2630 [inline] processscheduledworks+0xff6/0x1e60 kernel/workqueue.c:2703 workerthread+0xeca/0x14d0 kernel/workqueue.c:2784 kthread+0x3cc/0x520 kernel/kthread.c:388 retfromfork+0x66/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x11/0x20 arch/x86/entry/entry64.S:304

CPU: 1 PID: 10664 Comm: kworker/1:5 Not tainted 6.6.0-rc3-00146-g9f3ebbef746f #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014

Workqueue: vsock-loopback vsockloopbackwork

The following simple reproducer can cause the issue described above:

int main(void) { int sock; struct sockaddrvm addr = { .svmfamily = AFVSOCK, .svmcid = VMADDRCIDANY, .svm_port = 1234, };

sock = socket(AFVSOCK, SOCKSTREAM, 0); connect(sock, (struct sockaddr *)&addr, sizeof(addr)); return 0; }

This issue occurs because the buf_alloc and fwd_cnt fields of the struct virtio_vsock_hdr are not initialized when a new skb is allocated in virtio_transport_init_hdr(). This patch resolves the issue by initializing these fields during allocation.