[syzbot] [virt?] upstream test error: KMSAN: use-after-free in vring_map_one_sg

[syzbot] [virt?] upstream test error: KMSAN: use-after-free in vring_map_one_sg

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    ba9dac987319 Merge tag 'libnvdimm-for-6.18' of git://git.k..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=138581e2580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=ad506767107aacda
dashboard link: https://syzkaller.appspot.com/bug?extid=ac856b8b866cca41352c
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/ce6a737acd38/disk-ba9dac98.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/d7053b626642/vmlinux-ba9dac98.xz
kernel image: https://storage.googleapis.com/syzbot-assets/13f2d7e62179/bzImage-ba9dac98.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ac856b8b866cca41352c@syzkaller.appspotmail.com

8021q: adding VLAN 0 to HW filter on device bond0
eql: remember to turn off Van-Jacobson compression on your slave devices
=====================================================
BUG: KMSAN: use-after-free in vring_map_one_sg+0x290/0x7b0 drivers/virtio/virtio_ring.c:401
 vring_map_one_sg+0x290/0x7b0 drivers/virtio/virtio_ring.c:401
 virtqueue_add_split drivers/virtio/virtio_ring.c:608 [inline]
 virtqueue_add+0x32aa/0x6320 drivers/virtio/virtio_ring.c:2281
 virtqueue_add_outbuf+0x89/0xa0 drivers/virtio/virtio_ring.c:2342
 virtnet_add_outbuf drivers/net/virtio_net.c:574 [inline]
 xmit_skb drivers/net/virtio_net.c:3343 [inline]
 start_xmit+0x274d/0x4860 drivers/net/virtio_net.c:3367
 __netdev_start_xmit include/linux/netdevice.h:5248 [inline]
 netdev_start_xmit include/linux/netdevice.h:5257 [inline]
 xmit_one net/core/dev.c:3845 [inline]
 dev_hard_start_xmit+0x22c/0xa30 net/core/dev.c:3861
 sch_direct_xmit+0x3b2/0xcf0 net/sched/sch_generic.c:344
 __dev_xmit_skb net/core/dev.c:4152 [inline]
 __dev_queue_xmit+0x3588/0x5e60 net/core/dev.c:4729
 dev_queue_xmit include/linux/netdevice.h:3365 [inline]
 lapbeth_data_transmit+0x352/0x480 drivers/net/wan/lapbether.c:260
 lapb_data_transmit+0x90/0xf0 net/lapb/lapb_iface.c:447
 lapb_transmit_buffer+0x260/0x330 net/lapb/lapb_out.c:149
 lapb_send_control+0x458/0x5b0 net/lapb/lapb_subr.c:251
 lapb_establish_data_link+0xa6/0xd0 net/lapb/lapb_out.c:-1
 lapb_device_event+0xb2a/0xbc0 net/lapb/lapb_iface.c:-1
 notifier_call_chain kernel/notifier.c:85 [inline]
 raw_notifier_call_chain+0xe0/0x410 kernel/notifier.c:453
 call_netdevice_notifiers_info+0x1ac/0x2b0 net/core/dev.c:2229
 call_netdevice_notifiers_extack net/core/dev.c:2267 [inline]
 call_netdevice_notifiers net/core/dev.c:2281 [inline]
 __dev_notify_flags+0x20d/0x3c0 net/core/dev.c:-1
 netif_change_flags+0x162/0x1e0 net/core/dev.c:9705
 dev_change_flags+0x18c/0x320 net/core/dev_api.c:68
 devinet_ioctl+0x1186/0x2500 net/ipv4/devinet.c:1199
 inet_ioctl+0x4c0/0x6f0 net/ipv4/af_inet.c:1003
 sock_do_ioctl+0x9c/0x480 net/socket.c:1254
 sock_ioctl+0x70b/0xd60 net/socket.c:1375
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:597 [inline]
 __se_sys_ioctl+0x239/0x400 fs/ioctl.c:583
 __x64_sys_ioctl+0x97/0xe0 fs/ioctl.c:583
 x64_sys_call+0x1cbc/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:17
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at:
 slab_free_hook mm/slub.c:2440 [inline]
 slab_free mm/slub.c:6566 [inline]
 kmem_cache_free+0x2b0/0x1490 mm/slub.c:6676
 skb_kfree_head net/core/skbuff.c:1046 [inline]
 skb_free_head+0x13c/0x3a0 net/core/skbuff.c:1060
 skb_release_data+0x9f7/0xac0 net/core/skbuff.c:1087
 skb_release_all net/core/skbuff.c:1152 [inline]
 __kfree_skb+0x6b/0x260 net/core/skbuff.c:1166
 consume_skb+0x83/0x230 net/core/skbuff.c:1398
 skb_free_datagram+0x1e/0x30 net/core/datagram.c:324
 netlink_recvmsg+0xad1/0xfe0 net/netlink/af_netlink.c:1974
 sock_recvmsg_nosec net/socket.c:1078 [inline]
 sock_recvmsg+0x2dc/0x390 net/socket.c:1100
 ____sys_recvmsg+0x193/0x610 net/socket.c:2850
 ___sys_recvmsg+0x20b/0x850 net/socket.c:2892
 __sys_recvmsg net/socket.c:2925 [inline]
 __do_sys_recvmsg net/socket.c:2931 [inline]
 __se_sys_recvmsg net/socket.c:2928 [inline]
 __x64_sys_recvmsg+0x20e/0x3d0 net/socket.c:2928
 x64_sys_call+0x35f0/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:48
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Bytes 0-17 of 18 are uninitialized
Memory access of size 18 starts at ffff88811a0f1000

CPU: 1 UID: 0 PID: 5441 Comm: dhcpcd Not tainted syzkaller #0 PREEMPT(none) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
=====================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [virt?] upstream test error: KMSAN: use-after-free in vring_map_one_sg

[Jason Wang]

[-- Attachment #1: Type: text/plain, Size: 6037 bytes --]

#syz test

On Sat, Oct 11, 2025 at 4:38 AM syzbot
<syzbot+ac856b8b866cca41352c@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:    ba9dac987319 Merge tag 'libnvdimm-for-6.18' of git://git.k..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=138581e2580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=ad506767107aacda
> dashboard link: https://syzkaller.appspot.com/bug?extid=ac856b8b866cca41352c
> compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/ce6a737acd38/disk-ba9dac98.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/d7053b626642/vmlinux-ba9dac98.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/13f2d7e62179/bzImage-ba9dac98.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+ac856b8b866cca41352c@syzkaller.appspotmail.com
>
> 8021q: adding VLAN 0 to HW filter on device bond0
> eql: remember to turn off Van-Jacobson compression on your slave devices
> =====================================================
> BUG: KMSAN: use-after-free in vring_map_one_sg+0x290/0x7b0 drivers/virtio/virtio_ring.c:401
>  vring_map_one_sg+0x290/0x7b0 drivers/virtio/virtio_ring.c:401
>  virtqueue_add_split drivers/virtio/virtio_ring.c:608 [inline]
>  virtqueue_add+0x32aa/0x6320 drivers/virtio/virtio_ring.c:2281
>  virtqueue_add_outbuf+0x89/0xa0 drivers/virtio/virtio_ring.c:2342
>  virtnet_add_outbuf drivers/net/virtio_net.c:574 [inline]
>  xmit_skb drivers/net/virtio_net.c:3343 [inline]
>  start_xmit+0x274d/0x4860 drivers/net/virtio_net.c:3367
>  __netdev_start_xmit include/linux/netdevice.h:5248 [inline]
>  netdev_start_xmit include/linux/netdevice.h:5257 [inline]
>  xmit_one net/core/dev.c:3845 [inline]
>  dev_hard_start_xmit+0x22c/0xa30 net/core/dev.c:3861
>  sch_direct_xmit+0x3b2/0xcf0 net/sched/sch_generic.c:344
>  __dev_xmit_skb net/core/dev.c:4152 [inline]
>  __dev_queue_xmit+0x3588/0x5e60 net/core/dev.c:4729
>  dev_queue_xmit include/linux/netdevice.h:3365 [inline]
>  lapbeth_data_transmit+0x352/0x480 drivers/net/wan/lapbether.c:260
>  lapb_data_transmit+0x90/0xf0 net/lapb/lapb_iface.c:447
>  lapb_transmit_buffer+0x260/0x330 net/lapb/lapb_out.c:149
>  lapb_send_control+0x458/0x5b0 net/lapb/lapb_subr.c:251
>  lapb_establish_data_link+0xa6/0xd0 net/lapb/lapb_out.c:-1
>  lapb_device_event+0xb2a/0xbc0 net/lapb/lapb_iface.c:-1
>  notifier_call_chain kernel/notifier.c:85 [inline]
>  raw_notifier_call_chain+0xe0/0x410 kernel/notifier.c:453
>  call_netdevice_notifiers_info+0x1ac/0x2b0 net/core/dev.c:2229
>  call_netdevice_notifiers_extack net/core/dev.c:2267 [inline]
>  call_netdevice_notifiers net/core/dev.c:2281 [inline]
>  __dev_notify_flags+0x20d/0x3c0 net/core/dev.c:-1
>  netif_change_flags+0x162/0x1e0 net/core/dev.c:9705
>  dev_change_flags+0x18c/0x320 net/core/dev_api.c:68
>  devinet_ioctl+0x1186/0x2500 net/ipv4/devinet.c:1199
>  inet_ioctl+0x4c0/0x6f0 net/ipv4/af_inet.c:1003
>  sock_do_ioctl+0x9c/0x480 net/socket.c:1254
>  sock_ioctl+0x70b/0xd60 net/socket.c:1375
>  vfs_ioctl fs/ioctl.c:51 [inline]
>  __do_sys_ioctl fs/ioctl.c:597 [inline]
>  __se_sys_ioctl+0x239/0x400 fs/ioctl.c:583
>  __x64_sys_ioctl+0x97/0xe0 fs/ioctl.c:583
>  x64_sys_call+0x1cbc/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:17
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Uninit was created at:
>  slab_free_hook mm/slub.c:2440 [inline]
>  slab_free mm/slub.c:6566 [inline]
>  kmem_cache_free+0x2b0/0x1490 mm/slub.c:6676
>  skb_kfree_head net/core/skbuff.c:1046 [inline]
>  skb_free_head+0x13c/0x3a0 net/core/skbuff.c:1060
>  skb_release_data+0x9f7/0xac0 net/core/skbuff.c:1087
>  skb_release_all net/core/skbuff.c:1152 [inline]
>  __kfree_skb+0x6b/0x260 net/core/skbuff.c:1166
>  consume_skb+0x83/0x230 net/core/skbuff.c:1398
>  skb_free_datagram+0x1e/0x30 net/core/datagram.c:324
>  netlink_recvmsg+0xad1/0xfe0 net/netlink/af_netlink.c:1974
>  sock_recvmsg_nosec net/socket.c:1078 [inline]
>  sock_recvmsg+0x2dc/0x390 net/socket.c:1100
>  ____sys_recvmsg+0x193/0x610 net/socket.c:2850
>  ___sys_recvmsg+0x20b/0x850 net/socket.c:2892
>  __sys_recvmsg net/socket.c:2925 [inline]
>  __do_sys_recvmsg net/socket.c:2931 [inline]
>  __se_sys_recvmsg net/socket.c:2928 [inline]
>  __x64_sys_recvmsg+0x20e/0x3d0 net/socket.c:2928
>  x64_sys_call+0x35f0/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:48
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Bytes 0-17 of 18 are uninitialized
> Memory access of size 18 starts at ffff88811a0f1000
>
> CPU: 1 UID: 0 PID: 5441 Comm: dhcpcd Not tainted syzkaller #0 PREEMPT(none)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
> =====================================================
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
>
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
>
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
>
> If you want to undo deduplication, reply with:
> #syz undup
>

[-- Attachment #2: 0001-virtio-net-zero-unused-hash-fields.patch --]
[-- Type: application/octet-stream, Size: 954 bytes --]

From 43de9f3bb22bbdf22a7f50ea06fe91fea0337830 Mon Sep 17 00:00:00 2001
From: Jason Wang <jasowang@redhat.com>
Date: Sat, 11 Oct 2025 15:38:12 +0800
Subject: [PATCH] virtio-net: zero unused hash fields
Content-type: text/plain

Signed-off-by: Jason Wang <jasowang@redhat.com>
---
 include/linux/virtio_net.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 20e0584db1dd..4d1780848d0e 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -401,6 +401,10 @@ virtio_net_hdr_tnl_from_skb(const struct sk_buff *skb,
 	if (!tnl_hdr_negotiated)
 		return -EINVAL;
 
+        vhdr->hash_hdr.hash_value = 0;
+        vhdr->hash_hdr.hash_report = 0;
+        vhdr->hash_hdr.padding = 0;
+
 	/* Let the basic parsing deal with plain GSO features. */
 	skb_shinfo(skb)->gso_type &= ~tnl_gso_type;
 	ret = virtio_net_hdr_from_skb(skb, hdr, true, false, vlan_hlen);
-- 
2.42.0

Re: [syzbot] [virt?] upstream test error: KMSAN: use-after-free in vring_map_one_sg

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+ac856b8b866cca41352c@syzkaller.appspotmail.com
Tested-by: syzbot+ac856b8b866cca41352c@syzkaller.appspotmail.com

Tested on:

commit:         07394736 Merge tag 'for-6.18/hpfs-changes' of git://gi..
git tree:       upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=60ff1a9f60b0f77d
dashboard link: https://syzkaller.appspot.com/bug?extid=ac856b8b866cca41352c
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=17a7a9e2580000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [virt?] upstream test error: KMSAN: use-after-free in vring_map_one_sg

[Jason Wang]

Adding Paolo.

On Sat, Oct 11, 2025 at 3:40 PM Jason Wang <jasowang@redhat.com> wrote:
>
> #syz test
>
> On Sat, Oct 11, 2025 at 4:38 AM syzbot
> <syzbot+ac856b8b866cca41352c@syzkaller.appspotmail.com> wrote:

Paolo, it looks like the GSO tunnel features will leave uninitialized
vnet header field which trigger KMSAN warning.

Please have a look at the patch (which has been tested by syzbot) or
propose another one.

Thanks

> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:    ba9dac987319 Merge tag 'libnvdimm-for-6.18' of git://git.k..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=138581e2580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=ad506767107aacda
> > dashboard link: https://syzkaller.appspot.com/bug?extid=ac856b8b866cca41352c
> > compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/ce6a737acd38/disk-ba9dac98.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/d7053b626642/vmlinux-ba9dac98.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/13f2d7e62179/bzImage-ba9dac98.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+ac856b8b866cca41352c@syzkaller.appspotmail.com
> >
> > 8021q: adding VLAN 0 to HW filter on device bond0
> > eql: remember to turn off Van-Jacobson compression on your slave devices
> > =====================================================
> > BUG: KMSAN: use-after-free in vring_map_one_sg+0x290/0x7b0 drivers/virtio/virtio_ring.c:401
> >  vring_map_one_sg+0x290/0x7b0 drivers/virtio/virtio_ring.c:401
> >  virtqueue_add_split drivers/virtio/virtio_ring.c:608 [inline]
> >  virtqueue_add+0x32aa/0x6320 drivers/virtio/virtio_ring.c:2281
> >  virtqueue_add_outbuf+0x89/0xa0 drivers/virtio/virtio_ring.c:2342
> >  virtnet_add_outbuf drivers/net/virtio_net.c:574 [inline]
> >  xmit_skb drivers/net/virtio_net.c:3343 [inline]
> >  start_xmit+0x274d/0x4860 drivers/net/virtio_net.c:3367
> >  __netdev_start_xmit include/linux/netdevice.h:5248 [inline]
> >  netdev_start_xmit include/linux/netdevice.h:5257 [inline]
> >  xmit_one net/core/dev.c:3845 [inline]
> >  dev_hard_start_xmit+0x22c/0xa30 net/core/dev.c:3861
> >  sch_direct_xmit+0x3b2/0xcf0 net/sched/sch_generic.c:344
> >  __dev_xmit_skb net/core/dev.c:4152 [inline]
> >  __dev_queue_xmit+0x3588/0x5e60 net/core/dev.c:4729
> >  dev_queue_xmit include/linux/netdevice.h:3365 [inline]
> >  lapbeth_data_transmit+0x352/0x480 drivers/net/wan/lapbether.c:260
> >  lapb_data_transmit+0x90/0xf0 net/lapb/lapb_iface.c:447
> >  lapb_transmit_buffer+0x260/0x330 net/lapb/lapb_out.c:149
> >  lapb_send_control+0x458/0x5b0 net/lapb/lapb_subr.c:251
> >  lapb_establish_data_link+0xa6/0xd0 net/lapb/lapb_out.c:-1
> >  lapb_device_event+0xb2a/0xbc0 net/lapb/lapb_iface.c:-1
> >  notifier_call_chain kernel/notifier.c:85 [inline]
> >  raw_notifier_call_chain+0xe0/0x410 kernel/notifier.c:453
> >  call_netdevice_notifiers_info+0x1ac/0x2b0 net/core/dev.c:2229
> >  call_netdevice_notifiers_extack net/core/dev.c:2267 [inline]
> >  call_netdevice_notifiers net/core/dev.c:2281 [inline]
> >  __dev_notify_flags+0x20d/0x3c0 net/core/dev.c:-1
> >  netif_change_flags+0x162/0x1e0 net/core/dev.c:9705
> >  dev_change_flags+0x18c/0x320 net/core/dev_api.c:68
> >  devinet_ioctl+0x1186/0x2500 net/ipv4/devinet.c:1199
> >  inet_ioctl+0x4c0/0x6f0 net/ipv4/af_inet.c:1003
> >  sock_do_ioctl+0x9c/0x480 net/socket.c:1254
> >  sock_ioctl+0x70b/0xd60 net/socket.c:1375
> >  vfs_ioctl fs/ioctl.c:51 [inline]
> >  __do_sys_ioctl fs/ioctl.c:597 [inline]
> >  __se_sys_ioctl+0x239/0x400 fs/ioctl.c:583
> >  __x64_sys_ioctl+0x97/0xe0 fs/ioctl.c:583
> >  x64_sys_call+0x1cbc/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:17
> >  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> >  do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
> >  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> >
> > Uninit was created at:
> >  slab_free_hook mm/slub.c:2440 [inline]
> >  slab_free mm/slub.c:6566 [inline]
> >  kmem_cache_free+0x2b0/0x1490 mm/slub.c:6676
> >  skb_kfree_head net/core/skbuff.c:1046 [inline]
> >  skb_free_head+0x13c/0x3a0 net/core/skbuff.c:1060
> >  skb_release_data+0x9f7/0xac0 net/core/skbuff.c:1087
> >  skb_release_all net/core/skbuff.c:1152 [inline]
> >  __kfree_skb+0x6b/0x260 net/core/skbuff.c:1166
> >  consume_skb+0x83/0x230 net/core/skbuff.c:1398
> >  skb_free_datagram+0x1e/0x30 net/core/datagram.c:324
> >  netlink_recvmsg+0xad1/0xfe0 net/netlink/af_netlink.c:1974
> >  sock_recvmsg_nosec net/socket.c:1078 [inline]
> >  sock_recvmsg+0x2dc/0x390 net/socket.c:1100
> >  ____sys_recvmsg+0x193/0x610 net/socket.c:2850
> >  ___sys_recvmsg+0x20b/0x850 net/socket.c:2892
> >  __sys_recvmsg net/socket.c:2925 [inline]
> >  __do_sys_recvmsg net/socket.c:2931 [inline]
> >  __se_sys_recvmsg net/socket.c:2928 [inline]
> >  __x64_sys_recvmsg+0x20e/0x3d0 net/socket.c:2928
> >  x64_sys_call+0x35f0/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:48
> >  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> >  do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
> >  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> >
> > Bytes 0-17 of 18 are uninitialized
> > Memory access of size 18 starts at ffff88811a0f1000
> >
> > CPU: 1 UID: 0 PID: 5441 Comm: dhcpcd Not tainted syzkaller #0 PREEMPT(none)
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
> > =====================================================
> >
> >
> > ---
> > This report is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkaller@googlegroups.com.
> >
> > syzbot will keep track of this issue. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> >
> > If the report is already addressed, let syzbot know by replying with:
> > #syz fix: exact-commit-title
> >
> > If you want to overwrite report's subsystems, reply with:
> > #syz set subsystems: new-subsystem
> > (See the list of subsystem names on the web dashboard)
> >
> > If the report is a duplicate of another one, reply with:
> > #syz dup: exact-subject-of-another-report
> >
> > If you want to undo deduplication, reply with:
> > #syz undup
> >

Re: [syzbot] [virt?] upstream test error: KMSAN: use-after-free in vring_map_one_sg

[Jason Wang]

[-- Attachment #1: Type: text/plain, Size: 6991 bytes --]

On Mon, Oct 13, 2025 at 1:29 PM Jason Wang <jasowang@redhat.com> wrote:
>
> Adding Paolo.
>
> On Sat, Oct 11, 2025 at 3:40 PM Jason Wang <jasowang@redhat.com> wrote:
> >
> > #syz test
> >
> > On Sat, Oct 11, 2025 at 4:38 AM syzbot
> > <syzbot+ac856b8b866cca41352c@syzkaller.appspotmail.com> wrote:
>
> Paolo, it looks like the GSO tunnel features will leave uninitialized
> vnet header field which trigger KMSAN warning.
>
> Please have a look at the patch (which has been tested by syzbot) or
> propose another one.

Forget the attachment.

Thanks

>
> Thanks
>
> > >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:    ba9dac987319 Merge tag 'libnvdimm-for-6.18' of git://git.k..
> > > git tree:       upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=138581e2580000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=ad506767107aacda
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=ac856b8b866cca41352c
> > > compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> > >
> > > Downloadable assets:
> > > disk image: https://storage.googleapis.com/syzbot-assets/ce6a737acd38/disk-ba9dac98.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/d7053b626642/vmlinux-ba9dac98.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/13f2d7e62179/bzImage-ba9dac98.xz
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+ac856b8b866cca41352c@syzkaller.appspotmail.com
> > >
> > > 8021q: adding VLAN 0 to HW filter on device bond0
> > > eql: remember to turn off Van-Jacobson compression on your slave devices
> > > =====================================================
> > > BUG: KMSAN: use-after-free in vring_map_one_sg+0x290/0x7b0 drivers/virtio/virtio_ring.c:401
> > >  vring_map_one_sg+0x290/0x7b0 drivers/virtio/virtio_ring.c:401
> > >  virtqueue_add_split drivers/virtio/virtio_ring.c:608 [inline]
> > >  virtqueue_add+0x32aa/0x6320 drivers/virtio/virtio_ring.c:2281
> > >  virtqueue_add_outbuf+0x89/0xa0 drivers/virtio/virtio_ring.c:2342
> > >  virtnet_add_outbuf drivers/net/virtio_net.c:574 [inline]
> > >  xmit_skb drivers/net/virtio_net.c:3343 [inline]
> > >  start_xmit+0x274d/0x4860 drivers/net/virtio_net.c:3367
> > >  __netdev_start_xmit include/linux/netdevice.h:5248 [inline]
> > >  netdev_start_xmit include/linux/netdevice.h:5257 [inline]
> > >  xmit_one net/core/dev.c:3845 [inline]
> > >  dev_hard_start_xmit+0x22c/0xa30 net/core/dev.c:3861
> > >  sch_direct_xmit+0x3b2/0xcf0 net/sched/sch_generic.c:344
> > >  __dev_xmit_skb net/core/dev.c:4152 [inline]
> > >  __dev_queue_xmit+0x3588/0x5e60 net/core/dev.c:4729
> > >  dev_queue_xmit include/linux/netdevice.h:3365 [inline]
> > >  lapbeth_data_transmit+0x352/0x480 drivers/net/wan/lapbether.c:260
> > >  lapb_data_transmit+0x90/0xf0 net/lapb/lapb_iface.c:447
> > >  lapb_transmit_buffer+0x260/0x330 net/lapb/lapb_out.c:149
> > >  lapb_send_control+0x458/0x5b0 net/lapb/lapb_subr.c:251
> > >  lapb_establish_data_link+0xa6/0xd0 net/lapb/lapb_out.c:-1
> > >  lapb_device_event+0xb2a/0xbc0 net/lapb/lapb_iface.c:-1
> > >  notifier_call_chain kernel/notifier.c:85 [inline]
> > >  raw_notifier_call_chain+0xe0/0x410 kernel/notifier.c:453
> > >  call_netdevice_notifiers_info+0x1ac/0x2b0 net/core/dev.c:2229
> > >  call_netdevice_notifiers_extack net/core/dev.c:2267 [inline]
> > >  call_netdevice_notifiers net/core/dev.c:2281 [inline]
> > >  __dev_notify_flags+0x20d/0x3c0 net/core/dev.c:-1
> > >  netif_change_flags+0x162/0x1e0 net/core/dev.c:9705
> > >  dev_change_flags+0x18c/0x320 net/core/dev_api.c:68
> > >  devinet_ioctl+0x1186/0x2500 net/ipv4/devinet.c:1199
> > >  inet_ioctl+0x4c0/0x6f0 net/ipv4/af_inet.c:1003
> > >  sock_do_ioctl+0x9c/0x480 net/socket.c:1254
> > >  sock_ioctl+0x70b/0xd60 net/socket.c:1375
> > >  vfs_ioctl fs/ioctl.c:51 [inline]
> > >  __do_sys_ioctl fs/ioctl.c:597 [inline]
> > >  __se_sys_ioctl+0x239/0x400 fs/ioctl.c:583
> > >  __x64_sys_ioctl+0x97/0xe0 fs/ioctl.c:583
> > >  x64_sys_call+0x1cbc/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:17
> > >  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> > >  do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
> > >  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> > >
> > > Uninit was created at:
> > >  slab_free_hook mm/slub.c:2440 [inline]
> > >  slab_free mm/slub.c:6566 [inline]
> > >  kmem_cache_free+0x2b0/0x1490 mm/slub.c:6676
> > >  skb_kfree_head net/core/skbuff.c:1046 [inline]
> > >  skb_free_head+0x13c/0x3a0 net/core/skbuff.c:1060
> > >  skb_release_data+0x9f7/0xac0 net/core/skbuff.c:1087
> > >  skb_release_all net/core/skbuff.c:1152 [inline]
> > >  __kfree_skb+0x6b/0x260 net/core/skbuff.c:1166
> > >  consume_skb+0x83/0x230 net/core/skbuff.c:1398
> > >  skb_free_datagram+0x1e/0x30 net/core/datagram.c:324
> > >  netlink_recvmsg+0xad1/0xfe0 net/netlink/af_netlink.c:1974
> > >  sock_recvmsg_nosec net/socket.c:1078 [inline]
> > >  sock_recvmsg+0x2dc/0x390 net/socket.c:1100
> > >  ____sys_recvmsg+0x193/0x610 net/socket.c:2850
> > >  ___sys_recvmsg+0x20b/0x850 net/socket.c:2892
> > >  __sys_recvmsg net/socket.c:2925 [inline]
> > >  __do_sys_recvmsg net/socket.c:2931 [inline]
> > >  __se_sys_recvmsg net/socket.c:2928 [inline]
> > >  __x64_sys_recvmsg+0x20e/0x3d0 net/socket.c:2928
> > >  x64_sys_call+0x35f0/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:48
> > >  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> > >  do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
> > >  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> > >
> > > Bytes 0-17 of 18 are uninitialized
> > > Memory access of size 18 starts at ffff88811a0f1000
> > >
> > > CPU: 1 UID: 0 PID: 5441 Comm: dhcpcd Not tainted syzkaller #0 PREEMPT(none)
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
> > > =====================================================
> > >
> > >
> > > ---
> > > This report is generated by a bot. It may contain errors.
> > > See https://goo.gl/tpsmEJ for more information about syzbot.
> > > syzbot engineers can be reached at syzkaller@googlegroups.com.
> > >
> > > syzbot will keep track of this issue. See:
> > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> > >
> > > If the report is already addressed, let syzbot know by replying with:
> > > #syz fix: exact-commit-title
> > >
> > > If you want to overwrite report's subsystems, reply with:
> > > #syz set subsystems: new-subsystem
> > > (See the list of subsystem names on the web dashboard)
> > >
> > > If the report is a duplicate of another one, reply with:
> > > #syz dup: exact-subject-of-another-report
> > >
> > > If you want to undo deduplication, reply with:
> > > #syz undup
> > >

[-- Attachment #2: 0001-virtio-net-zero-unused-hash-fields.patch --]
[-- Type: application/octet-stream, Size: 954 bytes --]

From 43de9f3bb22bbdf22a7f50ea06fe91fea0337830 Mon Sep 17 00:00:00 2001
From: Jason Wang <jasowang@redhat.com>
Date: Sat, 11 Oct 2025 15:38:12 +0800
Subject: [PATCH] virtio-net: zero unused hash fields
Content-type: text/plain

Signed-off-by: Jason Wang <jasowang@redhat.com>
---
 include/linux/virtio_net.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 20e0584db1dd..4d1780848d0e 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -401,6 +401,10 @@ virtio_net_hdr_tnl_from_skb(const struct sk_buff *skb,
 	if (!tnl_hdr_negotiated)
 		return -EINVAL;
 
+        vhdr->hash_hdr.hash_value = 0;
+        vhdr->hash_hdr.hash_report = 0;
+        vhdr->hash_hdr.padding = 0;
+
 	/* Let the basic parsing deal with plain GSO features. */
 	skb_shinfo(skb)->gso_type &= ~tnl_gso_type;
 	ret = virtio_net_hdr_from_skb(skb, hdr, true, false, vlan_hlen);
-- 
2.42.0

Re: [syzbot] [virt?] upstream test error: KMSAN: use-after-free in vring_map_one_sg

[Paolo Abeni]

On 10/13/25 9:20 AM, Jason Wang wrote:
> On Mon, Oct 13, 2025 at 1:29 PM Jason Wang <jasowang@redhat.com> wrote:
>> On Sat, Oct 11, 2025 at 3:40 PM Jason Wang <jasowang@redhat.com> wrote:
>>>
>>> #syz test
>>>
>>> On Sat, Oct 11, 2025 at 4:38 AM syzbot
>>> <syzbot+ac856b8b866cca41352c@syzkaller.appspotmail.com> wrote:
>>
>> Paolo, it looks like the GSO tunnel features will leave uninitialized
>> vnet header field which trigger KMSAN warning.
>>
>> Please have a look at the patch (which has been tested by syzbot) or
>> propose another one.
> 
> Forget the attachment.

I have a few questions. The report mentions both UaF and uninit; the
patch addresses "just" the uninit access. It's not clear to me if and
how the UaF is addressed, and why/if it's related to the uninit access.
Do you know better?

It looks like the uninit root cause is on "the other side"? i.e. the
device not initializing properly the header. Would unconditionally
clearing the hash info implicitly disable such feature?

The syzbot dashboard mentions a (no more available) reproducer. Do you
have it cached somewhere?

Thanks,

Paolo

Re: [syzbot] [virt?] upstream test error: KMSAN: use-after-free in vring_map_one_sg

[Michael S. Tsirkin]

On Mon, Oct 13, 2025 at 09:37:29AM +0200, Paolo Abeni wrote:
> On 10/13/25 9:20 AM, Jason Wang wrote:
> > On Mon, Oct 13, 2025 at 1:29 PM Jason Wang <jasowang@redhat.com> wrote:
> >> On Sat, Oct 11, 2025 at 3:40 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>
> >>> #syz test
> >>>
> >>> On Sat, Oct 11, 2025 at 4:38 AM syzbot
> >>> <syzbot+ac856b8b866cca41352c@syzkaller.appspotmail.com> wrote:
> >>
> >> Paolo, it looks like the GSO tunnel features will leave uninitialized
> >> vnet header field which trigger KMSAN warning.
> >>
> >> Please have a look at the patch (which has been tested by syzbot) or
> >> propose another one.
> > 
> > Forget the attachment.
> 
> I have a few questions. The report mentions both UaF and uninit; the
> patch addresses "just" the uninit access. It's not clear to me if and
> how the UaF is addressed, and why/if it's related to the uninit access.


I'd like to understand that, too.

> Do you know better?
> 
> It looks like the uninit root cause is on "the other side"? i.e. the
> device not initializing properly the header. Would unconditionally
> clearing the hash info implicitly disable such feature?
> 
> The syzbot dashboard mentions a (no more available) reproducer. Do you
> have it cached somewhere?
> 
> Thanks,
> 
> Paolo

Re: [syzbot] [virt?] upstream test error: KMSAN: use-after-free in vring_map_one_sg

[Paolo Abeni]

On 10/13/25 10:08 AM, Michael S. Tsirkin wrote:
> On Mon, Oct 13, 2025 at 09:37:29AM +0200, Paolo Abeni wrote:
>> On 10/13/25 9:20 AM, Jason Wang wrote:
>>> On Mon, Oct 13, 2025 at 1:29 PM Jason Wang <jasowang@redhat.com> wrote:
>>>> On Sat, Oct 11, 2025 at 3:40 PM Jason Wang <jasowang@redhat.com> wrote:
>>>>>
>>>>> #syz test
>>>>>
>>>>> On Sat, Oct 11, 2025 at 4:38 AM syzbot
>>>>> <syzbot+ac856b8b866cca41352c@syzkaller.appspotmail.com> wrote:
>>>>
>>>> Paolo, it looks like the GSO tunnel features will leave uninitialized
>>>> vnet header field which trigger KMSAN warning.
>>>>
>>>> Please have a look at the patch (which has been tested by syzbot) or
>>>> propose another one.
>>>
>>> Forget the attachment.
>>
>> I have a few questions. The report mentions both UaF and uninit; the
>> patch addresses "just" the uninit access. It's not clear to me if and
>> how the UaF is addressed, and why/if it's related to the uninit access.
> 
> I'd like to understand that, too.

Somewhat related: the syzbot dashboard reports that the issue is no more
reproducible on plain Linus' tree:

https://syzkaller.appspot.com/bug?extid=ac856b8b866cca41352c

"""
* repros no longer work on HEAD.
"""

Possibly there was some external problem?

/P

Re: [syzbot] [virt?] upstream test error: KMSAN: use-after-free in vring_map_one_sg

[Jason Wang]

On Mon, Oct 13, 2025 at 4:17 PM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On 10/13/25 10:08 AM, Michael S. Tsirkin wrote:
> > On Mon, Oct 13, 2025 at 09:37:29AM +0200, Paolo Abeni wrote:
> >> On 10/13/25 9:20 AM, Jason Wang wrote:
> >>> On Mon, Oct 13, 2025 at 1:29 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>> On Sat, Oct 11, 2025 at 3:40 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>>>
> >>>>> #syz test
> >>>>>
> >>>>> On Sat, Oct 11, 2025 at 4:38 AM syzbot
> >>>>> <syzbot+ac856b8b866cca41352c@syzkaller.appspotmail.com> wrote:
> >>>>
> >>>> Paolo, it looks like the GSO tunnel features will leave uninitialized
> >>>> vnet header field which trigger KMSAN warning.
> >>>>
> >>>> Please have a look at the patch (which has been tested by syzbot) or
> >>>> propose another one.
> >>>
> >>> Forget the attachment.
> >>
> >> I have a few questions. The report mentions both UaF and uninit; the
> >> patch addresses "just" the uninit access. It's not clear to me if and
> >> how the UaF is addressed, and why/if it's related to the uninit access.
> >
> > I'd like to understand that, too.
>
> Somewhat related: the syzbot dashboard reports that the issue is no more
> reproducible on plain Linus' tree:
>
> https://syzkaller.appspot.com/bug?extid=ac856b8b866cca41352c

Interesting.

>
> """
> * repros no longer work on HEAD.
> """
>
> Possibly there was some external problem?

I think at least we need to make sure no information as we did in
virtio_net_hdr_from_skb():

static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
                                          struct virtio_net_hdr *hdr,
                                          bool little_endian,
                                          bool has_data_valid,
                                          int vlan_hlen)
{
        memset(hdr, 0, sizeof(*hdr));   /* no info leak */

Thanks

>
> /P
>
>

Re: [syzbot] [virt?] upstream test error: KMSAN: use-after-free in vring_map_one_sg

[Paolo Abeni]

On 10/14/25 4:41 AM, Jason Wang wrote:
> On Mon, Oct 13, 2025 at 4:17 PM Paolo Abeni <pabeni@redhat.com> wrote:
>> On 10/13/25 10:08 AM, Michael S. Tsirkin wrote:
>>> On Mon, Oct 13, 2025 at 09:37:29AM +0200, Paolo Abeni wrote:
>>>> On 10/13/25 9:20 AM, Jason Wang wrote:
>>>>> On Mon, Oct 13, 2025 at 1:29 PM Jason Wang <jasowang@redhat.com> wrote:
>>>>>> On Sat, Oct 11, 2025 at 3:40 PM Jason Wang <jasowang@redhat.com> wrote:
>>>>>>>
>>>>>>> #syz test
>>>>>>>
>>>>>>> On Sat, Oct 11, 2025 at 4:38 AM syzbot
>>>>>>> <syzbot+ac856b8b866cca41352c@syzkaller.appspotmail.com> wrote:
>>>>>>
>>>>>> Paolo, it looks like the GSO tunnel features will leave uninitialized
>>>>>> vnet header field which trigger KMSAN warning.
>>>>>>
>>>>>> Please have a look at the patch (which has been tested by syzbot) or
>>>>>> propose another one.
>>>>>
>>>>> Forget the attachment.
>>>>
>>>> I have a few questions. The report mentions both UaF and uninit; the
>>>> patch addresses "just" the uninit access. It's not clear to me if and
>>>> how the UaF is addressed, and why/if it's related to the uninit access.
>>>
>>> I'd like to understand that, too.
>>
>> Somewhat related: the syzbot dashboard reports that the issue is no more
>> reproducible on plain Linus' tree:
>>
>> https://syzkaller.appspot.com/bug?extid=ac856b8b866cca41352c
> 
> Interesting.
> 
>>
>> """
>> * repros no longer work on HEAD.
>> """
>>
>> Possibly there was some external problem?
> 
> I think at least we need to make sure no information as we did in
> virtio_net_hdr_from_skb():
> 
> static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
>                                           struct virtio_net_hdr *hdr,
>                                           bool little_endian,
>                                           bool has_data_valid,
>                                           int vlan_hlen)
> {
>         memset(hdr, 0, sizeof(*hdr));   /* no info leak */

I agree it makes sense to fully initialize the
virtio_net_hdr_v1_hash_tunnel struct. I would prefer to individually
zero the related fields (as in your initial patch). Hopefully the
compiler is smart enough to generate a single 64bit store instruction.

Still the backtrace reported by syzbot makes little sense to me: "uninit
created" at skb free time?!? UaF ?!? I suggest avoiding explicitly
marking the syzbot report closed with the formal patch.

Thanks,

Paolo

Re: [syzbot] [virt?] upstream test error: KMSAN: use-after-free in vring_map_one_sg

[Jason Wang]

On Mon, Oct 13, 2025 at 4:08 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Mon, Oct 13, 2025 at 09:37:29AM +0200, Paolo Abeni wrote:
> > On 10/13/25 9:20 AM, Jason Wang wrote:
> > > On Mon, Oct 13, 2025 at 1:29 PM Jason Wang <jasowang@redhat.com> wrote:
> > >> On Sat, Oct 11, 2025 at 3:40 PM Jason Wang <jasowang@redhat.com> wrote:
> > >>>
> > >>> #syz test
> > >>>
> > >>> On Sat, Oct 11, 2025 at 4:38 AM syzbot
> > >>> <syzbot+ac856b8b866cca41352c@syzkaller.appspotmail.com> wrote:
> > >>
> > >> Paolo, it looks like the GSO tunnel features will leave uninitialized
> > >> vnet header field which trigger KMSAN warning.
> > >>
> > >> Please have a look at the patch (which has been tested by syzbot) or
> > >> propose another one.
> > >
> > > Forget the attachment.
> >
> > I have a few questions. The report mentions both UaF and uninit; the
> > patch addresses "just" the uninit access. It's not clear to me if and
> > how the UaF is addressed, and why/if it's related to the uninit access.
>
>
> I'd like to understand that, too.
>
> > Do you know better?

Unfortunately, I didn't spot any UAF.

> >
> > It looks like the uninit root cause is on "the other side"? i.e. the
> > device not initializing properly the header.

The trace is in the TX path, so it's not the device side.

> > Would unconditionally
> > clearing the hash info implicitly disable such feature?

The feature is not used on the TX side in virtio-net. On the RX side
(e.g TUN) it has not been implemented yet.

> >
> > The syzbot dashboard mentions a (no more available) reproducer. Do you
> > have it cached somewhere?

I don't.

Thanks

> >
> > Thanks,
> >
> > Paolo
>