Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info
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
> > > > > > 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
> > > > > > 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
Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info
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
> > > > > 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
> > > > > 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
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
> > > > 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
> > > > 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
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
> > > 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
> > > 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
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 > > 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 > > 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
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 > 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 > 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
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 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 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:c9000cc2f530 EFLAGS: 00010246 > RAX: 72837a5a4342cf00 RBX: 0001 RCX: 888033218000 > RDX: RSI: 0001 RDI: 0002 > RBP: 8f8592b0 R08: 0003 R09: 0004 > R10: dc00 R11: fbfff1bfa6ec R12: dc00 > R13: 0001 R14: R15: 8880406730e4 > FS: 7fc0bd7eb6c0() GS:88808d23() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7fd5857ec368 CR3: 517cf000 CR4: 00352ef0 > Call Trace: > > virtio_transport_stream_enqueue net/vmw_vsock/virtio_transport_common.c: > [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:7fc0bd7eb038 EFLAGS: 0246 ORIG_RAX: 0133 > RAX: ffda RBX: 7fc0bcbb5fa0 RCX: 7fc0bc98ebe9 > RDX: 0001 RSI: 2100 RDI: 0004 > RBP: 7fc0bca11e19 R08: R09: > R10: 24008094 R11: 0246 R12: > R13: 7fc0bcbb6038 R14: 7fc0bcbb5fa0 R15: 7ffdb7bf09f8 > > > > 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=159d75bc58 > 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
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:c9000cc2f530 EFLAGS: 00010246 RAX: 72837a5a4342cf00 RBX: 0001 RCX: 888033218000 RDX: RSI: 0001 RDI: 0002 RBP: 8f8592b0 R08: 0003 R09: 0004 R10: dc00 R11: fbfff1bfa6ec R12: dc00 R13: 0001 R14: R15: 8880406730e4 FS: 7fc0bd7eb6c0() GS:88808d23() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fd5857ec368 CR3: 517cf000 CR4: 00352ef0 Call Trace: virtio_transport_stream_enqueue net/vmw_vsock/virtio_transport_common.c: [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:7fc0bd7eb038 EFLAGS: 0246 ORIG_RAX: 0133 RAX: ffda RBX: 7fc0bcbb5fa0 RCX: 7fc0bc98ebe9 RDX: 0001 RSI: 2100 RDI: 0004 RBP: 7fc0bca11e19 R08: R09: R10: 24008094 R11: 0246 R12: R13: 7fc0bcbb6038 R14: 7fc0bcbb5fa0 R15: 7ffdb7bf09f8 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=159d75bc58 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
Hello, syzbot has tested the proposed patch and the reproducer did not trigger any issue: Reported-by: [email protected] Tested-by: [email protected] 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=15d54af058 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
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=10b3b2f058 > 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=10f0f04258 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1485543458 > > 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: [email protected] > > [ 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:c900027ff530 EFLAGS: 00010246 > RAX: d7fcdfc663889c00 RBX: 0001 RCX: 888000e1a440 > RDX: RSI: 0001 RDI: 0002 > RBP: 8f8764d0 R08: 88801fc24253 R09: 111003f8484a > R10: dc00 R11: ed1003f8484b R12: dc00 > R13: 0001 R14: R15: 888058b48024 > FS: 6bda1500() GS:88808d218000() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 2003f000 CR3: 3f6db000 CR4: 00352ef0 > Call Trace: > > virtio_transport_stream_enqueue net/vmw_vsock/virtio_transport_common.c: > [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:7ffd48081028 EFLAGS: 0246 ORIG_RAX: 0133 > RAX: ffda RBX: 7fddc25b5fa0 RCX: 7fddc238ebe9 > RDX: 0001 RSI: 2100 RDI: 0004 > RBP: 7fddc2411e19 R08: R09: > R10: 24008094 R11: 0246 R12: > R13: 7fddc25b5fa0 R14: 7fddc25b5fa0 R15: 0004 > > > > --- > 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 [email protected]. > > 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 dupli
Re: [syzbot] [kvm?] [net?] [virt?] WARNING in virtio_transport_send_pkt_info
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=10b3b2f058 > 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=10f0f04258 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1485543458 > > 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: [email protected] > > [ 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:c900027ff530 EFLAGS: 00010246 > RAX: d7fcdfc663889c00 RBX: 0001 RCX: 888000e1a440 > RDX: RSI: 0001 RDI: 0002 > RBP: 8f8764d0 R08: 88801fc24253 R09: 111003f8484a > R10: dc00 R11: ed1003f8484b R12: dc00 > R13: 0001 R14: R15: 888058b48024 > FS: 6bda1500() GS:88808d218000() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 2003f000 CR3: 3f6db000 CR4: 00352ef0 > Call Trace: > > virtio_transport_stream_enqueue net/vmw_vsock/virtio_transport_common.c: > [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:7ffd48081028 EFLAGS: 0246 ORIG_RAX: 0133 > RAX: ffda RBX: 7fddc25b5fa0 RCX: 7fddc238ebe9 > RDX: 0001 RSI: 2100 RDI: 0004 > RBP: 7fddc2411e19 R08: R09: > R10: 24008094 R11: 0246 R12: > R13: 7fddc25b5fa0 R14: 7fddc25b5fa0 R15: 0004 > > > > --- > 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 [email protected]. > > 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 dupli
