CVS commit: [netbsd-10] src/sys

["Martin Husemann" <martin%netbsd.org@localhost>]

Module Name:    src
Committed By:   martin
Date:           Fri Jul  3 18:18:10 UTC 2026

Modified Files:
        src/sys/net [netbsd-10]: if_wg.c
        src/sys/rump/net/lib/libwg [netbsd-10]: wg_user.c

Log Message:
Pull up following revision(s) (requested by riastradh in ticket #1302):

        sys/rump/net/lib/libwg/wg_user.c: revision 1.4
        sys/net/if_wg.c: revision 1.141

wg-userspace(8): Drop <4-byte UDP packets immediately.

Same as the kernel already does.  Add an assertion into
wg_receive_packets about this and a couple comments cross-referencing
wg_overudp_cb and wg_receive_packets.

And, while here, as a precaution in case the
inpcb_register_overudp_cb mechanism ever breaks down or gets
refactored, make wg_receive_packets drop <4-byte packets too -- this
path should be hit only when handling handshake packets, so adding
another predicted-not-taken branch here should cost essentially
nothing.

PR bin/60392: assertion "mbuflen >= sizeof(struct wg_msg)" failed

wg-userspace(8): Ignore recvfrom errors.

On IPv6 networks, issuing sendto(2) when we've lost IPv6 connectivity
may eventually lead to the next recvfrom(2) failing with EHOSTDOWN.

Example ktrace:
  8072  16529 rump_server 1782951176.090085182 CALL  sendto(0xa,0x70fb4fa1b50c,0x60,0,0x70fb4f236b00,0x1c)
  8072  16529 rump_server 1782951176.090085664 MISC  msghdr: [name=0x70fb4f236b00, namelen=28, iov=0xffffc5126bfa8f50, iovlen=1, control=0x0, controllen=0, flags=0]
  8072  16529 rump_server 1782951176.090086919 MISC  mbsoname: [2601:...]
  8072  16529 rump_server 1782951176.090093493 GIO   fd 10 wrote 96 bytes
  8072  16529 rump_server 1782951176.090094033 RET   sendto 96/0x60
...
  8072  23248 rump_server 1782951180.090105990 CALL  recvfrom(0xa,0x70fb4efe203c,0x233a,0,0x70fb3f7cff50,0x70fb3f7cff4c)
  8072  23248 rump_server 1782951180.090106339 MISC  msghdr: [name=0x0, namelen=0, iov=0xffffc5126c63ff20, iovlen=1, control=0x0, controllen=0, flags=0]
  8072  23248 rump_server 1782951180.090107309 RET   recvfrom -1 errno 64 Host is down

In this case, wg_user_rcvthread mistakenly ignored the failing result
and blithely shoved the ssize_t -1 error indicator into
iov[1].iov_len and passed it on to rumpkern_recv_peer:
                        nn = recvfrom(wgu->wgu_sock6, wgu->wgu_rcvbuf,
                            sizeof(wgu->wgu_rcvbuf), 0, (struct sockaddr *)&sin6,
                            &len);
                        if (nn == -1 && errno == EAGAIN)
                                continue;
...
                        iov[1].iov_base = wgu->wgu_rcvbuf;
                        iov[1].iov_len = nn;
...
                        rumpkern_wg_recv_peer(wgu->wgu_sc, iov, 2);
rumpkern_wg_recv_peer then passed it through to m_copyback to fill a
newly allocated mbuf:
        m = m_gethdr(M_DONTWAIT, MT_DATA);
        if (m == NULL)
                return;
        m->m_len = m->m_pkthdr.len = 0;
        m_copyback(m, 0, iov[1].iov_len, iov[1].iov_base);

And m_copyback takes int, not size_t.  So the all-bits-set turned
into -1, which coincides with M_COPYALL, which means that we treat
this case as a zero-length mbuf, which was the actual source of the
phantom zero-length packets I initially thought were the cause of:

PR bin/60392: assertion "mbuflen >= sizeof(struct wg_msg)" failed

So several wrongs here made a right, turning several mistakes that
could have been buffer overruns into a harmless crash.

In any case, we don't really care that IPv6 is unreachable.  We'll
just keep trying sendto until connectivity is restored, and then
wg(4) packets can flow again.  So just ignore the recvfrom error.


To generate a diff of this commit:
cvs rdiff -u -r1.71.2.6 -r1.71.2.7 src/sys/net/if_wg.c
cvs rdiff -u -r1.3 -r1.3.20.1 src/sys/rump/net/lib/libwg/wg_user.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.