Skip to content

Conversation

@alyssais
Copy link
Member

The read_exact() call was introduced in 82ac114 ("virtio-devices: vsock: handle short read in muxer") to solve a crash when a connection disconnected without sending any data, but it introduced a problem of its own: because the socket is non-blocking, read_exact() may read some data, then return ErrorKind::WouldBlock. In that case, the data it read will be discarded. So for example if it read "CONNECT ", and then nothing else was available to read yet, "CONNECT " would be discarded, and so the next time this function was called, when epoll triggered again for the socket, only the following data would end up in command.buf, causing an error due to just a port number being an invalid command.

Contrary to that commit message, this code was actually designed to handle short reads just fine — in the case of a short read, it stores the data it has read in command, and returns Error::UnixRead(ErrorKind::WouldBlock), which is ignored by the caller, and the function gets called again when there is more data to read, building up command potentially over the course of several reads. The only thing it didn't handle correctly, as far as I can tell, was a 0-byte read, which happens when a client disconnects from the socket without writing anything. All that's needed to fix this is to avoid an invalid subtraction in that case, so this change reverts 82ac114, fixing the issue with partial commands being discarded, and instead handles the 0-byte read by using slice::get, and treating an empty command as an incomplete command, which of course it is.

@alyssais alyssais requested review from liuw and rbradford July 14, 2025 17:04
@alyssais alyssais requested a review from a team as a code owner July 14, 2025 17:04
The read_exact() call was introduced in 82ac114 ("virtio-devices:
vsock: handle short read in muxer") to solve a crash when a connection
disconnected without sending any data, but it introduced a problem of
its own: because the socket is non-blocking, read_exact() may read
some data, then return ErrorKind::WouldBlock.  In that case, the data
it read will be discarded.  So for example if it read "CONNECT ",
and then nothing else was available to read yet, "CONNECT " would be
discarded, and so the next time this function was called, when epoll
triggered again for the socket, only the following data would end up
in command.buf, causing an error due to just a port number being an
invalid command.

Contrary to that commit message, this code was actually designed to
handle short reads just fine — in the case of a short read, it stores
the data it has read in command, and returns
Error::UnixRead(ErrorKind::WouldBlock), which is ignored by the
caller, and the function gets called again when there is more data to
read, building up command potentially over the course of several
reads.  The only thing it didn't handle correctly, as far as I can
tell, was a 0-byte read, which happens when a client disconnects from
the socket without writing anything.  All that's needed to fix this is
to avoid an invalid subtraction in that case, so this change reverts
82ac114, fixing the issue with partial commands being discarded, and
instead handles the 0-byte read by using slice::get, and treating an
empty command as an incomplete command, which of course it is.

Fixes: 82ac114 ("virtio-devices: vsock: handle short read in muxer")
Signed-off-by: Alyssa Ross <[email protected]>
@rbradford rbradford added this pull request to the merge queue Jul 14, 2025
Merged via the queue into cloud-hypervisor:main with commit ec8fceb Jul 14, 2025
39 checks passed
@alyssais alyssais deleted the vsock-corruption branch July 15, 2025 08:45
@likebreath likebreath moved this from 🆕 New to ✅ Done in Cloud Hypervisor Roadmap Jul 16, 2025
@likebreath likebreath added the bug-fix Bug fix to include in release notes label Jul 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug-fix Bug fix to include in release notes

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants