vsock/virtio: fix msg_iter desync on transmission failure#958
vsock/virtio: fix msg_iter desync on transmission failure#958blktests-ci[bot] wants to merge 3 commits into
Conversation
|
Upstream branch: 2a2974b |
5f78e5d to
e48f9db
Compare
|
Upstream branch: 062871f |
574b987 to
4add41c
Compare
e48f9db to
199644a
Compare
|
Upstream branch: 5b33fc6 |
4add41c to
f5712cb
Compare
199644a to
e6d9eb8
Compare
|
Upstream branch: 66affa3 |
f5712cb to
bffc3fd
Compare
|
Upstream branch: 66affa3 |
bffc3fd to
376e05b
Compare
e6d9eb8 to
7d8604f
Compare
|
Upstream branch: bade58e |
376e05b to
0d3edcc
Compare
7d8604f to
4cc45a3
Compare
|
Upstream branch: 4edcdef |
0d3edcc to
22d5bb7
Compare
4cc45a3 to
90ffd56
Compare
|
Upstream branch: dc59e4f |
22d5bb7 to
b2153c1
Compare
90ffd56 to
d52f35a
Compare
|
Upstream branch: 87320be |
b2153c1 to
d69b4f2
Compare
d52f35a to
a644c13
Compare
Export iov_iter_restore so that it can be used by modules. This is needed by the virtio vsock transport (which can be built as a module) to restore the msg_iter state when transmission fails. Acked-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Octavian Purdila <tavip@google.com>
When transmission fails in virtio_transport_send_pkt_info, the msg_iter
might have been partially advanced. If we don't restore it, the next
attempt to send data will use an incorrect iterator state, leading to
desync and warnings like "send_pkt() returns 0, but X expected".
Specifically, this can happen in the following scenario, triggered by
the syzkaller repro:
1. A write-only VMA (PROT_WRITE only) is partially populated by a
prior TUN write that failed with -EIO but still faulted in some
pages).
2. A vsock sendmmsg call with MSG_ZEROCOPY requests transmission of a
buffer from this VMA.
3. The first packet (64KB) is sent successfully because the pages are
populated.
4. The second packet allocation fails because GUP fast pins the first page
but GUP slow fails on the next unpopulated page due to PROT_WRITE-only
permissions.
5. The iterator is advanced by the partially successful GUP (68KB total
advanced: 64KB from first packet + 4KB from second), but the send loop
breaks and only reports 64KB sent. This creates a 4KB desync.
6. The next retry starts with a non-zero iov_offset, disabling zerocopy
and falling back to copy mode.
7. In copy mode, the transmission succeeds for the next packets but
exhausts the iterator early because of the desync.
8. The final retry sees an empty iterator but zerocopy is re-enabled
(offset resets). It attempts to send the remaining bytes with zerocopy
but pins 0 pages, creating an empty packet.
9. The transport sends the empty packet, triggering the warning because
the returned bytes (header only) do not match the expected payload size.
10. The loop continues to spin, allocating ubuf_info each time, eventually
exhausting sysctl_optmem_max and returning -ENOMEM to userspace.
Restore msg_iter to its original state before the packet allocation
and transmission attempt if they fail.
Fixes: e0718bd ("vsock: enable setting SO_ZEROCOPY")
Reported-by: syzbot+28e5f3d207b14bae122a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=28e5f3d207b14bae122a
Assisted-by: gemini:gemini-3.1-pro
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Octavian Purdila <tavip@google.com>
|
Upstream branch: 8cdeaa5 |
d69b4f2 to
debba61
Compare
a644c13 to
a2204c3
Compare
Pull request for series with
subject: vsock/virtio: fix msg_iter desync on transmission failure
version: 2
url: https://patchwork.kernel.org/project/linux-block/list/?series=1110932