lwIP - A Lightweight TCP/IP stack - Bugs: bug #62857, sendmsg(), if called with last...
You are not allowed to post comments on this tracker with your current authentication level.
bug #62857: sendmsg(), if called with last item in msg_iov array to have .iov_len=0, build pbuf chain which cannot be cloned
Submitter: | Alex Riesen <raalkml> | ||
Submitted: | Wed 03 Aug 2022 11:03:40 AM UTC | ||
Category: | sockets/netconn | Severity: | 3 - Normal |
Item Group: | Faulty Behaviour | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open | Planned Release: | None |
lwIP version: | 2.1.0 |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
No changes have been made to this item
Hi,
I call lwip_sendmsg from LwIP 2.1.0 (release) with an UDP socket like this:
Usually, the payload is a string of bytes, but sometimes the function
"udp_tx" is called with zero-sized payload (end-of-transmission marker).
In those cases, the UDP packet on wire seems to contain random junk
instead of just whatever should be in the PROTOCOL_MAGIC.
After some debugging, it came to the low-level ethernet driver in my project,
which contains code like this:
The Ethernet hardware apparently needs a contiguous, aligned data to transfer,
and the code tried to provide that.
The problem is that pbuf_clone returns not the expected pbuf containing the
flattened chain given in the "p" argument. The implementation in 2.1.0 (and if
I'm not mistaken, also in master) will return the allocated, partially filled
buffer, ignoring returned error from pbuf_copy!
The pbuf_copy in this case returns the errors because of this code:
On its final iterations, having processed Ethernet, IP, UDP, and the magic
from application, it reaches the zero-sized msg_iov item and returns with an
error code, which pbuf_clone mostly ignores (might print a debug message) and
returns new pbuf to the caller, which has no way to know that it is not the
clone it wanted.
Now, arguably "sendmsg" shouldn't have created such an evil chain of pbufs.
On the other hand, pbuf_clone is a public function and is even prepared to
fail (it returns NULL). On yet another hand, pbuf_copy may simply skip over
such buffers.
Right now, pbuf_clone just silently produces partial clones. And sendmsg silently
(under some circumstances, admitted) sends corrupted packets.