Repository navigation
fix(libkernel): fail sendto to port 0 from an unbound IPv4 datagram socket with EADDRNOTAVAIL - #8499
Conversation
|
Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.
Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.
|
|
Thanks, the rule matches |
…ocket with EADDRNOTAVAIL udp_output hands the destination to in_pcbconnect_setup unless the socket is bound to a specific address and port and the destination is neither INADDR_ANY nor INADDR_BROADCAST, and in_pcbconnect_setup fails port 0 with EADDRNOTAVAIL. The send went to the host, which accepted it. sendto, and sendmsg through it, now fails the same way for an AF_INET datagram socket that is not connected. connect to port 0 already did. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…he host Linux's udp_sendmsg refuses port 0 with EINVAL, so a send that FreeBSD accepts (the socket is bound to a specific address and port and the destination is not INADDR_ANY or INADDR_BROADCAST) failed there. Nothing can receive on port 0, so the call now returns the length itself on every host. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
f531a91 to
0bb7b02
Compare
|
Thanks, you're right: Linux's udp_sendmsg refuses port 0 with EINVAL. The send that FreeBSD accepts (socket bound to a specific address and port, destination not INADDR_ANY/INADDR_BROADCAST) is now answered in Udp.cpp without the host in 0bb7b02: nothing can receive on port 0, so it returns the length on every platform. The Technical debt entry says so; guest_udp now also checks that nothing is queued afterwards. Re-tested on Windows 10 (guest_udp, guest_sce_net, guest_socket_address_length pass); I could not run Linux here, so the Linux CI is the check. AI-assisted (Claude Code). |
|
Re-reviewed against current main (cf2c667): the bound-socket answer in 0bb7b02 matches the |
What
udp_outputhands the destination toin_pcbconnect_setupunless the socket is bound to a specific address and port and the destination is neitherINADDR_ANYnorINADDR_BROADCAST(in_pcbconnect_setupfails port 0 withEADDRNOTAVAIL).sendto, andsendmsgthrough it, sent such a datagram to the host. For anAF_INETdatagram socket that is not connected they now fail with 49 in those cases; a socket bound to a specific address and port can still send to port 0, as FreeBSD allows. This closes thesendto/sendmsgpart of the known gap in theconnectTechnical debt entry (#6884).AF_INET6is unchanged.Fixes #8498
Overlap:
git merge-treeagainst #7475 (sendto on a connected socket, open) has one conflict inUdp.cpp; against #7090, #8392, #8448, #8463, #8474, #8483, #8492, #7511, #7850, #7490 and #8312 it is clean. Whichever lands second rebases.pr_overlapwas not run.Tested
Windows 10 (19045), MinGW-w64 GCC 15.2.0, Release, on upstream/main d0eb3b6 + this commit:
guest_udp: the new case aborts without the change toUdp.cppand passes with it. It checks port 0 from an unbound socket (49, nothing queued), a datagram to the real port, port 0 from a socket bound to 127.0.0.1 (sent) and destination 0.0.0.0 port 0 from that socket (49).guest_datagram_recv,guest_sce_net,guest_socket_error,guest_socket_address_length,guest_pollandguest_tcppass.python tools/check_conventions.py --base upstream/main: passes.sendmsgdirectly,AF_INET6.Checklist
main; no other open PR implements the same functions (fix(libkernel): return EISCONN from sendto with an address on a connected datagram socket #7475 changessendtofor a connected socket).mdfiles or images added to the repositoryAI-assisted (Claude Code).
🤖 Generated with Claude Code