net_poll trusts the firmware's claimed read length — port c64-wireguard's drop-not-trim validation

[JC-000]

Offered in #70 (item 3b, reverse direction). Filing so it is trackable independently.

The gap

src/net/uci/net.s's net_poll takes the SOCKET_READ response header straight into uci_poll_rem and starts copying, with no check that the returned actual_len is a value the adapter actually asked for.

It survives a bogus length only incidentally: the inner copy loop re-checks ring-full and DATA_AV on every byte, so a wild length exits early rather than running away. That is a property of the copy loop, not a validation, and it is one refactor away from not holding.

Why this is worth a real check

This firmware is documented to return nonsense lengths. Measured on U64E fw 3.14d (c64-wireguard tools/test_uci_udp_size_probe.py, 2026-08-24):

requested	returned
600 / 768 / 1280	512 (remainder silently discarded)
1024 / 1500	nothing delivered at all

and a 1500-byte request has been observed returning 0xFFFF. A firmware that returns 0xFFFF for a 1500-byte request can return a bogus length for a 512-byte one; nothing about the 512 cap makes the response trustworthy.

c64-wireguard learned this expensively. Its PR #62 fixed a case where net_poll trusted the returned length and copied ~18 KB from udp_recv_buf through $D000 — WireGuard packet bytes were found sitting in the VIC registers, presenting as a red screen and garbled charset that looked like a video bug rather than a memory-safety bug.

The check

c64-wireguard src/net/uci/net.s, the @hdr_done block — validate before trusting, and drop rather than trim:

        lda uci_read_hdr+1
        cmp #>UCI_READ_CHUNK_MAX
        bcc @len_ok                 ; hi < 2 -> certainly under the cap
        bne @len_bad                ; hi > 2 -> certainly over it
        lda uci_read_hdr+0          ; hi == 2 -> only exactly 512 is legal
        beq @len_ok
@len_bad:
        lda #UCI_ERR_LONG_READ
        sta net_last_error
        ; ...drain, do not copy

Dropping is deliberate: a trimmed datagram is a corrupt datagram, and for c64-wireguard it fails AEAD anyway. For a TCP stream the equivalent argument is that a truncated fill silently desynchronises the stream — which is the same class of defect d9cd021 chased through a ring wrap, arriving from the other end.

UCI_ERR_LONG_READ is $8A in c64-wireguard, proposed for reservation in #70 (3a) and filed against the contract as JC-000/c64-lib-contract#137.

Note on the reverse direction

d9cd021's ring-free-space clamp does not port to c64-wireguard — that adapter reads one datagram into a flat buffer behind a udp_recv_ready interlock, with no wrapping ring and no free-space computation. Detail in #70. These two fixes are complements, not the same fix seen twice.

[JC-000]

Taken, with measurements that changed the answer — see #143.

Porting the drop-on-over-claim check verbatim aborted every real github.com handshake at the first read. The rig now dumps the pair: first poll uci_req_len=$0200, uci_read_hdr=$FFFF (ring empty, ~690 B queued); last poll $0016/$0016. On the TCP path the 3.14d header is a count when the queue fits the request and the $FFFF sentinel otherwise — the same sentinel you saw for a 1500 B UDP request. So on a byte stream over-claim is routine and recoverable (the excess stays queued); the fix is a bound — copy at most the request — not a drop. $8A keeps your datagram disposition and is never emitted here; a header above the request that is not $FFFF now leaves $8B UCI_ERR_BAD_READ_HDR as a C=0 breadcrumb, allocated in SPEC §13.2 (c64-lib-contract#139) before use.

Your point stands in full: the old code's safety was a property of the copy loop, not a validation, and that is now fixed by construction. The reverse port (our ring clamp into your adapter) is withdrawn for the reasons you gave. Still unmeasured, and yours if you want it: what the UDP header reads for a 600-1280 B datagram against a 512 B request.

[JC-000]

Correction to my comment above, from c64-wireguard's idle-UDP measurement (every idle SOCKET_READ returns header $FFFF, rx_len 0, 11/11 sizes): $FFFF is the no-data sentinel on both transports. Our first-poll capture was at tls_last_state=2 — an idle poll waiting for ServerHello — so "~690 B queued" was an inference, and the drop-and-error cut aborted on an empty read, the same misfiling c64-wireguard carried for four days as a documented firmware quirk. $FFFF must be excluded before any over-claim test. #143's code is unchanged and byte-identical (the cap plus the DATA_AV check already copy zero bytes on the sentinel); cfebf5f corrects its comments, and c64-lib-contract#139's rows now say this in the table.