DEV Community: zerox80

Before authentication: three bugs in Mullvad's gotatun

zerox80 — Thu, 05 Nov 2026 20:10:45 +0000

WireGuard is known for staying silent towards packets it can't authenticate. But a userspace implementation has to receive a UDP datagram before it can decide whether to ignore it. That receive path is attack surface too.

I found three bugs there in gotatun, Mullvad's userspace WireGuard implementation in Rust. All three trigger before WireGuard authentication, and all three are fixed.

1. An empty datagram kills the Linux receive task

GHSA-6gxq-8xp9-742r · High (CVSS 7.5) · fixed in 0.10.1

On Linux, gotatun receives datagrams in batches with recvmmsg. For each result it took the payload like this:

result.iovs().next().expect("we create exactly one IoSlice")

For an empty datagram, the iterator returns None, and expect panics. That panic ends the receive task that all peers on the device share. One zero-length UDP datagram to the listening port, and inbound traffic stops for every peer until the device is restarted or reconfigured. No peer key or secret is needed.

Takeaway: an empty UDP datagram is perfectly legal. "This can't happen" in a receive path is a denial of service waiting for someone to send zero bytes.

2. An oversized datagram stops reception on Windows

GHSA-fc57-wfhg-7c2w · High (CVSS 7.5) · fixed in 0.10.0

On Windows without the optional windows-gro feature, gotatun receives into a 4096-byte buffer. If a datagram is larger, Windows returns WSAEMSGSIZE (10040). The socket itself is fine after that, the next receive works.

But gotatun passed the error up. The buffered receive task exited, and once the queued packets drained, the receive loop ended. It ended with Ok(()), so nothing registered a fatal error and nothing restarted reception.

I tested this on native Windows 11 with two connected devices over loopback. After a single 8192-byte datagram, the unpatched device did not deliver the next packet within five seconds. With my patch, traffic kept flowing in both directions. The patch was part of my report. It discards datagrams that fail with WSAEMSGSIZE and keeps receiving:

match self.socket().recv_from(&mut buf).await {
    Ok((n, src)) => { /* deliver the datagram */ }
    // The socket is still usable; skip the oversized datagram.
    Err(err) if err.raw_os_error() == Some(WinSock::WSAEMSGSIZE) => {
        tokio::task::yield_now().await;
    }
    Err(err) => return Err(err),
}

Takeaway: an error that is harmless for the socket was fatal for the task. And a task that exits with Ok(()) after failing is worse than one that crashes, because nobody notices.

3. A rate limiter that never forgets

GHSA-m2rr-7rr7-vmp7 · Medium · fixed in 0.10.1

To protect against handshake floods, gotatun counts handshake packets per source IP. A packet only gets counted if its MAC1 is valid. But the MAC1 key is derived from the device's public key, so anyone who knows the public key can produce valid MAC1 values.

The counters are cleared from the peer timer loop. That loop skips peers without an endpoint. If no peer has an endpoint, the cleanup never runs, and every new source IP adds an entry. On top of that, HashMap::clear() keeps the allocated capacity, so even a reset doesn't give the memory back.

This one needs traffic from many different source IPs, so network filtering and anti-spoofing make it much harder. It is rated Medium.

Takeaway: cleanup that depends on an unrelated condition will eventually not run. And clear() empties a map, it doesn't shrink it.

What they have in common

All three happen before the packet reaches authentication. A quick checklist for any UDP service:

What happens with a 0-byte datagram?
What happens with a datagram larger than my buffer?
What happens if a million different source IPs send me one packet each?

If you use gotatun, update to 0.10.1 or later.

Thanks to the Mullvad team for the quick fixes and the advisories.

Two ways to stall quinn, Rust's QUIC library

zerox80 — Thu, 05 Nov 2026 20:10:34 +0000

quinn is a popular QUIC implementation in Rust. I reported two denial-of-service bugs to the maintainers, both are fixed. One lives in the UDP layer below QUIC, the other in how quinn handles a peer's transport parameters.

1. recv_single() spins after a truncated datagram

GHSA-6pp4-4cxf-xf88 · High · quinn-udp, fixed in 0.5.16 and 0.6.3

recv_single is the Unix fallback that receives one datagram per recvmsg call. It is used on OpenBSD and some other Unix and Apple configurations. The normal Linux batched path and Windows use different code.

Two details combined into a loop:

The code checked the MSG_TRUNC flag before checking whether recvmsg had failed.
The msghdr was initialized only once, so its flags survived from one call to the next.

So after a datagram that was too big for the buffer, the next call returned EAGAIN, but the old MSG_TRUNC flag was still set. The code treated that as "another truncated datagram, discard and try again" instead of returning WouldBlock. The endpoint's runtime thread kept calling recvmsg until a normal datagram happened to arrive. All of this happens before any QUIC packet authentication.

The fix I proposed returns errors before looking at the flags and re-initializes the header before every syscall.

I reproduced it with a localhost regression test that calls recv_single directly with a 16-byte datagram and an 8-byte buffer. The test fails before the fix and passes after it. I checked the OpenBSD kernel source for the relevant semantics but did not run it on native OpenBSD.

Takeaway: check the return value before you read output parameters. And if a struct is both input and output for a syscall, reset it before each call.

2. A peer can make clamp() panic

GHSA-3g6h-r5qx-f6hq / RUSTSEC-2026-0340 · High (CVSS 7.5) · quinn-proto, fixed in 0.11.18

Duration::clamp(min, max) panics if min > max. quinn uses it to compute the ACK delay when sending ACK_FREQUENCY frames, with a lower bound that comes from the peer's min_ack_delay transport parameter.

A peer could send min_ack_delay = 100 ms together with max_ack_delay = 100 ms. Both pass validation. At an RTT of 5 ms, the upper bound is max(5 ms, 25 ms) = 25 ms, which is lower than the 100 ms lower bound. A minimal illustration:

use std::time::Duration;

let lower = Duration::from_millis(100); // from the peer's min_ack_delay
let upper = Duration::from_millis(25);  // max(rtt, 25 ms) at a 5 ms RTT
let _ = Duration::from_millis(50).clamp(lower, upper); // panics: min > max

This only affects connections where sending ACK_FREQUENCY is enabled with TransportConfig::ack_frequency_config(Some(...)), which is off by default. Whether the panic takes down the whole process depends on how the application handles panics, I did not verify a process-wide crash.

Takeaway: clamp has a precondition. If either bound comes from the network, check the relation between the bounds, not just each value on its own.

Updating

quinn-udp: 0.5.16 or 0.6.3 and later
quinn-proto: 0.11.18 and later

Thanks to the quinn maintainers for the fixes and the credit in the advisories.

My toxic relationship with Meta's bug bounty program

zerox80 — Thu, 05 Nov 2026 19:26:27 +0000

Update, Nov 5 (evening): A few hours after I published this, Meta's bug bounty team reached me by email. They had replied before, but a bug in their platform kept those messages from reaching me. The report is confirmed and resolved and is waiting for a bounty decision. They can't help with the Facebook account, but we can now talk by email. So less ghosting than it looked like, more of a broken mailbox.

Every relationship starts with good intentions. On October 9, I created my first Facebook account for one reason: to report a security bug to Meta.

Within about two hours, the account was permanently disabled. I did the video selfie verification they asked for. That felt fast for a relationship that was two hours old. My appeal was rejected anyway.

Here is the catch: Meta's bug bounty portal sends you through Facebook to open a report. I can see that my report exists. I just can't open it, answer questions or add evidence.

I don't think anybody did this on purpose. To me it looks like an automated false positive: brand new account, no history, and the only thing it ever did was file a security report.

How it went

Oct 9: I submit the report and lose the account. I email security@ and bugbounty@. No reply reaches me.
Oct 13: I open a public GitHub issue, without technical details, asking how to reach the team.
Oct 24: Day 15. I ping the maintainers. One of them answers the same day and asks me to email the details. The report now shows as "Triaged".
Oct 25: The fix lands in mvfst.
Oct 26: A Meta engineer confirms by email that the fix came from my report and says the bug bounty team will reach out.
Nov 3: CERT-Bund, Germany's national CERT, forwards my request to Meta. They take no position on the account or the bounty. So yes, we have reached the stage where a federal agency passes notes between us.
Nov 5: A few hours after this post went up, the bug bounty team reaches me by email. Their earlier replies had been lost to a delivery bug on their side.

To be fair, the people who write the code were great. Two engineers on the mvfst team answered a stranger's ping and took it seriously. The silence turned out to be a process problem, not a people problem.

The bug

mvfst is Meta's open source QUIC implementation. QUIC has a packet called Retry, which arrives before the handshake and carries a 16-byte integrity tag. RFC 9001 says what the tag is for: only someone who has seen the client's Initial packet should be able to send a valid Retry.

mvfst computed that tag correctly. Then it ignored the answer.

// verifyRetryIntegrityTag returns Expected<bool, QuicError>
if (!clientConn_->clientHandshakeLayer->verifyRetryIntegrityTag(
        *originalDstConnId, *retryPacket)) {
  // drop the packet
}

With a bad tag, the function returns a successful Expected that contains false. But !expected asks "is there an error?", not "is the value false?". So the drop branch never ran for a bad tag.

The existing unit test made the same mistake. EXPECT_TRUE(verifyRetryIntegrityTag(...)) passes for both true and false.

The result: the client accepted a Retry with any tag, took the attacker's connection ID and token, reset its state and restarted the handshake.

What it actually means

The attacker here is blind and off-path. They have to spoof the server's address, know the client's IP and UDP port, and land one datagram in a short window during connection setup. That is a real hurdle. An attacker who is on the path gains nothing from this bug, because they can compute a valid tag anyway.

I tested it with mvfst's own echo client and server over real UDP on my own machine, using a Retry with an all-zero tag:

QUIC v1: the connection attempt fails with TRANSPORT_PARAMETER_ERROR.
mvfst's own version (0xfaceb002, the client default): the handshake completes with the attacker's connection ID and token, and no error is raised.
With the fix: the Retry is dropped and the connection completes normally.

What I did not do: send this over the internet, test any Meta system, or check current Facebook or Instagram app builds. The attacker does not get the handshake or application keys. My own rating is Medium (CVSS 6.5). Meta's rating? See above, I can't open the report.

The fix

auto integrityResult =
    clientConn_->clientHandshakeLayer->verifyRetryIntegrityTag(
        *originalDstConnId, *retryPacket);
if (!integrityResult.has_value() || !*integrityResult) {
  // drop the packet
}

If you embed the mvfst client, use v2026.10.26.00 or later.

What I took away

Expected<bool, E> has two kinds of "no". If you only need yes or no, return bool. If you only need success or error, return Expected<void, E>.
A test that never sees bad input doesn't test validation. The bug survived because nothing ever fed the check a wrong tag and looked at the result.
A social media account should not be the only door to a security report. When automation closes that door, researchers need another way in.

Where we stand

The bug is fixed, and that matters most. The report is confirmed and resolved, and the bounty decision is pending. Thanks to the mvfst engineers, to CERT-Bund, and to the bug bounty team for following up.

The Facebook account is still gone, and the security team can't help with that. If you're new to Meta's program, expect a brand-new Facebook account to get flagged, and keep a second channel like email or a coordinator open.

Meta, it was partly your mailbox after all. Your account integrity system and I still need to talk, though.