lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <tencent_387517772566B03DBD365896C036264AA809@qq.com>
Date: Fri, 28 Nov 2025 16:41:38 +0800
From: Edward Adam Davis <eadavis@...com>
To: syzbot+28e5f3d207b14bae122a@...kaller.appspotmail.com
Cc: davem@...emloft.net,
	edumazet@...gle.com,
	eperezma@...hat.com,
	horms@...nel.org,
	jasowang@...hat.com,
	kuba@...nel.org,
	kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	mst@...hat.com,
	netdev@...r.kernel.org,
	pabeni@...hat.com,
	sgarzare@...hat.com,
	stefanha@...hat.com,
	syzkaller-bugs@...glegroups.com,
	virtualization@...ts.linux.dev,
	xuanzhuo@...ux.alibaba.com
Subject: [PATCH Next] net: restore the iterator to its original state when an error occurs

In zerocopy_fill_skb_from_iter(), if two copy operations are performed
and the first one succeeds while the second one fails, it returns a
failure but the count in iterator has already been decremented due to
the first successful copy. This ultimately affects the local variable
rest_len in virtio_transport_send_pkt_info(), causing the remaining
count in rest_len to be greater than the actual iterator count. As a
result, packet sending operations continue even when the iterator count
is zero, which further leads to skb->len being 0 and triggers the warning
reported by syzbot [1].

Therefore, if the zerocopy operation fails, we should revert the iterator
to its original state.

[1]
'send_pkt()' returns 0, but 4096 expected
WARNING: net/vmw_vsock/virtio_transport_common.c:430 at virtio_transport_send_pkt_info+0xd1e/0xef0 net/vmw_vsock/virtio_transport_common.c:428, CPU#1: syz.0.17/5986
Call Trace:
 virtio_transport_stream_enqueue net/vmw_vsock/virtio_transport_common.c:1113 [inline]
 virtio_transport_seqpacket_enqueue+0x143/0x1c0 net/vmw_vsock/virtio_transport_common.c:841
 vsock_connectible_sendmsg+0xabf/0x1040 net/vmw_vsock/af_vsock.c:2158
 sock_sendmsg_nosec net/socket.c:727 [inline]
 __sock_sendmsg+0x21c/0x270 net/socket.c:746

Reported-by: syzbot+28e5f3d207b14bae122a@...kaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=28e5f3d207b14bae122a
Tested-by: syzbot+28e5f3d207b14bae122a@...kaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@...com>
---
 net/core/datagram.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/net/core/datagram.c b/net/core/datagram.c
index c285c6465923..da10465cd8a4 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -748,10 +748,13 @@ int __zerocopy_sg_from_iter(struct msghdr *msg, struct sock *sk,
 			    size_t length,
 			    struct net_devmem_dmabuf_binding *binding)
 {
+	struct iov_iter_state state;
 	unsigned long orig_size = skb->truesize;
 	unsigned long truesize;
 	int ret;
 
+	iov_iter_save_state(from, &state);
+
 	if (msg && msg->msg_ubuf && msg->sg_from_iter)
 		ret = msg->sg_from_iter(skb, from, length);
 	else if (binding)
@@ -759,6 +762,9 @@ int __zerocopy_sg_from_iter(struct msghdr *msg, struct sock *sk,
 	else
 		ret = zerocopy_fill_skb_from_iter(skb, from, length);
 
+	if (ret)
+		iov_iter_restore(from, &state);
+
 	truesize = skb->truesize - orig_size;
 	if (sk && sk->sk_type == SOCK_STREAM) {
 		sk_wmem_queued_add(sk, truesize);
-- 
2.43.0


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ