[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+ac856b...@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 syzk...@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

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: Re: [syzbot] [virt?] upstream test error: KMSAN: use-after-free in vring_map_one_sg
Author: jaso...@redhat.com

#syz test

[syzbot]

Hello,

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

Reported-by: syzbot+ac856b...@syzkaller.appspotmail.com
Tested-by: syzbot+ac856b...@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=11361b34580000

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

[Jason Wang]

#syz test

On Sat, Oct 11, 2025 at 4:38 AM syzbot
<syzbot+ac856b...@syzkaller.appspotmail.com> wrote:
>

[syzbot]

Hello,

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

Reported-by: syzbot+ac856b...@syzkaller.appspotmail.com
Tested-by: syzbot+ac856b...@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

[Jason Wang]

Adding Paolo.

On Sat, Oct 11, 2025 at 3:40 PM Jason Wang <jaso...@redhat.com> wrote:
>
> #syz test
>
> On Sat, Oct 11, 2025 at 4:38 AM syzbot
> <syzbot+ac856b...@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

[Jason Wang]

On Mon, Oct 13, 2025 at 1:29 PM Jason Wang <jaso...@redhat.com> wrote:
>
> Adding Paolo.
>
> On Sat, Oct 11, 2025 at 3:40 PM Jason Wang <jaso...@redhat.com> wrote:
> >
> > #syz test
> >
> > On Sat, Oct 11, 2025 at 4:38 AM syzbot
> > <syzbot+ac856b...@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

[Paolo Abeni]

On 10/13/25 9:20 AM, Jason Wang wrote:
> On Mon, Oct 13, 2025 at 1:29 PM Jason Wang <jaso...@redhat.com> wrote:
>> On Sat, Oct 11, 2025 at 3:40 PM Jason Wang <jaso...@redhat.com> wrote:
>>>
>>> #syz test
>>>
>>> On Sat, Oct 11, 2025 at 4:38 AM syzbot
>>> <syzbot+ac856b...@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

[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 <jaso...@redhat.com> wrote:
> >> On Sat, Oct 11, 2025 at 3:40 PM Jason Wang <jaso...@redhat.com> wrote:
> >>>
> >>> #syz test
> >>>
> >>> On Sat, Oct 11, 2025 at 4:38 AM syzbot
> >>> <syzbot+ac856b...@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.

[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 <jaso...@redhat.com> wrote:
>>>> On Sat, Oct 11, 2025 at 3:40 PM Jason Wang <jaso...@redhat.com> wrote:
>>>>>
>>>>> #syz test
>>>>>
>>>>> On Sat, Oct 11, 2025 at 4:38 AM syzbot
>>>>> <syzbot+ac856b...@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

[Jason Wang]

On Mon, Oct 13, 2025 at 4:08 PM Michael S. Tsirkin <m...@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 <jaso...@redhat.com> wrote:
> > >> On Sat, Oct 11, 2025 at 3:40 PM Jason Wang <jaso...@redhat.com> wrote:
> > >>>
> > >>> #syz test
> > >>>
> > >>> On Sat, Oct 11, 2025 at 4:38 AM syzbot
> > >>> <syzbot+ac856b...@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
>

[Jason Wang]

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
>
>

[Paolo Abeni]

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