Fix sendmsg/recvmsg data corruption in bsdsocket emulation

[tbdye]

Problem

sendmsg() in the bsdsocket emulation silently sent data from the wrong memory location. The host_sendto() function (POSIX path) always assigned sb->buf = get_real_address(msg) regardless of whether a host-side buffer was provided via hmsg. When called from bsdsocklib_sendmsg(), msg is 0 and hmsg points to the coalesced iovec data — so get_real_address(0) resolved to natmem_offset (Amiga address 0) instead of the actual data buffer. The worker thread then sent whatever was at the start of Amiga chip RAM.

Two additional bugs existed in the sendmsg/recvmsg trap handlers:

• bsdsocklib_sendmsg() passed the Amiga address of the msg_namelen field as tolen to host_sendto(), but the worker thread uses tolen as a length value. This broke UDP sendmsg() with a destination address, since copysockaddr_a2n() received a multi-million-byte "length" and rejected it.

• bsdsocklib_recvmsg() used ftable[sd - 1] with a 0-based socket descriptor, causing an off-by-one in MSG_TRUNC detection. For socket 0 this was an out-of-bounds read (ftable[-1]); for all others it checked the wrong socket's flags.

Fix

Three targeted changes:

1. host_sendto(): Use realpt (which already handles both the normal send/sendto path and the sendmsg path) instead of unconditionally calling get_real_address(msg). This matches how host_recvfrom() already works.

2. bsdsocklib_sendmsg(): Read the msg_namelen value with trap_get_long() before passing to host_sendto(), consistent with how normal sendto() passes tolen from the D3 register.

3. bsdsocklib_recvmsg(): Use ftable[sd] instead of ftable[sd - 1] for correct 0-based indexing.

Validation

Tested with bsdsocktest 0.2.2 (142 tests):

Run	Passed	Failed	Known	Skipped
Before (loopback)	116	0	11	15
After (loopback)	118	0	9	15
After (with host helper)	130	0	9	3

Tests fixed: 31 (sendmsg/recvmsg single iovec), 32 (sendmsg/recvmsg scatter-gather). No regressions across all 142 tests.

🤖 Generated with Claude Code