dnsmasq extract_addresses() RDLEN/RDATA Buffer Overflow — CVE-2026-5172
by lottiedeyan (GitHub); reproduction based on a public writeup by yanyuyingshu (Medium) · 2026-07-05
- Severity
- Not disclosed
- CVE
- CVE-2026-5172
- Category
- network
- Affected product
- dnsmasq (DNS forwarder/resolver)
- Affected versions
- Not disclosed in repo (see upstream dnsmasq advisories for exact affected range)
- Disclosed
- 2026-07-05
- Patch status
- unpatched
References
Archive entry
intelseclab/poc-archiveMetadata
| Field | Value |
|---|---|
| Date Added | 2026-07-05 |
| Last Updated | 2026-05 |
| Author / Researcher | lottiedeyan (GitHub); reproduction based on a public writeup by yanyuyingshu (Medium) |
| CVE / Advisory | CVE-2026-5172 |
| Category | network |
| Severity | Not disclosed |
| CVSS Score | Not disclosed |
| Status | PoC |
| Tags | dnsmasq, dns, buffer-overflow, srv-record, rdlen, upstream-resolver, memory-corruption |
| Related | N/A |
Affected Target
| Field | Value |
|---|---|
| Software / System | dnsmasq (DNS forwarder/resolver) |
| Versions Affected | Not disclosed in repo (see upstream dnsmasq advisories for exact affected range) |
| Language / Platform | Python 3 (PoC harness); target is the C dnsmasq daemon |
| Authentication Required | No |
| Network Access Required | Yes — attacker must be reachable as an upstream/authoritative DNS server that dnsmasq queries |
Summary
The PoC targets extract_addresses() in dnsmasq, which parses resource records (RRs) returned by an upstream DNS server. The function is reported to trust the RR’s declared RDLENGTH field without properly validating it against the actual RDATA bytes present in the reply, leading to a buffer overflow/mismatch condition when a malicious or compromised upstream server returns a crafted answer. This repository provides a minimal, self-contained reproduction harness: a rogue authoritative nameserver (server.py) that replies to any query with a hand-crafted SRV record whose declared RDLENGTH (6) is smaller than its actual RDATA length (8), plus a client (query_client.py) that sends a query to a locally configured dnsmasq instance to trigger the parsing path. A dnsmasq.conf is included to point dnsmasq at the rogue server as its upstream resolver.
Vulnerability Details
Root Cause
extract_addresses() in dnsmasq’s RR-parsing code appears to use the RR’s advertised RDLENGTH field to determine how many bytes of RDATA to consume/copy, without cross-checking that value against the RDATA actually available/consistent with the record type being parsed (e.g., an SRV record’s real content is priority(2)+weight(2)+port(2)+target — at least 8 bytes — while the attacker declares only 6). This rdlen/actual-length mismatch can cause dnsmasq to read or copy the wrong number of bytes when processing the answer, corrupting adjacent memory.
Attack Vector
- Attacker controls or spoofs a DNS server that the victim’s dnsmasq instance queries as an upstream resolver (configured via
server=directive, or via cache-poisoning/MITM if reachable on the query path). - Victim’s dnsmasq (configured per
dnsmasq.conf, forwarding to127.0.0.1#5354in the PoC) sends a query, forwarded to the attacker-controlled nameserver. - The rogue nameserver (
server.py) responds with a crafted SRV answer: owner name compressed pointer, type SRV (33), a declared RDLENGTH of 6, but actual RDATA of 8 bytes (prio/weight/port+ a name-compression pointer to the target). - dnsmasq’s
extract_addresses()parses this RR using the mismatched length field, corrupting internal buffers/heap state. query_client.pyis used to send the original triggering query to dnsmasq and observe the resulting behavior/crash.
Impact
Memory corruption in a privileged, widely-deployed DNS forwarding daemon (dnsmasq runs as root or with elevated privileges on many routers, embedded devices, and Linux distributions), potentially leading to denial of service (crash) or further exploitation depending on heap layout, triggered simply by dnsmasq querying an attacker-influenced or spoofable upstream resolver.
Environment / Lab Setup
Target: dnsmasq daemon configured via the included dnsmasq.conf
(port=5353, forwards queries to 127.0.0.1#5354)
Attacker: Python 3 (no external dependencies — uses only socket/struct/argparse)
Proof of Concept
PoC Script
See
server.py,query_client.py, anddnsmasq.confin this folder.
| |
server.py listens as a standalone UDP “evil” authoritative nameserver and answers any incoming query with a crafted SRV record whose RDLENGTH (6) is smaller than the actual RDATA it embeds (8 bytes). query_client.py builds and sends a minimal raw DNS query directly to the dnsmasq instance, which forwards it upstream to the rogue server per dnsmasq.conf, and prints the header/flags of whatever reply comes back.
Detection & IOCs
Signs of compromise:
- dnsmasq process crashing or restarting shortly after resolving a domain via a specific upstream server
- SRV (or similarly-parsed) DNS responses where the RDLENGTH field does not match the expected minimum size for the record type
- Unexpected
server=upstream entries or DNS forwarding to attacker-controlled resolvers
Remediation
| Action | Detail |
|---|---|
| Primary fix | Upgrade dnsmasq to the version containing the upstream fix for CVE-2026-5172 (validate RDLENGTH against the minimum/expected RDATA size per record type in extract_addresses()) |
| Interim mitigation | Restrict dnsmasq’s upstream server= directives to trusted resolvers only, and avoid exposing dnsmasq’s forwarding path to attacker-influenceable DNS servers |
References
Notes
Mirrored from https://github.com/lottiedeyan/CVE20265172poc on 2026-07-05. Category was reclassified from the suggested “binary” to “network” since the PoC is a client/server DNS-protocol harness targeting dnsmasq’s upstream-response parsing, consistent with how similar network-daemon parsing bugs are catalogued elsewhere in this archive.
| |