Unratedcrates.ioPublished
Receive loop can spin after a truncated datagram
GHSA-6pp4-4cxf-xf88
- Affected
- crates.io quinn-udp >= 0.0.0-0, < 0.5.16; >= 0.6.0, < 0.6.3
- Fixed in
- 0.5.160.6.3· Vendor fix available
- Issue
- Some targets read one datagram per `recvmsg` call instead of using `recvmmsg`: Apple platforms without the `fast-apple-datapath` feature, OpenBSD, NetBSD, Solaris and illumos, and from 0.6 also DragonFly BSD, Redox and GNU/Hurd. On these targets the receive loop set up its `msghdr` only once and looked at the `MSG_TRUNC` flag before checking whether `recvmsg` had failed. After a datagram larger than the receive buffer was dropped, a following `EAGAIN` still saw the old truncation flag. The loop then kept issuing non-blocking receives instead of returning `WouldBlock`. When the receive buffer is smaller than a datagram that arrives, a remote sender can keep the task that drives the socket busy, before any QUIC packet authentication. The loop ends only when a later datagram fits in the buffer. Whether an application is exposed therefore depends on the receive buffer size it uses. Linux, Android, FreeBSD and Windows use other receive paths and are not affected. The fix rebuilds the…
Recommended action: Upgrade to 0.6.3 or 0.5.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.