CVE-2026-2291
Summary: extractname() tracks name length in wire-format bytes and enforces namelen < MAXDNAME. But three byte values (0x00, 0x2E, 0x01) undergo 2-byte NAMEESCAPE expansion in the presentation format. A wire-format name at the 1024-byte limit can expand to 2031 bytes in presentation format.
The code accounted for this correctly when sizing namebuff -- the comment at option.c:5942 explains the (MAXDNAME 2) + 1 allocation. But union bigname in dnsmasq.h is still sized at MAXDNAME:
c // dnsmasq.h:481 union bigname { char name[MAXDNAME]; // 1025 bytes union bigname next; };
So the strcpy at cache.c:760 can write up to 2031 bytes into a 1025-byte buffer:
c strcpy(cachegetname(new), name); // name comes from daemon->namebuff (2051 bytes)
A DNS response containing 16 labels of 63 NUL bytes (wire length 1024, passes the check) produces a presentation-format string of 2031 bytes -- a 1006-byte overflow.
Trigger A PTR or CNAME response with NUL-byte-filled labels triggers it. NUL bytes in DNS labels are legal per RFC 2181 Section 11, and I confirmed Unbound and BIND forward them without sanitization. No special dnsmasq configuration is needed.
Impact - Crash: A single malicious DNS response corrupts heap metadata. ASAN reports WRITE of size 2032 at cache.c:760. Release builds crash on subsequent operations (malloc(): corrupted top size).
- Cache poisoning: The overflow can overwrite an adjacent bigname.name[] with a target domain string, causing cachefindbyname() to match the target domain against an entry with the attacker's IP. The crec metadata is untouched -- only the name changes. This bypasses TXID/port randomization since the attacker is the legitimate authoritative server for their own zone.
Affected Versions The NAMEESCAPE expansion was introduced in commit cbe379a (2015-04-21, "Handle domain names with '.' or /000 within labels"), first released in v2.73. That same commit upsized namebuff to MAXDNAME 2 with an explicit comment about the 2x expansion -- but union bigname was not updated. From v2.73 through v2.89, the expansion only ran in DNSSEC-enabled builds.
In commit 638c7c4 (2023-03-23, "Add --cache-rr to enable caching of arbitrary RR types"), released in v2.90, the NAMEESCAPE expansion was made unconditional -- it now runs in all builds regardless of DNSSEC configuration. The namebuff allocation was moved to readopts() and unconditionally sized at (MAXDNAME 2) + 1.
- v2.73 -- v2.89: Vulnerable in DNSSEC-enabled builds only. - v2.90 -- v2.92 (current): Vulnerable in all builds, all configurations.
ASAN Output Built v2.92 at d8f66f4 with -fsanitize=address -g -O0. Triggered via a single PTR response containing 16 labels of 63 NUL bytes:
==3387188==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x519000001888 WRITE of size 2032 at 0x519000001888 thread T0 #0 strcpy #1 reallyinsert cache.c:760 #2 cacheinsert cache.c:626 #3 extractaddresses rfc1035.c:770 #4 processreply forward.c:824 #5 returnreply forward.c:1426 #6 replyquery forward.c:1298 #7 checkdnslisteners dnsmasq.c:1905 #8 main dnsmasq.c:1297
0x519000001888 is located 0 bytes after 1032-byte region [0x519000001480,0x519000001888) allocated by thread T0 here: #0 calloc #1 whinemalloc util.c:346 #2 reallyinsert cache.c:731
Patch Tested against v2.92 (d8f66f4): ASAN build survives the same payload that previously triggered the overflow. Applicable with git am:
A flow has been identified into dnssec.c library, causing an infinite loop to dnsmasq service. An attacker who controls any DNSSEC-signed zone can hang the dnsmasq process with a single crafted response, killing all DNS resolution for its clients.
A heap-based out-of-bounds read vulnerability in the DNSSEC validation of dnsmasq allows remote attackers to cause a denial of service via a crafted DNS packet.
A heap-based out-of-bounds write vulnerability in the DHCPv6 implementation of dnsmasq allows local attackers to execute arbitrary code with root privileges via a crafted DHCPv6 packet.
A Denial of Service (DoS) vulnerability in the DNSSEC validation of dnsmasq allows remote attackers to cause a denial of service via a crafted DNS packet.
An information disclosure vulnerability in dnsmasq allows remote attackers to bypass source checks via a crafted DNS packet with RFC 7871 client subnet information.
On 5/11/26 11:11, Alan Coopersmith wrote: CVE-2026-2291 dnsmasq's extractname() function can be abused to cause a heap buffer overflow, enabling an attacker to inject false DNS cache entries. This could cause DNS queries to be redirected to attacker-controlled IP addresses or result in a Denial of Service (DoS). Further info on this CVE has been posted now by a researcher: https://blog.exodusintel.com/2026/07/20/dnsmasq-dns-remote-heap-buffer-overflow/
"We cover the technical analysis of the vulnerability and how we exploited it to gain remote code execution on a OpenWRT target that is configured with a malicious upstream DNS server."
-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
A heap buffer overflow exists in dnsmasq's logquery() function (src/cache.c). When query logging is enabled and dnsmasq logs DS or DNSKEY replies containing unsupported algorithm or digest types, the "(not supported)" suffix causes sprintf() to write past the end of daemon->addrbuff, a 46-byte heap buffer. Trigger example: a DS record with keytag=65535, algorithm=255, digesttype=255 (both algorithm 255 and digesttype 255 are IANA-unassigned), causing the "(not supported)" branch in dnssec.c to fire during logging. Prerequisites: - DNSSEC validation enabled - Query logging enabled (e.g. --log-queries) Impact: bounded heap write overflow (~12 bytes). Upstream maintainer Simon Kelley notes the overwrite is of bounded length, the bytes written are not attacker-controlled, and this is not considered a likely remote-execution vector. Practical impact is denial of service via process crash or heap corruption. Fixed upstream in commit 36d081e37477027fd721fea498f3760f529034ad (dnsmasq 2.92rel2).
A heap buffer overflow exists in dnsmasq's logquery() function (src/cache.c). When query logging is enabled and dnsmasq logs DS or DNSKEY replies containing unsupported algorithm or digest types, the "(not supported)" suffix causes sprintf() to write past the end of daemon->addrbuff, a 46-byte heap buffer. Trigger example: a DS record with keytag=65535, algorithm=255, digesttype=255 (both algorithm 255 and digesttype 255 are IANA-unassigned), causing the "(not supported)" branch in dnssec.c to fire during logging. Prerequisites: - DNSSEC validation enabled - Query logging enabled (e.g. --log-queries) Impact: bounded heap write overflow (~12 bytes). Upstream maintainer Simon Kelley notes the overwrite is of bounded length, the bytes written are not attacker-controlled, and this is not considered a likely remote-execution vector. Practical impact is denial of service via process crash or heap corruption. Fixed upstream in commit 36d081e37477027fd721fea498f3760f529034ad (dnsmasq 2.92rel2).
A buffer overflow in dnsmasq’s extractaddresses() function allows an attacker to trigger a heap out-of-bounds read and crash by exploiting a malformed DNS response, enabling extractname() to advance the pointer past the record’s end.
An out-of-bounds read vulnerability exists in dnsmasq's findsoa() function in src/rfc1035.c. When parsing NS section records, extractname() is called with extrabytes=0, failing to validate that 10 additional bytes exist for fixed-length DNS record fields. A remote attacker controlling a DNS zone can exploit this via a crafted NXDOMAIN response to cause a 10-byte heap out-of-bounds read, potentially accessing stale data from prior transactions.
An out-of-bounds read vulnerability was found in dnsmasq's findsoa() function in src/rfc1035.c. The function calls extractname() with extrabytes=0 when parsing NS section records in NXDOMAIN/NODATA responses, which only validates that the DNS name fits within the packet but does not verify that 10 additional bytes exist for the fixed-length fields (type, class, TTL, rdlen). The subsequent GETSHORT/GETLONG macros then unconditionally read 10 bytes past the valid packet boundary.
An attacker controlling a DNS zone can trigger this by returning a crafted NXDOMAIN response where the NS record name (a compression pointer) extends to the packet boundary. The 10-byte over-read typically stays within dnsmasq's over-allocated packet buffer (headroom of 1035 bytes), limiting crash risk, but accesses data outside the logical packet boundary and may read stale heap data from prior DNS transactions.
Upstream fix: https://repo.or.cz/dnsmasq.mirror.git/commit/14094e88beca519c53151184cc4553656672b54f Fixed in: dnsmasq 2.93rc1
A flaw was found in dnsmasq. A remote attacker could exploit an out-of-bounds write vulnerability by sending a specially crafted BOOTREPLY (Bootstrap Protocol Reply) packet to a dnsmasq server configured with the --dhcp-split-relay option. This can lead to memory corruption, causing the dnsmasq daemon to crash and resulting in a denial of service (DoS).
Alan Coopersmith <alan.coopersmith () oracle com> writes: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2026q2/018471.html announces: Today, 11th May 2026 CERT is releasing a set of six CVEs for serious security vulnerabilities in dnsmasq. These are all long-standing bugs which apply to pretty much all non-ancient versions. The CVE has been pre-disclosed to vendors, so hopefully they will be releasing patched versions of their dnsmasq packages in a timely manner. Details and patches are available on the website at https://thekelleys.org.uk/dnsmasq/CVE/ and I have made "2.92rel2" release of the current 2.92 dnsmasq stable release which is downloadable from the usual place and has had these patches applied.
[...]
Thank you to the reporters for discovering these vulnerabilities: Hugo Martinez (hugomray () gmail com) - CVE-2026-5172, CVE-2026-2291 Andrew Fasano (NIST) - CVE-2026-2291 Royce M (royce () xchglabs com) - CVE-2026-4893, CVE-2026-4892, CVE-2026-4891, CVE-2026-4890, CVE-2026-2291 Writeup for these 5 is available at https://xchglabs.com/blog/dnsmasq-five-cves.html Asim Viladi Oglu Manizada - CVE-2026-4892 Mattia Ricciardi (mindless) - CVE-2026-2291
On 5/11/26 11:11, Alan Coopersmith wrote:
https://www.kb.cert.org/vuls/id/471747 provides additional details: dnsmasq has released version 2.93 to fix the above vulnerabilities, and various vendors have published patches to address individual remediations. CERT has now corrected their advisory to list version 2.92rel2 as well.
-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Details and patches are available on the website at
https://thekelleys.org.uk/dnsmasq/CVE/
Simon. https://www.kb.cert.org/vuls/id/471747 provides additional details: dnsmasq contains several vulnerabilities, including attacker DNS redirect, privilege escalation, and heap manipulation
Vulnerability Note VU#471747 Original Release Date: 2026-05-11 | Last Revised: 2026-05-11
Overview -------- dnsmasq is affected by multiple memory safety and input validation vulnerabilities, including heap buffer overflows, heap corruption, and code execution flaws. Collectively, these vulnerabilities enable attackers to poison cached DNS records, bypass security controls, crash the dnsmasq process, or under certain conditions, achieve local privilege escalation.
Description -----------
dnsmasq is an open-source networking tool that provides DNS forwarding, DHCP, and network boot services for small-to-medium sized networks and home routing devices. It can also function as a DNS resolver, which is the primary exploitation use case for several of the vulnerabilities described below, tracked collectively as CVE-2026-2291, CVE-2026-4890, CVE-2026-4891, CVE-2026-4892, CVE-2026-4893, and CVE-2026-5172.
CVE-2026-2291 dnsmasq's extractname() function can be abused to cause a heap buffer overflow, enabling an attacker to inject false DNS cache entries. This could cause DNS queries to be redirected to attacker-controlled IP addresses or result in a Denial of Service (DoS).
CVE-2026-4890 An infinite-loop flaw in the DNSSEC validation of dnsmasq allows remote attackers to cause Denial of Service (DoS) conditions via a crafted DNS packet.
CVE-2026-4891 A heap-based out-of-bounds read vulnerability in the DNSSEC validation of dnsmasq allows remote attackers to leak memory information via a crafted DNS packet.
CVE-2026-4892 A heap-based out-of-bounds write vulnerability in the DHCPv6 implementation of dnsmasq allows local attackers to execute arbitrary code with root privileges via a crafted DHCPv6 packet.
CVE-2026-4893 An information disclosure vulnerability in dnsmasq allows remote attackers to bypass source checks via a crafted DNS packet containing RFC 7871 client-subnet information.
CVE-2026-5172 A buffer overflow vulnerability in dnsmasq’s extractaddresses() function allows attackers to trigger a heap out-of-bounds read and crash dnsmasq by exploiting a malformed DNS response.
Impact ------
These vulnerabilities collectively pose various risks:
DoS (CVE-2026-2291, CVE-2026-4890, CVE-2026-5172) — dnsmasq may crash or become unresponsive, terminating DNS resolution and affecting dependent services.
Cache Poisoning / Redirection (CVE-2026-2291, CVE-2026-4893) — Attackers may overwrite cache entries or manipulate response routing, enabling the silent redirection of users to malicious domains.
Information Disclosure (CVE-2026-4891, CVE-2026-4893) — Internal memory and network information may be inadvertently exposed.
Local Privilege Escalation (CVE-2026-4892) — A local attacker may execute arbitrary code as root via DHCPv6 manipulation.
Solution --------
dnsmasq has released version 2.93 to fix the above vulnerabilities, and various vendors have published patches to address individual remediations. A full list of affected vendors and vendor patches can be found in the References section below. This note, as well as the CVE listings, will be updated as additional patches become available.
Acknowledgements ----------------
Thank you to the reporters for discovering these vulnerabilities: Hugo Martinez (hugomray () gmail com) - CVE-2026-5172, CVE-2026-2291 Andrew Fasano (NIST) - CVE-2026-2291 Royce M (royce () xchglabs com) - CVE-2026-4893, CVE-2026-4892, CVE-2026-4891, CVE-2026-4890, CVE-2026-2291 Asim Viladi Oglu Manizada - CVE-2026-4892 Mattia Ricciardi (mindless) - CVE-2026-2291 -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
On dnsmasq 2.92, a server-facing BOOTREPLY processed under --dhcp-split-relay can place OPTIONAGENTID at the end of a 552-byte packet and make dnsmasq zero one byte past the receive buffer. In my PoC, a benign 552-byte BOOTREPLY leaves the daemon alive, while the malicious variant followed by one oversized BOOTREPLY aborts the normal build with malloc(): invalid next size (unsorted). The attached PoC also reproduces the direct AddressSanitizer report at src/rfc2131.c:3251.
Details The bug is in src/rfc2131.c:3249-3251. After finding OPTIONAGENTID, dnsmasq sets opt = OPTIONEND and then executes memset(opt + 1, 0, optionlen(opt) + 2). The attached PoC uses the smallest RFC 3046-conformant Agent Information option: OPTIONAGENTID, length 2, followed by one zero-length sub-option (01 00). When that option starts at byte 548 of a 552-byte BOOTREPLY, memset(opt + 1, 0, 4) clears bytes 549..552, so the last byte is still written one byte past the end of the packet buffer. The buffer is exact-size because recvdhcppacket() grows the receive iovec to the packet length in src/dhcp-common.c:54-64, and expandbuf() reallocates that exact size in src/util.c:703-716.
Dnsmasq before 2.21 allows remote attackers to poison the DNS cache via answers to queries that were not made by Dnsmasq.
Off-by-one buffer overflow in Dnsmasq before 2.21 may allow attackers to execute arbitrary code via the DHCP lease file.
Dnsmasq 2.29 allows remote attackers to cause a denial of service (application crash) via a DHCP client broadcast reply request.