Conversation
sangho2
reviewed
May 8, 2026
Comment on lines
+1598
to
+1612
| let size = self.do_recvfrom( | ||
| sockfd, | ||
| recv_buf, | ||
| flags, | ||
| if want_source { | ||
| Some(&mut source_addr) | ||
| } else { | ||
| None | ||
| }, | ||
| )?; | ||
|
|
||
| // Set MSG_TRUNC if the received message was larger than the total buffer. | ||
| if size > total_iov_capacity { | ||
| ret_flags |= ReceiveFlags::TRUNC; | ||
| } |
Contributor
There was a problem hiding this comment.
High: recvmsg does not set output MSG_TRUNC for truncated datagrams.
this calls do_recvfrom without forcing MSG_TRUNC, then sets msg_flags only when size > total_iov_capacity. For datagram sockets, do_recvfrom returns the copied length unless the caller passed input MSG_TRUNC, so a too-large datagram received without input MSG_TRUNC returns the copied byte count but leaves msg_flags empty. Linux recvmsg should set msg_flags |= MSG_TRUNC when the datagram was larger than the supplied iovecs.
It sounds like size cannot be greater than total_iov_capacity for datagrams received without MSG_TRUNC even if there was truncation.
Contributor
Author
There was a problem hiding this comment.
Yes, it is checked at
litebox/litebox_shim_linux/src/syscalls/net.rs
Lines 1631 to 1637 in 5441699
Comment on lines
+1573
to
+1588
| if msg_iovlen == 0 || msg_iovlen > 1024 { | ||
| return Err(Errno::EINVAL); | ||
| } | ||
|
|
||
| let iovs = msg_iov.to_owned_slice(msg_iovlen).ok_or(Errno::EFAULT)?; | ||
|
|
||
| // Compute total buffer capacity across all non-empty iovecs, capped at MAX_LEN. | ||
| let total_iov_capacity: usize = iovs | ||
| .iter() | ||
| .map(|iov| iov.iov_len) | ||
| .fold(0usize, usize::saturating_add) | ||
| .min(MAX_LEN); | ||
|
|
||
| if total_iov_capacity == 0 { | ||
| return Ok(0); | ||
| } |
Contributor
There was a problem hiding this comment.
High: zero-length recvmsg is incorrect.
This rejects msg_iovlen == 0 with EINVAL, and returns 0 immediately when total iovec capacity is zero. Linux permits zero-length receives. For datagram sockets, a zero-length receive can still dequeue one pending datagram and should update output fields such as msg_flags, msg_namelen, and msg_controllen.
It sounds like LiteBox might not dequeue pending zero-length datagram?
Contributor
Author
There was a problem hiding this comment.
Right, I added a test to confirm that's Linux's behavior. It is fixed now.
|
🤖 SemverChecks 🤖 Click for details |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Support syscall
recvmsg.Some flags like
MSG_PEEKis not supported yet but can be added when needed.Also fix a message boundary issue for datagram unix socket, i.e., one read should only read one message.