{"@attributes":{"version":"2.0"},"channel":{"title":"DEV Community: zerox80","description":"The latest articles on DEV Community by zerox80 (@zerox80).","link":"https:\/\/dev.to\/zerox80","image":{"url":"https:\/\/media2.dev.to\/dynamic\/image\/width=90,height=90,fit=cover,gravity=auto,format=auto\/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4229178%2F887d0b8a-3a57-45e5-8458-c350bc76884c.jpg","title":"DEV Community: zerox80","link":"https:\/\/dev.to\/zerox80"},"language":"en","item":[{"title":"Before authentication: three bugs in Mullvad's gotatun","pubDate":"Thu, 05 Nov 2026 20:10:45 +0000","link":"https:\/\/dev.to\/zerox80\/before-authentication-three-bugs-in-mullvads-gotatun-25ih","guid":"https:\/\/dev.to\/zerox80\/before-authentication-three-bugs-in-mullvads-gotatun-25ih","description":"

WireGuard is known for staying silent towards packets it cannot authenticate. A userspace implementation still has to receive a UDP datagram, interpret the result of a socket call, and move bytes through its internal tasks before it can reject that packet. Bugs in those steps can stop a tunnel without breaking any cryptography.<\/p>\n\n

I found three such bugs in gotatun<\/a>, Mullvad's userspace WireGuard implementation in Rust. One empty datagram could terminate a Linux receive task. An oversized datagram could stop reception in the default Windows transport. A separate issue let handshake rate-limiter state accumulate when no peer had an endpoint.<\/p>\n\n

All three are fixed. This post walks through the failure paths, the evidence behind them, and what the fixes change. The scope is gotatun and the configurations described below; these findings do not establish the exposure of a particular deployed VPN product.<\/p>\n\n

\n\n\n\n\n\n\n
Finding<\/th>\nRelevant path or condition<\/th>\nAdvisory severity<\/th>\nFirst patched release<\/th>\n<\/tr>\n<\/thead>\n
Empty datagram causes a panic<\/td>\nLinux batched\/GRO receive path<\/td>\nHigh, CVSS 7.5<\/td>\n0.10.1<\/td>\n<\/tr>\n
Oversized datagram stops reception<\/td>\nWindows built-in transport without windows-gro<\/code>\n<\/td>\nHigh, CVSS 7.5<\/td>\n0.10.0<\/td>\n<\/tr>\n
Source-IP counters accumulate<\/td>\nListening device with no known peer endpoints<\/td>\nModerate<\/td>\n0.10.1<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/div>\n\n

The advisories identify 0.9.2 as affected for the Linux and rate-limiter findings, and versions through 0.9.2 for the Windows finding. The older-version coverage was not exhaustively established in the original reports. For the issues covered here, 0.10.1 is the first release containing all three fixes.<\/p>\n\n

\n \n \n Where the authentication boundary actually sits\n<\/h2>\n\n

It helps to separate accepting a datagram from accepting a WireGuard peer. The implementation first receives the datagram through its platform-specific socket code. A buffered receive task passes it through a channel to the device handler, which then runs packet verification and handshake processing.<\/p>\n\n

The first two findings interrupt this path before packet verification. A valid handshake is unnecessary: the trigger is a property of the UDP datagram itself.<\/p>\n\n

The rate-limiter finding is slightly different. It requires a handshake-shaped packet with a valid MAC1, but that check does not authenticate a configured peer. The distinction matters because a public-key-derived MAC can protect a different boundary from one that requires a peer's secret key.<\/p>\n\n

These are availability failures. Their mechanisms do not demonstrate decryption, key disclosure, or code execution. Their reach comes from putting device-wide resources on a path that processes untrusted input.<\/p>\n\n

\n \n \n 1. An empty datagram kills the Linux receive task\n<\/h2>\n\n

GHSA-6gxq-8xp9-742r<\/a> \u00b7 High, CVSS 7.5 \u00b7 fixed in 0.10.1<\/p>\n\n

\n \n \n The assumption behind the panic\n<\/h3>\n\n

The affected Linux implementation receives datagrams in batches using recvmmsg<\/code>. In gotatun\/src\/udp\/socket\/linux.rs<\/code>, it obtains the payload for each result through an iterator over the received I\/O slices:
\n<\/p>\n\n

\n
result<\/span>.iovs<\/span>()<\/span>.next<\/span>()<\/span>.expect<\/span>(<\/span>\"we create exactly one IoSlice\"<\/span>)<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
The comment embedded in the panic message explains the assumption: one slice was supplied, so one slice must be returned.<\/p>\n\n
With the nix<\/code> 0.31.2 behavior described in the advisory, an empty received datagram makes this iterator return None<\/code>. The buffer arrangement used to request a receive does not guarantee a nonempty result iterator for every possible datagram. Calling expect<\/code> turns that mismatch into a panic.<\/p>\n\n
A zero-length UDP datagram is a valid message. It is different from a stream reaching EOF: the sender has sent a datagram whose payload length happens to be zero. There is no reason for a WireGuard implementation to accept it as a protocol packet, but receiving it must remain a normal, discardable event.<\/p>\n\n
\n  \n  \n  How a packet-level edge case becomes device-wide\n<\/h3>\n\n
The panic does not stay attached to the offending packet. It terminates the shared UDP receive task, which serves all peers on that gotatun device.<\/p>\n\n
The resulting failure is therefore larger than a failed handshake:<\/p>\n\n
    \n
  1. An unauthenticated sender delivers an empty datagram to the listening UDP port.<\/li>\n
  2. The batched receiver reaches the expect<\/code> while extracting its payload.<\/li>\n
  3. The receive task panics and its channel closes.<\/li>\n
  4. Further inbound traffic cannot reach the device's peers through that task.<\/li>\n<\/ol>\n\n
    Restarting or reconfiguring the device is required to restore reception. The demonstrated scope is the device's receive path; describing it as an inevitable crash of the entire embedding process would go beyond that evidence.<\/p>\n\n
    The report's Linux loopback reproduction queues an empty datagram followed by a nonempty control message. It observes the buffered receiver returning a broken-pipe error after its producer task panics. No configured tunnel peer or secret key is needed. The control message is important: it distinguishes losing one useless packet from losing the ability to receive the next useful one.<\/p>\n\n
    \n  \n  \n  The upstream fix\n<\/h3>\n\n
    The fixing pull request, #204<\/a>, changes the empty iterator result into a skip instead of a panic. This is the replacement statement inside the loop over receive results:
    \n<\/p>\n\n
    \n
    let<\/span> Some<\/span>(<\/span>iov<\/span>)<\/span> =<\/span> result<\/span>.iovs<\/span>()<\/span>.next<\/span>()<\/span> else<\/span> {<\/span>\n    cold_path<\/span>();<\/span>\n    if<\/span> cfg!<\/span>(<\/span>debug_assertions<\/span>)<\/span> {<\/span>\n        tracing<\/span>::<\/span>trace!<\/span>(<\/span>\"Received empty datagram from IoSlice\"<\/span>);<\/span>\n    }<\/span>\n    continue<\/span>;<\/span>\n};<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
    That is the right level at which to handle the condition: discard this receive result and continue processing the batch. There is no need to authenticate the empty packet, reconstruct the device, or make unrelated peers pay for it.<\/p>\n\n
    The PR also includes a regression test. For this kind of bug, a useful assertion is not merely that the receiver avoids panicking. It should verify that a normal message still gets through after the empty one.<\/p>\n\n
    \n  \n  \n  What Windows reports\n<\/h3>\n\n
    When an incoming datagram is larger than the supplied buffer, Windows can return WSAEMSGSIZE<\/code>, error 10040. Microsoft's recvfrom<\/code> documentation<\/a> describes the truncation and explains that excess UDP data is lost.<\/p>\n\n
    That describes a problem with this message. In the native reproduction, the socket remained usable: a subsequent direct receive obtained the next, shorter message.<\/p>\n\n
    Gotatun nevertheless propagated the first error out of the receive worker. A recoverable condition at the socket boundary became the end of the producer task.<\/p>\n\n
    \n  \n  \n  Following the error through the task boundary\n<\/h3>\n\n
    The receive producer in BufferedUdpReceive::new<\/code><\/a> exits on a failed receive. This statement sits inside its packet-processing loop:
    \n<\/p>\n\n
    \n
    let<\/span> Ok<\/span>(())<\/span> =<\/span> udp_rx<\/span>\n    .recv_many_from<\/span>(<\/span>&<\/span>mut<\/span> recv_many_buf<\/span>,<\/span> &<\/span>mut<\/span> recv_pool<\/span>,<\/span> &<\/span>mut<\/span> packet_bufs<\/span>)<\/span>\n    .await<\/span>\nelse<\/span> {<\/span>\n    \/\/ TODO<\/span>\n    return<\/span>;<\/span>\n};<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
    That return<\/code> drops the channel's sender. After already queued packets drain, the buffered consumer encounters the closed channel and the device's receive loop ends.<\/p>\n\n
    The last step made the problem harder to notice. DeviceState::handle_incoming<\/code> ended with Ok(())<\/code>, so that exit did not register as a fatal error and did not restart reception. The operating system had not permanently broken the socket; the library had stopped asking it for packets.<\/p>\n\n
    This also explains why a test that only checks the first receive error is incomplete. It proves that Windows reports an oversized datagram, but it does not establish what the application does after that error crosses its buffering and task boundaries.<\/p>\n\n
    \n  \n  \n  What I tested\n<\/h3>\n\n
    I tested this on native Windows 11, first at the socket and buffered-receiver layers, then with two peered gotatun devices using real loopback UDP sockets and in-process TUN channels.<\/p>\n\n
    Baseline traffic succeeded in both the patched and unpatched builds. After a single 8192-byte datagram was delivered to one device's UDP port, the unpatched build failed to deliver a subsequent packet to that device within five seconds. With only the Windows receive patch applied, traffic continued in both directions.<\/p>\n\n
    That comparison ties the observable outage to the receive error handling. It covers the library's device data path. A complete VPN product and recovery by rebuilding the device were not tested, so those remain separate deployment questions.<\/p>\n\n
    The configuration limit matters too. The optional Windows GRO path uses a different, larger batch buffer, and Linux has a different receive implementation. This finding should not be expanded into a claim that every platform or transport configuration stops on the same input.<\/p>\n\n
    \n  \n  \n  Recover at the point where the error is understood\n<\/h3>\n\n
    The patch I included with the report handles WSAEMSGSIZE<\/code> locally, discards the offending message, and continues receiving. Here is the complete UdpSocket::recv_datagram<\/code> method from gotatun 0.10.0<\/a>:
    \n<\/p>\n\n
    \n
    async<\/span> fn<\/span> recv_datagram<\/span>(<\/span>&<\/span>self<\/span>,<\/span> pool<\/span>:<\/span> &<\/span>mut<\/span> PacketBufPool<\/span>)<\/span> -><\/span> io<\/span>::<\/span>Result<\/span><<\/span>(<\/span>Packet<\/span>,<\/span> SocketAddr<\/span>)<\/span>><\/span> {<\/span>\n    let<\/span> mut<\/span> buf<\/span> =<\/span> pool<\/span>.get<\/span>();<\/span>\n    loop<\/span> {<\/span>\n        match<\/span> self<\/span>.socket<\/span>()<\/span>.recv_from<\/span>(<\/span>&<\/span>mut<\/span> buf<\/span>)<\/span>.await<\/span> {<\/span>\n            Ok<\/span>((<\/span>n<\/span>,<\/span> src<\/span>))<\/span> =><\/span> {<\/span>\n                buf<\/span>.truncate<\/span>(<\/span>n<\/span>);<\/span>\n                return<\/span> Ok<\/span>((<\/span>buf<\/span>,<\/span> self<\/span>.map_src<\/span>(<\/span>src<\/span>)));<\/span>\n            }<\/span>\n            \/\/ Winsock discards the remainder of an oversized datagram. The socket<\/span>\n            \/\/ remains usable; never pass its truncated contents to the protocol.<\/span>\n            Err<\/span>(<\/span>err<\/span>)<\/span> if<\/span> err<\/span>.raw_os_error<\/span>()<\/span> ==<\/span> Some<\/span>(<\/span>WinSock<\/span>::<\/span>WSAEMSGSIZE<\/span>)<\/span> =><\/span> {<\/span>\n                tokio<\/span>::<\/span>task<\/span>::<\/span>yield_now<\/span>()<\/span>.await<\/span>;<\/span>\n            }<\/span>\n            Err<\/span>(<\/span>err<\/span>)<\/span> =><\/span> return<\/span> Err<\/span>(<\/span>err<\/span>),<\/span>\n        }<\/span>\n    }<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
    The yield gives the executor an opportunity to run other work between retries. Other receive errors still propagate. Treating one understood, message-local error as recoverable is different from swallowing every socket failure.<\/p>\n\n
    The broader lesson is about ownership of recovery. The socket layer knows what this platform-specific error means. If it lets that error terminate a shared task, every layer above it has to reconstruct context that was available at the original boundary.<\/p>\n\n
    \n  \n  \n  A valid MAC1 is not peer authentication\n<\/h3>\n\n
    The counter insertion happens after MAC1 validation. At first glance, that can look like a useful barrier against untrusted senders allocating state.<\/p>\n\n
    But the MAC1 key is derived from the device's public key. A sender who knows that public key can construct a packet that passes MAC1 without possessing a configured peer's secret key. The packet can therefore reach the rate-limiter accounting before the sender has authenticated as a peer.<\/p>\n\n
    The resource that matters here is the number of distinct source IPs, because those addresses become map keys. The 0.9.2 rate-limiter implementation<\/a> inserts or increments the entry before comparing its count to the per-IP limit:
    \n<\/p>\n\n
    \n
    fn<\/span> is_under_load<\/span>(<\/span>&<\/span>self<\/span>,<\/span> src_addr<\/span>:<\/span> IpAddr<\/span>)<\/span> -><\/span> bool<\/span> {<\/span>\n    let<\/span> mut<\/span> ip_counts<\/span> =<\/span> self<\/span>.ip_counts<\/span>.lock<\/span>();<\/span>\n    let<\/span> count<\/span> =<\/span> ip_counts<\/span>.counts<\/span>.entry<\/span>(<\/span>src_addr<\/span>)<\/span>.or_insert<\/span>(<\/span>0<\/span>);<\/span>\n    *<\/span>count<\/span> +=<\/span> 1<\/span>;<\/span>\n    *<\/span>count<\/span> ><\/span> self<\/span>.limit<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
    Sending more packets from one address and sending packets from many addresses exercise different limits. A per-IP packet threshold does not by itself bound the number of IP entries stored.<\/p>\n\n
    \n  \n  \n  Cleanup depended on peer activity\n<\/h3>\n\n
    The reset method in that same file checks whether enough time has passed, clears the entries, and updates its timestamp:
    \n<\/p>\n\n
    \n
    pub<\/span> fn<\/span> try_reset_count<\/span>(<\/span>&<\/span>self<\/span>)<\/span> {<\/span>\n    let<\/span> current_time<\/span> =<\/span> Instant<\/span>::<\/span>now<\/span>();<\/span>\n    let<\/span> mut<\/span> ip_counts<\/span> =<\/span> self<\/span>.ip_counts<\/span>.lock<\/span>();<\/span>\n    if<\/span> current_time<\/span>.duration_since<\/span>(<\/span>ip_counts<\/span>.last_reset<\/span>)<\/span> >=<\/span> RESET_PERIOD<\/span> {<\/span>\n        ip_counts<\/span>.counts<\/span>.clear<\/span>();<\/span>\n        ip_counts<\/span>.last_reset<\/span> =<\/span> current_time<\/span>;<\/span>\n    }<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
    It has to be called for any of that to happen. The caller was reached through the peer timer path, which skipped peers without an endpoint. If no peer had an endpoint, nothing reached the usual counter reset, even though the listening device could still process incoming handshake-shaped traffic.<\/p>\n\n
    The mismatch was between the lifecycle of the data and the lifecycle of its cleanup. The counters belonged to the device's exposed receive path, while their maintenance depended on the existence of a suitable peer.<\/p>\n\n
    The public advisory's test uses no sockets. It constructs packets with valid MAC1 values for 2,048 synthetic source IPs, separated into two groups across the normal reset interval. The entries remain until an explicit reset is invoked. Together with the device timer control flow, that demonstrates why elapsed time alone did not guarantee cleanup in the affected state.<\/p>\n\n
    This is evidence of retained growth, not a measurement of how quickly an attacker could exhaust a particular machine. A practical attack still requires traffic appearing from many distinct IPs. Filtering and anti-spoofing can limit that ability, which is one reason this finding needs more qualification than the single-datagram receive failures.<\/p>\n\n
    \n  \n  \n  What the fix changes\n<\/h3>\n\n
    The upstream fix, #205<\/a>, adds a reset attempt to the device's periodic maintenance, independently of the per-peer update path. The added call is straightforward:
    \n<\/p>\n\n
    \n
    if<\/span> let<\/span> Some<\/span>(<\/span>rate_limiter<\/span>)<\/span> =<\/span> device<\/span>.rate_limiter<\/span>.as_ref<\/span>()<\/span> {<\/span>\n    rate_limiter<\/span>.try_reset_count<\/span>();<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
    The existing peer-side reset remains. The important change is that device-owned counters now have a cleanup opportunity even when peer state supplies none. This patch should not be described as a new shrinking policy: the published change fixes when resets run.<\/p>\n\n
    \n  \n  \n  Testing the receive path after the bad input\n<\/h2>\n\n
    These findings suggest a more useful test question than whether a malformed packet gets rejected: can the service still do useful work afterward?<\/p>\n\n
    For the Linux and Windows cases, a regression test should queue the trigger and then a normal control message. It should use a bounded wait and assert that the control message arrives. That exercises continuity across the receive loop, buffering, and task lifetime.<\/p>\n\n
    For the rate limiter, the relevant boundary is time and device state. Tests should cover a listening device without peer endpoints, advance beyond the reset interval, and inspect whether entries are actually removed. Retained allocation should be measured separately from logical entry count.<\/p>\n\n
    Platform coverage also needs to follow implementation paths. A passing Linux test cannot establish Windows receive behavior. A passing non-GRO test cannot establish what the batched\/GRO implementation does. The operating-system wrapper is part of the behavior being tested.<\/p>\n\n
    \n  \n  \n  Updating and reviewing downstream use\n<\/h2>\n\n
    Update gotatun to 0.10.1 or a later release containing these fixes<\/strong>. Version 0.10.0 contains the Windows fix, but 0.10.1 is the first release that also covers the Linux panic and rate-limiter cleanup issue.<\/p>\n\n
    For an application embedding the library, inspect the resolved dependency and the deployed build, then check the actual target platform and transport features. A library advisory establishes a vulnerable path; determining whether a specific product exposes that path requires its own configuration and integration evidence.<\/p>\n\n
    When reviewing a similar UDP service, I would start with a few concrete questions:<\/p>\n\n
    \n  \n  \n  Emptying a map and releasing its allocation are different\n<\/h3>\n\n
    There was another relevant detail: HashMap::clear()<\/code><\/a> removes entries while retaining allocated memory for reuse.<\/p>\n\n
    That behavior is useful in a repeatedly reused collection. It also means that an empty map is not evidence that memory has returned to its earlier footprint. When reviewing a resource-exhaustion report, both entry count and retained capacity deserve attention.<\/p>\n\n
    Those are separate questions, though. Restoring periodic resets addresses the missing-cleanup lifecycle. Deciding whether and when to shrink an allocation is an additional resource-management policy, with its own allocation and performance tradeoffs.<\/p>\n\n
    \n  \n  \n  3. A rate limiter that never forgets\n<\/h2>\n\n
    GHSA-m2rr-7rr7-vmp7<\/a> \u00b7 Moderate \u00b7 fixed in 0.10.1<\/p>\n\n
    The third finding concerns memory retained while processing handshake traffic. Gotatun counts handshake packets per source IP to help protect against floods. The vulnerable lifecycle allowed entries to accumulate when the device had no known peer endpoints.<\/p>\n\n
    \n  \n  \n  2. An oversized datagram stops reception on Windows\n<\/h2>\n\n
    GHSA-fc57-wfhg-7c2w<\/a> \u00b7 High, CVSS 7.5 \u00b7 fixed in 0.10.0<\/p>\n\n
    This failure starts with a socket error rather than a panic. The affected configuration is the built-in Windows transport without the optional windows-gro<\/code> feature. In the reviewed path, the device supplies a default 4096-byte packet buffer to the buffered receiver.<\/p>\n\n