| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| github.com/coredns/coredns | go | < 1.21.2 | 1.21.2 |
The vulnerability described is a Denial of Service (DoS) in CoreDNS's DNS-over-QUIC (DoQ) server, caused by uncontrolled memory consumption due to an unlimited number of goroutines being created for incoming QUIC streams. The analysis of the provided patch (commit efaed02c6a480ec147b1f799aab7cf815b17dfe1) pinpoints the vulnerable behavior to the serveQUICConnection method in core/dnsserver/server_quic.go.
In the vulnerable code, serveQUICConnection would accept a new QUIC connection and then, in a loop, accept streams on that connection. For each stream, it directly launched a new goroutine using go s.serveQUICStream(stream, conn). This 1:1 mapping of stream to goroutine, without any cap on the total number of goroutines, is the root cause of the memory exhaustion vulnerability. An attacker could establish a QUIC connection and then open a very large number of streams, each triggering the creation of a new goroutine, eventually overwhelming the server's memory resources.
The patch mitigates this by introducing two main changes visible in serveQUICConnection and its setup in NewServerQUIC:
streamProcessPool) is introduced. Now, instead of directly spawning a goroutine, serveQUICConnection attempts to acquire a worker from this pool before launching the goroutine. This limits the total number of concurrently running serveQUICStream goroutines across all connections.maxStreams) is also introduced, configured in NewServerQUIC and applied to the quic.Config. While this helps, the primary defense against goroutine exhaustion is the worker pool.The function (*ServerQUIC).serveQUICConnection is therefore identified as the vulnerable function because it contained the logic that directly led to the unbounded creation of goroutines based on attacker-controlled input (number of streams). During exploitation, this function would be actively creating these goroutines, and its activity (or the subsequent OOM) would be a key indicator.
The function NewServerQUIC was modified to initialize these new limiting mechanisms, and is the function executed by each goroutine. However, the vulnerability—the act of creating too many goroutines—resides in .
serveQUICStreamserveQUICConnectionOngoing coverage of React2Shell