[syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    37816488247d Merge tag 'net-6.17-rc1' of git://git.kernel...
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10b3b2f0580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=e143c1cd9dadd720
dashboard link: https://syzkaller.appspot.com/bug?extid=b4d960daf7a3c7c2b7b1
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10f0f042580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14855434580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-37816488.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/74b3ac8946d4/vmlinux-37816488.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a2b391aacaec/bzImage-37816488.xz

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

------------[ cut here ]------------
'send_pkt()' returns 0, but 65536 expected
WARNING: CPU: 0 PID: 5503 at net/vmw_vsock/virtio_transport_common.c:428 virtio_transport_send_pkt_info+0xd11/0xf00 net/vmw_vsock/virtio_transport_common.c:426
Modules linked in:
CPU: 0 UID: 0 PID: 5503 Comm: syz.0.17 Not tainted 6.16.0-syzkaller-12063-g37816488247d #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:virtio_transport_send_pkt_info+0xd11/0xf00 net/vmw_vsock/virtio_transport_common.c:426
Code: 0f 0b 90 bd f2 ff ff ff eb bc e8 8a 20 65 f6 c6 05 94 cf 32 04 01 90 48 c7 c7 00 c3 b8 8c 44 89 f6 4c 89 ea e8 40 af 28 f6 90 <0f> 0b 90 90 e9 e1 fe ff ff e8 61 20 65 f6 90 0f 0b 90 e9 c5 f7 ff
RSP: 0018:ffffc900027ff530 EFLAGS: 00010246
RAX: d7fcdfc663889c00 RBX: 0000000000010000 RCX: ffff888000e1a440
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000002
RBP: ffffffff8f8764d0 R08: ffff88801fc24253 R09: 1ffff11003f8484a
R10: dffffc0000000000 R11: ffffed1003f8484b R12: dffffc0000000000
R13: 0000000000010000 R14: 0000000000000000 R15: ffff888058b48024
FS:  000055556bda1500(0000) GS:ffff88808d218000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000020000003f000 CR3: 000000003f6db000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 virtio_transport_stream_enqueue net/vmw_vsock/virtio_transport_common.c:1111 [inline]
 virtio_transport_seqpacket_enqueue+0x143/0x1c0 net/vmw_vsock/virtio_transport_common.c:839
 vsock_connectible_sendmsg+0xac7/0x1050 net/vmw_vsock/af_vsock.c:2140
 sock_sendmsg_nosec net/socket.c:714 [inline]
 __sock_sendmsg+0x21c/0x270 net/socket.c:729
 ____sys_sendmsg+0x52d/0x830 net/socket.c:2614
 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668
 __sys_sendmmsg+0x227/0x430 net/socket.c:2757
 __do_sys_sendmmsg net/socket.c:2784 [inline]
 __se_sys_sendmmsg net/socket.c:2781 [inline]
 __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2781
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fddc238ebe9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd48081028 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
RAX: ffffffffffffffda RBX: 00007fddc25b5fa0 RCX: 00007fddc238ebe9
RDX: 0000000000000001 RSI: 0000200000000100 RDI: 0000000000000004
RBP: 00007fddc2411e19 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000024008094 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fddc25b5fa0 R14: 00007fddc25b5fa0 R15: 0000000000000004
 </TASK>


---
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 syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

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

Forwarded: Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[syzbot]

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

***

Subject: Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info
Author: mst@redhat.com


#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index f9193f952f49..a8c90676d715 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -1149,10 +1149,15 @@ static ssize_t __iov_iter_get_pages_alloc(struct iov_iter *i,
 {
 	unsigned int n, gup_flags = 0;
 
+	pr_err("DEBUG: __iov_iter_get_pages_alloc: initial maxsize=%zu, i->count=%zu\n",
+	       maxsize, i->count);
+
 	if (maxsize > i->count)
 		maxsize = i->count;
-	if (!maxsize)
+	if (!maxsize) {
+		pr_err("DEBUG: __iov_iter_get_pages_alloc: returning 0 - no maxsize\n");
 		return 0;
+	}
 	if (maxsize > MAX_RW_COUNT)
 		maxsize = MAX_RW_COUNT;
 
@@ -1166,15 +1171,31 @@ static ssize_t __iov_iter_get_pages_alloc(struct iov_iter *i,
 			gup_flags |= FOLL_NOFAULT;
 
 		addr = first_iovec_segment(i, &maxsize);
+		pr_err("DEBUG: first_iovec_segment returned addr=%lx, maxsize_after=%zu\n",
+		       addr, maxsize);
+
 		*start = addr % PAGE_SIZE;
 		addr &= PAGE_MASK;
 		n = want_pages_array(pages, maxsize, *start, maxpages);
+
+		pr_err("DEBUG: want_pages_array returned n=%u, addr=%lx, start=%zu\n",
+		       n, addr, *start);
+
 		if (!n)
 			return -ENOMEM;
+
 		res = get_user_pages_fast(addr, n, gup_flags, *pages);
+
+		pr_err("DEBUG: get_user_pages_fast returned res=%d (requested n=%u)\n",
+		       res, n);
+
 		if (unlikely(res <= 0))
 			return res;
+
 		maxsize = min_t(size_t, maxsize, res * PAGE_SIZE - *start);
+
+		pr_err("DEBUG: final maxsize=%zu, advancing iterator\n", maxsize);
+
 		iov_iter_advance(i, maxsize);
 		return maxsize;
 	}
@@ -1213,11 +1234,21 @@ static ssize_t __iov_iter_get_pages_alloc(struct iov_iter *i,
 ssize_t iov_iter_get_pages2(struct iov_iter *i, struct page **pages,
 		size_t maxsize, unsigned maxpages, size_t *start)
 {
+	ssize_t result;
+
+	pr_err("DEBUG: iov_iter_get_pages2: maxsize=%zu, maxpages=%u, iter_count=%zu, iter_type=%u\n",
+	       maxsize, maxpages, iov_iter_count(i), i->iter_type);
+
 	if (!maxpages)
 		return 0;
 	BUG_ON(!pages);
 
-	return __iov_iter_get_pages_alloc(i, &pages, maxsize, maxpages, start);
+	result = __iov_iter_get_pages_alloc(i, &pages, maxsize, maxpages, start);
+
+	pr_err("DEBUG: iov_iter_get_pages2: returning result=%zd, start=%zu, iter_count_after=%zu\n",
+	       result, start ? *start : 0, iov_iter_count(i));
+
+	return result;
 }
 EXPORT_SYMBOL(iov_iter_get_pages2);
 
diff --git a/net/core/datagram.c b/net/core/datagram.c
index 94cc4705e91d..135dc37bd746 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -623,6 +623,21 @@ int zerocopy_fill_skb_from_iter(struct sk_buff *skb,
 {
 	int frag = skb_shinfo(skb)->nr_frags;
 
+	pr_err("DEBUG: zerocopy_fill_skb_from_iter: initial length=%zu, iov_iter_count=%zu, iter_type=%u\n",
+	       length, iov_iter_count(from), from->iter_type);
+
+	if (from->iter_type == ITER_IOVEC) {
+		pr_err("DEBUG: IOVEC iterator: nr_segs=%lu, iov_offset=%zu\n",
+		       from->nr_segs, from->iov_offset);
+		if (from->__iov && from->nr_segs > 0) {
+			pr_err("DEBUG: Current iovec[0]: base=%px, len=%zu\n",
+			       from->__iov[0].iov_base, from->__iov[0].iov_len);
+			if (from->nr_segs > 1)
+				pr_err("DEBUG: Next iovec[1]: base=%px, len=%zu\n",
+				       from->__iov[1].iov_base, from->__iov[1].iov_len);
+		}
+	}
+
 	if (!skb_frags_readable(skb))
 		return -EFAULT;
 
@@ -633,16 +648,32 @@ int zerocopy_fill_skb_from_iter(struct sk_buff *skb,
 		size_t start;
 		ssize_t copied;
 
+		pr_err("DEBUG: zerocopy loop: length=%zu, iov_iter_count=%zu, frag=%d\n",
+		       length, iov_iter_count(from), frag);
+
 		if (frag == MAX_SKB_FRAGS)
 			return -EMSGSIZE;
 
 		copied = iov_iter_get_pages2(from, pages, length,
-					    MAX_SKB_FRAGS - frag, &start);
+					     MAX_SKB_FRAGS - frag, &start);
+
+		pr_err("DEBUG: iov_iter_get_pages2 returned copied=%zd, start=%zu\n",
+		       copied, start);
+		pr_err("DEBUG: iterator state after get_pages2: iov_iter_count=%zu\n",
+		       iov_iter_count(from));
+
 		if (copied < 0)
 			return -EFAULT;
 
+		if (copied == 0 && iov_iter_count(from) > 0)
+			pr_err("BUG: iov_iter_get_pages2 returned 0 but iterator claims %zu bytes remaining (requested %zu bytes)\n",
+			       iov_iter_count(from), length);
+
 		length -= copied;
 
+		pr_err("DEBUG: after processing: length=%zu, iov_iter_count=%zu, copied=%zd\n",
+		       length, iov_iter_count(from), copied);
+
 		skb->data_len += copied;
 		skb->len += copied;
 		skb->truesize += PAGE_ALIGN(copied + start);
@@ -686,6 +717,12 @@ int zerocopy_fill_skb_from_iter(struct sk_buff *skb,
 		if (refs)
 			page_ref_sub(last_head, refs);
 	}
+
+	pr_err("DEBUG: zerocopy_fill_skb_from_iter: loop exit - length=%zu, iov_iter_count=%zu\n",
+	       length, iov_iter_count(from));
+	pr_err("DEBUG: zerocopy_fill_skb_from_iter: final skb->len=%u, skb->data_len=%u\n",
+	       skb->len, skb->data_len);
+
 	return 0;
 }
 
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index fe92e5fa95b4..25300125b789 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -288,7 +288,14 @@ static struct sk_buff *virtio_transport_alloc_skb(struct virtio_vsock_pkt_info *
 	if (info->msg && payload_len > 0) {
 		int err;
 
+		pr_err("DEBUG: virtio_transport_alloc_skb: calling fill_skb with payload_len=%zu, zcopy=%d\n",
+		       payload_len, zcopy);
+
 		err = virtio_transport_fill_skb(skb, info, payload_len, zcopy);
+
+		pr_err("DEBUG: virtio_transport_fill_skb returned err=%d, skb->len=%u\n",
+		       err, skb->len);
+
 		if (err)
 			goto out;
 

Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in virtio_transport_send_pkt_info

DEBUG: zerocopy_fill_skb_from_iter: final skb->len=0, skb->data_len=0
DEBUG: virtio_transport_fill_skb returned err=0, skb->len=0
------------[ cut here ]------------
'send_pkt()' returns 0, but 65536 expected
WARNING: CPU: 0 PID: 5984 at net/vmw_vsock/virtio_transport_common.c:435 virtio_transport_send_pkt_info+0xd11/0xf00 net/vmw_vsock/virtio_transport_common.c:433
Modules linked in:
CPU: 0 UID: 0 PID: 5984 Comm: syz.0.17 Not tainted 6.17.0-rc1-syzkaller-g53e760d89498-dirty #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:virtio_transport_send_pkt_info+0xd11/0xf00 net/vmw_vsock/virtio_transport_common.c:433
Code: 0f 0b 90 bd f2 ff ff ff eb bc e8 0a bf 64 f6 c6 05 ba 87 32 04 01 90 48 c7 c7 80 d8 b8 8c 44 89 f6 4c 89 ea e8 c0 4d 28 f6 90 <0f> 0b 90 90 e9 e1 fe ff ff e8 e1 be 64 f6 90 0f 0b 90 e9 c5 f7 ff
RSP: 0018:ffffc900029cf530 EFLAGS: 00010246
RAX: 3eb3238673451c00 RBX: 0000000000010000 RCX: ffff888034db0000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000002
RBP: ffffffff8f879d50 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffffbfff1bfa1ec R12: dffffc0000000000
R13: 0000000000010000 R14: 0000000000000000 R15: ffff88804fdd20a4
FS:  00007f24a46d96c0(0000) GS:ffff88808d211000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000020000003f000 CR3: 0000000048de9000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 virtio_transport_stream_enqueue net/vmw_vsock/virtio_transport_common.c:1118 [inline]
 virtio_transport_seqpacket_enqueue+0x143/0x1c0 net/vmw_vsock/virtio_transport_common.c:846
 vsock_connectible_sendmsg+0xac7/0x1050 net/vmw_vsock/af_vsock.c:2140
 sock_sendmsg_nosec net/socket.c:714 [inline]
 __sock_sendmsg+0x21c/0x270 net/socket.c:729
 ____sys_sendmsg+0x52d/0x830 net/socket.c:2614
 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668
 __sys_sendmmsg+0x227/0x430 net/socket.c:2757
 __do_sys_sendmmsg net/socket.c:2784 [inline]
 __se_sys_sendmmsg net/socket.c:2781 [inline]
 __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2781
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f24a378ebe9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f24a46d9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
RAX: ffffffffffffffda RBX: 00007f24a39b5fa0 RCX: 00007f24a378ebe9
RDX: 0000000000000001 RSI: 0000200000000100 RDI: 0000000000000004
RBP: 00007f24a3811e19 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000024008094 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f24a39b6038 R14: 00007f24a39b5fa0 R15: 00007ffcbd16bc88
 </TASK>


Tested on:

commit:         53e760d8 Merge tag 'nfsd-6.17-1' of git://git.kernel.o..
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=17794af0580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=d67d3af29f50297e
dashboard link: https://syzkaller.appspot.com/bug?extid=b4d960daf7a3c7c2b7b1
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
patch:          https://syzkaller.appspot.com/x/patch.diff?x=12ad8c34580000

Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[Michael S. Tsirkin]

On Mon, Aug 11, 2025 at 11:59:30AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    37816488247d Merge tag 'net-6.17-rc1' of git://git.kernel...
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10b3b2f0580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=e143c1cd9dadd720
> dashboard link: https://syzkaller.appspot.com/bug?extid=b4d960daf7a3c7c2b7b1
> compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10f0f042580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14855434580000
> 
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-37816488.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/74b3ac8946d4/vmlinux-37816488.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/a2b391aacaec/bzImage-37816488.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+b4d960daf7a3c7c2b7b1@syzkaller.appspotmail.com
> 
> ------------[ cut here ]------------
> 'send_pkt()' returns 0, but 65536 expected
> WARNING: CPU: 0 PID: 5503 at net/vmw_vsock/virtio_transport_common.c:428 virtio_transport_send_pkt_info+0xd11/0xf00 net/vmw_vsock/virtio_transport_common.c:426
> Modules linked in:
> CPU: 0 UID: 0 PID: 5503 Comm: syz.0.17 Not tainted 6.16.0-syzkaller-12063-g37816488247d #0 PREEMPT(full) 
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
> RIP: 0010:virtio_transport_send_pkt_info+0xd11/0xf00 net/vmw_vsock/virtio_transport_common.c:426
> Code: 0f 0b 90 bd f2 ff ff ff eb bc e8 8a 20 65 f6 c6 05 94 cf 32 04 01 90 48 c7 c7 00 c3 b8 8c 44 89 f6 4c 89 ea e8 40 af 28 f6 90 <0f> 0b 90 90 e9 e1 fe ff ff e8 61 20 65 f6 90 0f 0b 90 e9 c5 f7 ff
> RSP: 0018:ffffc900027ff530 EFLAGS: 00010246
> RAX: d7fcdfc663889c00 RBX: 0000000000010000 RCX: ffff888000e1a440
> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000002
> RBP: ffffffff8f8764d0 R08: ffff88801fc24253 R09: 1ffff11003f8484a
> R10: dffffc0000000000 R11: ffffed1003f8484b R12: dffffc0000000000
> R13: 0000000000010000 R14: 0000000000000000 R15: ffff888058b48024
> FS:  000055556bda1500(0000) GS:ffff88808d218000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000020000003f000 CR3: 000000003f6db000 CR4: 0000000000352ef0
> Call Trace:
>  <TASK>
>  virtio_transport_stream_enqueue net/vmw_vsock/virtio_transport_common.c:1111 [inline]
>  virtio_transport_seqpacket_enqueue+0x143/0x1c0 net/vmw_vsock/virtio_transport_common.c:839
>  vsock_connectible_sendmsg+0xac7/0x1050 net/vmw_vsock/af_vsock.c:2140
>  sock_sendmsg_nosec net/socket.c:714 [inline]
>  __sock_sendmsg+0x21c/0x270 net/socket.c:729
>  ____sys_sendmsg+0x52d/0x830 net/socket.c:2614
>  ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668
>  __sys_sendmmsg+0x227/0x430 net/socket.c:2757
>  __do_sys_sendmmsg net/socket.c:2784 [inline]
>  __se_sys_sendmmsg net/socket.c:2781 [inline]
>  __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2781
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7fddc238ebe9
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007ffd48081028 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
> RAX: ffffffffffffffda RBX: 00007fddc25b5fa0 RCX: 00007fddc238ebe9
> RDX: 0000000000000001 RSI: 0000200000000100 RDI: 0000000000000004
> RBP: 00007fddc2411e19 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000024008094 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007fddc25b5fa0 R14: 00007fddc25b5fa0 R15: 0000000000000004
>  </TASK>
> 
> 
> ---
> 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 syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.

#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 8ca76151d2c8219edea82f1925a2a25907ff6a9d



> 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] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[Michael S. Tsirkin]

On Mon, Aug 11, 2025 at 11:59:30AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    37816488247d Merge tag 'net-6.17-rc1' of git://git.kernel...
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10b3b2f0580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=e143c1cd9dadd720
> dashboard link: https://syzkaller.appspot.com/bug?extid=b4d960daf7a3c7c2b7b1
> compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10f0f042580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14855434580000
> 
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-37816488.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/74b3ac8946d4/vmlinux-37816488.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/a2b391aacaec/bzImage-37816488.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+b4d960daf7a3c7c2b7b1@syzkaller.appspotmail.com
> 
> ------------[ cut here ]------------
> 'send_pkt()' returns 0, but 65536 expected
> WARNING: CPU: 0 PID: 5503 at net/vmw_vsock/virtio_transport_common.c:428 virtio_transport_send_pkt_info+0xd11/0xf00 net/vmw_vsock/virtio_transport_common.c:426
> Modules linked in:
> CPU: 0 UID: 0 PID: 5503 Comm: syz.0.17 Not tainted 6.16.0-syzkaller-12063-g37816488247d #0 PREEMPT(full) 
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
> RIP: 0010:virtio_transport_send_pkt_info+0xd11/0xf00 net/vmw_vsock/virtio_transport_common.c:426
> Code: 0f 0b 90 bd f2 ff ff ff eb bc e8 8a 20 65 f6 c6 05 94 cf 32 04 01 90 48 c7 c7 00 c3 b8 8c 44 89 f6 4c 89 ea e8 40 af 28 f6 90 <0f> 0b 90 90 e9 e1 fe ff ff e8 61 20 65 f6 90 0f 0b 90 e9 c5 f7 ff
> RSP: 0018:ffffc900027ff530 EFLAGS: 00010246
> RAX: d7fcdfc663889c00 RBX: 0000000000010000 RCX: ffff888000e1a440
> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000002
> RBP: ffffffff8f8764d0 R08: ffff88801fc24253 R09: 1ffff11003f8484a
> R10: dffffc0000000000 R11: ffffed1003f8484b R12: dffffc0000000000
> R13: 0000000000010000 R14: 0000000000000000 R15: ffff888058b48024
> FS:  000055556bda1500(0000) GS:ffff88808d218000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000020000003f000 CR3: 000000003f6db000 CR4: 0000000000352ef0
> Call Trace:
>  <TASK>
>  virtio_transport_stream_enqueue net/vmw_vsock/virtio_transport_common.c:1111 [inline]
>  virtio_transport_seqpacket_enqueue+0x143/0x1c0 net/vmw_vsock/virtio_transport_common.c:839
>  vsock_connectible_sendmsg+0xac7/0x1050 net/vmw_vsock/af_vsock.c:2140
>  sock_sendmsg_nosec net/socket.c:714 [inline]
>  __sock_sendmsg+0x21c/0x270 net/socket.c:729
>  ____sys_sendmsg+0x52d/0x830 net/socket.c:2614
>  ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668
>  __sys_sendmmsg+0x227/0x430 net/socket.c:2757
>  __do_sys_sendmmsg net/socket.c:2784 [inline]
>  __se_sys_sendmmsg net/socket.c:2781 [inline]
>  __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2781
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7fddc238ebe9
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007ffd48081028 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
> RAX: ffffffffffffffda RBX: 00007fddc25b5fa0 RCX: 00007fddc238ebe9
> RDX: 0000000000000001 RSI: 0000200000000100 RDI: 0000000000000004
> RBP: 00007fddc2411e19 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000024008094 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007fddc25b5fa0 R14: 00007fddc25b5fa0 R15: 0000000000000004
>  </TASK>
> 
> 
> ---
> 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 syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.


#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 6693731487a8145a9b039bc983d77edc47693855


> 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] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[syzbot]

Hello,

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

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

Tested on:

commit:         8ca76151 vsock/virtio: Rename virtio_vsock_skb_rx_put()
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=15d54af0580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=84141250092a114f
dashboard link: https://syzkaller.appspot.com/bug?extid=b4d960daf7a3c7c2b7b1
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7

Note: no patches were applied.
Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in virtio_transport_send_pkt_info

------------[ cut here ]------------
'send_pkt()' returns 0, but 65536 expected
WARNING: CPU: 0 PID: 5936 at net/vmw_vsock/virtio_transport_common.c:428 virtio_transport_send_pkt_info+0xd11/0xf00 net/vmw_vsock/virtio_transport_common.c:426
Modules linked in:
CPU: 0 UID: 0 PID: 5936 Comm: syz.0.17 Not tainted 6.16.0-rc6-syzkaller-00030-g6693731487a8 #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:virtio_transport_send_pkt_info+0xd11/0xf00 net/vmw_vsock/virtio_transport_common.c:426
Code: 0f 0b 90 bd f2 ff ff ff eb bc e8 2a 15 74 f6 c6 05 17 6f 40 04 01 90 48 c7 c7 00 4b b7 8c 44 89 f6 4c 89 ea e8 e0 f7 37 f6 90 <0f> 0b 90 90 e9 e1 fe ff ff e8 01 15 74 f6 90 0f 0b 90 e9 c5 f7 ff
RSP: 0018:ffffc9000cc2f530 EFLAGS: 00010246
RAX: 72837a5a4342cf00 RBX: 0000000000010000 RCX: ffff888033218000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000002
RBP: ffffffff8f8592b0 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffffbfff1bfa6ec R12: dffffc0000000000
R13: 0000000000010000 R14: 0000000000000000 R15: ffff8880406730e4
FS:  00007fc0bd7eb6c0(0000) GS:ffff88808d230000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd5857ec368 CR3: 00000000517cf000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 virtio_transport_stream_enqueue net/vmw_vsock/virtio_transport_common.c:1111 [inline]
 virtio_transport_seqpacket_enqueue+0x143/0x1c0 net/vmw_vsock/virtio_transport_common.c:839
 vsock_connectible_sendmsg+0xac4/0x1050 net/vmw_vsock/af_vsock.c:2123
 sock_sendmsg_nosec net/socket.c:712 [inline]
 __sock_sendmsg+0x219/0x270 net/socket.c:727
 ____sys_sendmsg+0x52d/0x830 net/socket.c:2566
 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620
 __sys_sendmmsg+0x227/0x430 net/socket.c:2709
 __do_sys_sendmmsg net/socket.c:2736 [inline]
 __se_sys_sendmmsg net/socket.c:2733 [inline]
 __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fc0bc98ebe9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fc0bd7eb038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
RAX: ffffffffffffffda RBX: 00007fc0bcbb5fa0 RCX: 00007fc0bc98ebe9
RDX: 0000000000000001 RSI: 0000200000000100 RDI: 0000000000000004
RBP: 00007fc0bca11e19 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000024008094 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fc0bcbb6038 R14: 00007fc0bcbb5fa0 R15: 00007ffdb7bf09f8
 </TASK>


Tested on:

commit:         66937314 vsock/virtio: Allocate nonlinear SKBs for han..
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=159d75bc580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=84141250092a114f
dashboard link: https://syzkaller.appspot.com/bug?extid=b4d960daf7a3c7c2b7b1
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7

Note: no patches were applied.

Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[Michael S. Tsirkin]

On Tue, Aug 12, 2025 at 03:03:02AM -0700, syzbot wrote:
> Hello,
> 
> syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> WARNING in virtio_transport_send_pkt_info

OK so the issue triggers on
commit 6693731487a8145a9b039bc983d77edc47693855
Author: Will Deacon <will@kernel.org>
Date:   Thu Jul 17 10:01:16 2025 +0100

    vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers
    

but does not trigger on:

commit 8ca76151d2c8219edea82f1925a2a25907ff6a9d
Author: Will Deacon <will@kernel.org>
Date:   Thu Jul 17 10:01:15 2025 +0100

    vsock/virtio: Rename virtio_vsock_skb_rx_put()
    


Will, I suspect your patch merely uncovers a latent bug
in zero copy handling elsewhere.
Want to take a look?



> ------------[ cut here ]------------
> 'send_pkt()' returns 0, but 65536 expected
> WARNING: CPU: 0 PID: 5936 at net/vmw_vsock/virtio_transport_common.c:428 virtio_transport_send_pkt_info+0xd11/0xf00 net/vmw_vsock/virtio_transport_common.c:426
> Modules linked in:
> CPU: 0 UID: 0 PID: 5936 Comm: syz.0.17 Not tainted 6.16.0-rc6-syzkaller-00030-g6693731487a8 #0 PREEMPT(full) 
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
> RIP: 0010:virtio_transport_send_pkt_info+0xd11/0xf00 net/vmw_vsock/virtio_transport_common.c:426
> Code: 0f 0b 90 bd f2 ff ff ff eb bc e8 2a 15 74 f6 c6 05 17 6f 40 04 01 90 48 c7 c7 00 4b b7 8c 44 89 f6 4c 89 ea e8 e0 f7 37 f6 90 <0f> 0b 90 90 e9 e1 fe ff ff e8 01 15 74 f6 90 0f 0b 90 e9 c5 f7 ff
> RSP: 0018:ffffc9000cc2f530 EFLAGS: 00010246
> RAX: 72837a5a4342cf00 RBX: 0000000000010000 RCX: ffff888033218000
> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000002
> RBP: ffffffff8f8592b0 R08: 0000000000000003 R09: 0000000000000004
> R10: dffffc0000000000 R11: fffffbfff1bfa6ec R12: dffffc0000000000
> R13: 0000000000010000 R14: 0000000000000000 R15: ffff8880406730e4
> FS:  00007fc0bd7eb6c0(0000) GS:ffff88808d230000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fd5857ec368 CR3: 00000000517cf000 CR4: 0000000000352ef0
> Call Trace:
>  <TASK>
>  virtio_transport_stream_enqueue net/vmw_vsock/virtio_transport_common.c:1111 [inline]
>  virtio_transport_seqpacket_enqueue+0x143/0x1c0 net/vmw_vsock/virtio_transport_common.c:839
>  vsock_connectible_sendmsg+0xac4/0x1050 net/vmw_vsock/af_vsock.c:2123
>  sock_sendmsg_nosec net/socket.c:712 [inline]
>  __sock_sendmsg+0x219/0x270 net/socket.c:727
>  ____sys_sendmsg+0x52d/0x830 net/socket.c:2566
>  ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620
>  __sys_sendmmsg+0x227/0x430 net/socket.c:2709
>  __do_sys_sendmmsg net/socket.c:2736 [inline]
>  __se_sys_sendmmsg net/socket.c:2733 [inline]
>  __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7fc0bc98ebe9
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007fc0bd7eb038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
> RAX: ffffffffffffffda RBX: 00007fc0bcbb5fa0 RCX: 00007fc0bc98ebe9
> RDX: 0000000000000001 RSI: 0000200000000100 RDI: 0000000000000004
> RBP: 00007fc0bca11e19 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000024008094 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007fc0bcbb6038 R14: 00007fc0bcbb5fa0 R15: 00007ffdb7bf09f8
>  </TASK>
> 
> 
> Tested on:
> 
> commit:         66937314 vsock/virtio: Allocate nonlinear SKBs for han..
> git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> console output: https://syzkaller.appspot.com/x/log.txt?x=159d75bc580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=84141250092a114f
> dashboard link: https://syzkaller.appspot.com/bug?extid=b4d960daf7a3c7c2b7b1
> compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
> 
> Note: no patches were applied.

Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[Hillf Danton]

> Date: Mon, 11 Aug 2025 11:59:30 -0700	[thread overview]
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    37816488247d Merge tag 'net-6.17-rc1' of git://git.kernel...
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10b3b2f0580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=e143c1cd9dadd720
> dashboard link: https://syzkaller.appspot.com/bug?extid=b4d960daf7a3c7c2b7b1
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10f0f042580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14855434580000

#syz test

--- x/net/vmw_vsock/virtio_transport_common.c
+++ y/net/vmw_vsock/virtio_transport_common.c
@@ -258,9 +258,7 @@ static struct sk_buff *virtio_transport_
 	size_t skb_len;
 
 	skb_len = VIRTIO_VSOCK_SKB_HEADROOM;
-
-	if (!zcopy)
-		skb_len += payload_len;
+	skb_len += payload_len;
 
 	skb = virtio_vsock_alloc_skb(skb_len, GFP_KERNEL);
 	if (!skb)
--

Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[syzbot]

Hello,

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

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

Tested on:

commit:         8742b2d8 Merge tag 'pull-fixes' of git://git.kernel.or..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=136725a2580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=d67d3af29f50297e
dashboard link: https://syzkaller.appspot.com/bug?extid=b4d960daf7a3c7c2b7b1
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
patch:          https://syzkaller.appspot.com/x/patch.diff?x=12c575a2580000

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

Forwarded: Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[syzbot]

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

***

Subject: Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info
Author: mst@redhat.com


#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


diff --git a/net/core/datagram.c b/net/core/datagram.c
index 94cc4705e91d..ab890448f3a2 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -642,6 +642,7 @@ int zerocopy_fill_skb_from_iter(struct sk_buff *skb,
 			return -EFAULT;
 
 		length -= copied;
+		iov_iter_advance(from, copied);
 
 		skb->data_len += copied;
 		skb->len += copied;

Forwarded: Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[syzbot]

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

***

Subject: Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info
Author: mst@redhat.com


#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


diff --git a/net/core/datagram.c b/net/core/datagram.c
index 94cc4705e91d..3b5695ad3714 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -686,6 +686,11 @@ int zerocopy_fill_skb_from_iter(struct sk_buff *skb,
 		if (refs)
 			page_ref_sub(last_head, refs);
 	}
+
+	/* Fail if we couldn't get all requested data, like linear copy does */
+	if (length > 0)
+		return -EFAULT;
+
 	return 0;
 }
 

Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[Will Deacon]

On Tue, Aug 12, 2025 at 06:15:46AM -0400, Michael S. Tsirkin wrote:
> On Tue, Aug 12, 2025 at 03:03:02AM -0700, syzbot wrote:
> > Hello,
> > 
> > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > WARNING in virtio_transport_send_pkt_info
> 
> OK so the issue triggers on
> commit 6693731487a8145a9b039bc983d77edc47693855
> Author: Will Deacon <will@kernel.org>
> Date:   Thu Jul 17 10:01:16 2025 +0100
> 
>     vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers
>     
> 
> but does not trigger on:
> 
> commit 8ca76151d2c8219edea82f1925a2a25907ff6a9d
> Author: Will Deacon <will@kernel.org>
> Date:   Thu Jul 17 10:01:15 2025 +0100
> 
>     vsock/virtio: Rename virtio_vsock_skb_rx_put()
>     
> 
> 
> Will, I suspect your patch merely uncovers a latent bug
> in zero copy handling elsewhere.
> Want to take a look?

Sorry for the delay, I was debugging something else!

I see Hillf already tried some stuff in the other thread, but I can take
a look as well.

Will

Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[Michael S. Tsirkin]

On Fri, Aug 15, 2025 at 11:09:24AM +0100, Will Deacon wrote:
> On Tue, Aug 12, 2025 at 06:15:46AM -0400, Michael S. Tsirkin wrote:
> > On Tue, Aug 12, 2025 at 03:03:02AM -0700, syzbot wrote:
> > > Hello,
> > > 
> > > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > > WARNING in virtio_transport_send_pkt_info
> > 
> > OK so the issue triggers on
> > commit 6693731487a8145a9b039bc983d77edc47693855
> > Author: Will Deacon <will@kernel.org>
> > Date:   Thu Jul 17 10:01:16 2025 +0100
> > 
> >     vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers
> >     
> > 
> > but does not trigger on:
> > 
> > commit 8ca76151d2c8219edea82f1925a2a25907ff6a9d
> > Author: Will Deacon <will@kernel.org>
> > Date:   Thu Jul 17 10:01:15 2025 +0100
> > 
> >     vsock/virtio: Rename virtio_vsock_skb_rx_put()
> >     
> > 
> > 
> > Will, I suspect your patch merely uncovers a latent bug
> > in zero copy handling elsewhere.
> > Want to take a look?
> 
> Sorry for the delay, I was debugging something else!
> 
> I see Hillf already tried some stuff in the other thread, but I can take
> a look as well.
> 
> Will

I will be frank I don't understand how that patch makes sense though.

-- 
MST

Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[Will Deacon]

On Fri, Aug 15, 2025 at 06:44:47AM -0400, Michael S. Tsirkin wrote:
> On Fri, Aug 15, 2025 at 11:09:24AM +0100, Will Deacon wrote:
> > On Tue, Aug 12, 2025 at 06:15:46AM -0400, Michael S. Tsirkin wrote:
> > > On Tue, Aug 12, 2025 at 03:03:02AM -0700, syzbot wrote:
> > > > Hello,
> > > > 
> > > > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > > > WARNING in virtio_transport_send_pkt_info
> > > 
> > > OK so the issue triggers on
> > > commit 6693731487a8145a9b039bc983d77edc47693855
> > > Author: Will Deacon <will@kernel.org>
> > > Date:   Thu Jul 17 10:01:16 2025 +0100
> > > 
> > >     vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers
> > >     
> > > 
> > > but does not trigger on:
> > > 
> > > commit 8ca76151d2c8219edea82f1925a2a25907ff6a9d
> > > Author: Will Deacon <will@kernel.org>
> > > Date:   Thu Jul 17 10:01:15 2025 +0100
> > > 
> > >     vsock/virtio: Rename virtio_vsock_skb_rx_put()
> > >     
> > > 
> > > 
> > > Will, I suspect your patch merely uncovers a latent bug
> > > in zero copy handling elsewhere.

I'm still looking at this, but I'm not sure zero-copy is the right place
to focus on.

The bisected patch 6693731487a8 ("vsock/virtio: Allocate nonlinear SKBs
for handling large transmit buffers") only has two hunks. The first is
for the non-zcopy case and the latter is a no-op for zcopy, as
skb_len == VIRTIO_VSOCK_SKB_HEADROOM and so we end up with a linear SKB
regardless.

I'll keep digging...

Will

Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[Will Deacon]

On Fri, Aug 15, 2025 at 01:00:59PM +0100, Will Deacon wrote:
> On Fri, Aug 15, 2025 at 06:44:47AM -0400, Michael S. Tsirkin wrote:
> > On Fri, Aug 15, 2025 at 11:09:24AM +0100, Will Deacon wrote:
> > > On Tue, Aug 12, 2025 at 06:15:46AM -0400, Michael S. Tsirkin wrote:
> > > > On Tue, Aug 12, 2025 at 03:03:02AM -0700, syzbot wrote:
> > > > > Hello,
> > > > > 
> > > > > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > > > > WARNING in virtio_transport_send_pkt_info
> > > > 
> > > > OK so the issue triggers on
> > > > commit 6693731487a8145a9b039bc983d77edc47693855
> > > > Author: Will Deacon <will@kernel.org>
> > > > Date:   Thu Jul 17 10:01:16 2025 +0100
> > > > 
> > > >     vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers
> > > >     
> > > > 
> > > > but does not trigger on:
> > > > 
> > > > commit 8ca76151d2c8219edea82f1925a2a25907ff6a9d
> > > > Author: Will Deacon <will@kernel.org>
> > > > Date:   Thu Jul 17 10:01:15 2025 +0100
> > > > 
> > > >     vsock/virtio: Rename virtio_vsock_skb_rx_put()
> > > >     
> > > > 
> > > > 
> > > > Will, I suspect your patch merely uncovers a latent bug
> > > > in zero copy handling elsewhere.
> 
> I'm still looking at this, but I'm not sure zero-copy is the right place
> to focus on.
> 
> The bisected patch 6693731487a8 ("vsock/virtio: Allocate nonlinear SKBs
> for handling large transmit buffers") only has two hunks. The first is
> for the non-zcopy case and the latter is a no-op for zcopy, as
> skb_len == VIRTIO_VSOCK_SKB_HEADROOM and so we end up with a linear SKB
> regardless.

It's looking like this is caused by moving from memcpy_from_msg() to
skb_copy_datagram_from_iter(), which is necessary to handle non-linear
SKBs correctly.

In the case of failure (i.e. faulting on the source and returning
-EFAULT), memcpy_from_msg() rewinds the message iterator whereas
skb_copy_datagram_from_iter() does not. If we have previously managed to
transmit some of the packet, then I think
virtio_transport_send_pkt_info() can end up returning a positive "bytes
written" error code and the caller will call it again. If we've advanced
the message iterator, then this can end up with the reported warning if
we run out of input data.

As a hack (see below), I tried rewinding the iterator in the error path
of skb_copy_datagram_from_iter() but I'm not sure whether other callers
would be happy with that. If not, then we could save/restore the
iterator state in virtio_transport_fill_skb() if the copy fails. Or we
could add a variant of skb_copy_datagram_from_iter(), say
skb_copy_datagram_from_iter_full(), which has the rewind behaviour.

What do you think?

Will

--->8

diff --git a/net/core/datagram.c b/net/core/datagram.c
index 94cc4705e91d..62e44ab136b7 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -551,7 +551,7 @@ int skb_copy_datagram_from_iter(struct sk_buff *skb, int offset,
 				 int len)
 {
 	int start = skb_headlen(skb);
-	int i, copy = start - offset;
+	int i, copy = start - offset, start_off = offset;
 	struct sk_buff *frag_iter;
 
 	/* Copy header. */
@@ -614,6 +614,7 @@ int skb_copy_datagram_from_iter(struct sk_buff *skb, int offset,
 		return 0;
 
 fault:
+	iov_iter_revert(from, offset - start_off);
 	return -EFAULT;
 }
 EXPORT_SYMBOL(skb_copy_datagram_from_iter);

Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[Hillf Danton]

On Fri, 15 Aug 2025 16:48:00 +0100 Will Deacon wrote:
>On Fri, Aug 15, 2025 at 01:00:59PM +0100, Will Deacon wrote:
>> On Fri, Aug 15, 2025 at 06:44:47AM -0400, Michael S. Tsirkin wrote:
>> > On Fri, Aug 15, 2025 at 11:09:24AM +0100, Will Deacon wrote:
>> > > On Tue, Aug 12, 2025 at 06:15:46AM -0400, Michael S. Tsirkin wrote:
>> > > > On Tue, Aug 12, 2025 at 03:03:02AM -0700, syzbot wrote:
>> > > > > Hello,
>> > > > > 
>> > > > > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
>> > > > > WARNING in virtio_transport_send_pkt_info
>> > > > 
>> > > > OK so the issue triggers on
>> > > > commit 6693731487a8145a9b039bc983d77edc47693855
>> > > > Author: Will Deacon <will@kernel.org>
>> > > > Date:   Thu Jul 17 10:01:16 2025 +0100
>> > > > 
>> > > >     vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers
>> > > >     
>> > > > 
>> > > > but does not trigger on:
>> > > > 
>> > > > commit 8ca76151d2c8219edea82f1925a2a25907ff6a9d
>> > > > Author: Will Deacon <will@kernel.org>
>> > > > Date:   Thu Jul 17 10:01:15 2025 +0100
>> > > > 
>> > > >     vsock/virtio: Rename virtio_vsock_skb_rx_put()
>> > > >     
>> > > > 
>> > > > 
>> > > > Will, I suspect your patch merely uncovers a latent bug
>> > > > in zero copy handling elsewhere.
>> 
>> I'm still looking at this, but I'm not sure zero-copy is the right place
>> to focus on.
>> 
>> The bisected patch 6693731487a8 ("vsock/virtio: Allocate nonlinear SKBs
>> for handling large transmit buffers") only has two hunks. The first is
>> for the non-zcopy case and the latter is a no-op for zcopy, as
>> skb_len == VIRTIO_VSOCK_SKB_HEADROOM and so we end up with a linear SKB
>> regardless.
>
>It's looking like this is caused by moving from memcpy_from_msg() to
>skb_copy_datagram_from_iter(), which is necessary to handle non-linear
>SKBs correctly.
>
>In the case of failure (i.e. faulting on the source and returning
>-EFAULT), memcpy_from_msg() rewinds the message iterator whereas
>skb_copy_datagram_from_iter() does not. If we have previously managed to
>transmit some of the packet, then I think
>virtio_transport_send_pkt_info() can end up returning a positive "bytes
>written" error code and the caller will call it again. If we've advanced
>the message iterator, then this can end up with the reported warning if
>we run out of input data.
>
>As a hack (see below), I tried rewinding the iterator in the error path
>of skb_copy_datagram_from_iter() but I'm not sure whether other callers
>would be happy with that. If not, then we could save/restore the
>iterator state in virtio_transport_fill_skb() if the copy fails. Or we
>could add a variant of skb_copy_datagram_from_iter(), say
>skb_copy_datagram_from_iter_full(), which has the rewind behaviour.
>
>What do you think?
>
>Will
>
>--->8

#syz test

diff --git a/net/core/datagram.c b/net/core/datagram.c
index 94cc4705e91d..62e44ab136b7 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -551,7 +551,7 @@ int skb_copy_datagram_from_iter(struct sk_buff *skb, int offset,
 				 int len)
 {
 	int start = skb_headlen(skb);
-	int i, copy = start - offset;
+	int i, copy = start - offset, start_off = offset;
 	struct sk_buff *frag_iter;
 
 	/* Copy header. */
@@ -614,6 +614,7 @@ int skb_copy_datagram_from_iter(struct sk_buff *skb, int offset,
 		return 0;
 
 fault:
+	iov_iter_revert(from, offset - start_off);
 	return -EFAULT;
 }
 EXPORT_SYMBOL(skb_copy_datagram_from_iter);
--

Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[syzbot]

Hello,

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

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

Tested on:

commit:         dfd4b508 Merge tag 'drm-fixes-2025-08-16' of https://g..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=130453a2580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=3f81850843b877ed
dashboard link: https://syzkaller.appspot.com/bug?extid=b4d960daf7a3c7c2b7b1
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
patch:          https://syzkaller.appspot.com/x/patch.diff?x=125373a2580000

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

Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[Michael S. Tsirkin]

On Fri, Aug 15, 2025 at 04:48:00PM +0100, Will Deacon wrote:
> On Fri, Aug 15, 2025 at 01:00:59PM +0100, Will Deacon wrote:
> > On Fri, Aug 15, 2025 at 06:44:47AM -0400, Michael S. Tsirkin wrote:
> > > On Fri, Aug 15, 2025 at 11:09:24AM +0100, Will Deacon wrote:
> > > > On Tue, Aug 12, 2025 at 06:15:46AM -0400, Michael S. Tsirkin wrote:
> > > > > On Tue, Aug 12, 2025 at 03:03:02AM -0700, syzbot wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > > > > > WARNING in virtio_transport_send_pkt_info
> > > > > 
> > > > > OK so the issue triggers on
> > > > > commit 6693731487a8145a9b039bc983d77edc47693855
> > > > > Author: Will Deacon <will@kernel.org>
> > > > > Date:   Thu Jul 17 10:01:16 2025 +0100
> > > > > 
> > > > >     vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers
> > > > >     
> > > > > 
> > > > > but does not trigger on:
> > > > > 
> > > > > commit 8ca76151d2c8219edea82f1925a2a25907ff6a9d
> > > > > Author: Will Deacon <will@kernel.org>
> > > > > Date:   Thu Jul 17 10:01:15 2025 +0100
> > > > > 
> > > > >     vsock/virtio: Rename virtio_vsock_skb_rx_put()
> > > > >     
> > > > > 
> > > > > 
> > > > > Will, I suspect your patch merely uncovers a latent bug
> > > > > in zero copy handling elsewhere.
> > 
> > I'm still looking at this, but I'm not sure zero-copy is the right place
> > to focus on.
> > 
> > The bisected patch 6693731487a8 ("vsock/virtio: Allocate nonlinear SKBs
> > for handling large transmit buffers") only has two hunks. The first is
> > for the non-zcopy case and the latter is a no-op for zcopy, as
> > skb_len == VIRTIO_VSOCK_SKB_HEADROOM and so we end up with a linear SKB
> > regardless.
> 
> It's looking like this is caused by moving from memcpy_from_msg() to
> skb_copy_datagram_from_iter(), which is necessary to handle non-linear
> SKBs correctly.
> 
> In the case of failure (i.e. faulting on the source and returning
> -EFAULT), memcpy_from_msg() rewinds the message iterator whereas
> skb_copy_datagram_from_iter() does not. If we have previously managed to
> transmit some of the packet, then I think
> virtio_transport_send_pkt_info() can end up returning a positive "bytes
> written" error code and the caller will call it again. If we've advanced
> the message iterator, then this can end up with the reported warning if
> we run out of input data.
> 
> As a hack (see below), I tried rewinding the iterator in the error path
> of skb_copy_datagram_from_iter() but I'm not sure whether other callers
> would be happy with that. If not, then we could save/restore the
> iterator state in virtio_transport_fill_skb() if the copy fails. Or we
> could add a variant of skb_copy_datagram_from_iter(), say
> skb_copy_datagram_from_iter_full(), which has the rewind behaviour.
> 
> What do you think?
> 
> Will

It is, at least, self-contained. I don't much like hacking around
it in virtio_transport_fill_skb. If your patch isn't acceptable,
skb_copy_datagram_from_iter_full seem like a better approach, I think.


> --->8
> 
> diff --git a/net/core/datagram.c b/net/core/datagram.c
> index 94cc4705e91d..62e44ab136b7 100644
> --- a/net/core/datagram.c
> +++ b/net/core/datagram.c
> @@ -551,7 +551,7 @@ int skb_copy_datagram_from_iter(struct sk_buff *skb, int offset,
>  				 int len)
>  {
>  	int start = skb_headlen(skb);
> -	int i, copy = start - offset;
> +	int i, copy = start - offset, start_off = offset;
>  	struct sk_buff *frag_iter;
>  
>  	/* Copy header. */
> @@ -614,6 +614,7 @@ int skb_copy_datagram_from_iter(struct sk_buff *skb, int offset,
>  		return 0;
>  
>  fault:
> +	iov_iter_revert(from, offset - start_off);
>  	return -EFAULT;
>  }
>  EXPORT_SYMBOL(skb_copy_datagram_from_iter);

Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info

[Will Deacon]

On Sat, Aug 16, 2025 at 06:34:29AM -0400, Michael S. Tsirkin wrote:
> On Fri, Aug 15, 2025 at 04:48:00PM +0100, Will Deacon wrote:
> > On Fri, Aug 15, 2025 at 01:00:59PM +0100, Will Deacon wrote:
> > > On Fri, Aug 15, 2025 at 06:44:47AM -0400, Michael S. Tsirkin wrote:
> > > > On Fri, Aug 15, 2025 at 11:09:24AM +0100, Will Deacon wrote:
> > > > > On Tue, Aug 12, 2025 at 06:15:46AM -0400, Michael S. Tsirkin wrote:
> > > > > > On Tue, Aug 12, 2025 at 03:03:02AM -0700, syzbot wrote:
> > > > > > > Hello,
> > > > > > > 
> > > > > > > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > > > > > > WARNING in virtio_transport_send_pkt_info
> > > > > > 
> > > > > > OK so the issue triggers on
> > > > > > commit 6693731487a8145a9b039bc983d77edc47693855
> > > > > > Author: Will Deacon <will@kernel.org>
> > > > > > Date:   Thu Jul 17 10:01:16 2025 +0100
> > > > > > 
> > > > > >     vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers
> > > > > >     
> > > > > > 
> > > > > > but does not trigger on:
> > > > > > 
> > > > > > commit 8ca76151d2c8219edea82f1925a2a25907ff6a9d
> > > > > > Author: Will Deacon <will@kernel.org>
> > > > > > Date:   Thu Jul 17 10:01:15 2025 +0100
> > > > > > 
> > > > > >     vsock/virtio: Rename virtio_vsock_skb_rx_put()
> > > > > >     
> > > > > > 
> > > > > > 
> > > > > > Will, I suspect your patch merely uncovers a latent bug
> > > > > > in zero copy handling elsewhere.
> > > 
> > > I'm still looking at this, but I'm not sure zero-copy is the right place
> > > to focus on.
> > > 
> > > The bisected patch 6693731487a8 ("vsock/virtio: Allocate nonlinear SKBs
> > > for handling large transmit buffers") only has two hunks. The first is
> > > for the non-zcopy case and the latter is a no-op for zcopy, as
> > > skb_len == VIRTIO_VSOCK_SKB_HEADROOM and so we end up with a linear SKB
> > > regardless.
> > 
> > It's looking like this is caused by moving from memcpy_from_msg() to
> > skb_copy_datagram_from_iter(), which is necessary to handle non-linear
> > SKBs correctly.
> > 
> > In the case of failure (i.e. faulting on the source and returning
> > -EFAULT), memcpy_from_msg() rewinds the message iterator whereas
> > skb_copy_datagram_from_iter() does not. If we have previously managed to
> > transmit some of the packet, then I think
> > virtio_transport_send_pkt_info() can end up returning a positive "bytes
> > written" error code and the caller will call it again. If we've advanced
> > the message iterator, then this can end up with the reported warning if
> > we run out of input data.
> > 
> > As a hack (see below), I tried rewinding the iterator in the error path
> > of skb_copy_datagram_from_iter() but I'm not sure whether other callers
> > would be happy with that. If not, then we could save/restore the
> > iterator state in virtio_transport_fill_skb() if the copy fails. Or we
> > could add a variant of skb_copy_datagram_from_iter(), say
> > skb_copy_datagram_from_iter_full(), which has the rewind behaviour.
> > 
> > What do you think?
> > 
> > Will
> 
> It is, at least, self-contained. I don't much like hacking around
> it in virtio_transport_fill_skb. If your patch isn't acceptable,
> skb_copy_datagram_from_iter_full seem like a better approach, I think.

Thanks. I'll send something out shortly with you on cc.

Will