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.

Rejected reason: REJECT DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: Based on the analysis by MITRE and review of community feedback, the reported conditions represent expected and intentional behavior within dnsmasq's documented design, rather than security vulnerabilities.

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).

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 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.

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.

Dnsmasq before 2.21 allows remote attackers to poison the DNS cache via answers to queries that were not made by Dnsmasq.

CVE-2026-2291

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).

An information disclosure vulnerability in dnsmasq allows remote attackers to bypass source checks via a crafted DNS packet with RFC 7871 client subnet information.

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.

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.

Rejected reason: REJECT DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: Based on the analysis by MITRE and review of community feedback, the reported conditions represent expected and intentional behavior within dnsmasq's documented design, rather than security vulnerabilities.

Rejected reason: REJECT DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: Based on the analysis by MITRE and review of community feedback, the reported conditions represent expected and intentional behavior within dnsmasq's documented design, rather than security vulnerabilities.

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.

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.

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 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).

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

Description of problem: On my workstation, as a virtual machine host, I have NetworkManager's dnsmasq configured to forward DNS queries for a local domain to 192.168.122.1, so I can resolve those to virtual machine DHCP hostnames. Recently this stopped working.

With manual dig commands, I found that TCP queries still work, but UDP doesn't. For example, in libvirt I have a statically defined name "vhost" to 192.168.122.1 itself. From the host, the command "dig +short +tcp @192.168.122.1 vhost" resolves that just fine. But "dig +short +notcp @192.168.122.1 vhost" says "connection timed out; no servers could be reached". From a guest, +tcp and +notcp both work fine.

Version-Release number of selected component (if applicable): libvirt-0.9.11.8-2.fc17.x8664, dnsmasq-2.63-1.fc17.x8664 I also tried dnsmasq-2.65-1.fc17.x8664 from updates-testing

How reproducible: 100%

Steps to Reproduce: 1. From the virtual machine host, try to query the libvirt dnsmasq. Actual results: $ dig +short +tcp @192.168.122.1 vhost 192.168.122.1 $ dig +short +notcp @192.168.122.1 vhost ;; connection timed out; no servers could be reached

Expected results: A positive answer from both TCP and UDP queries.

Additional info: I suspect this is related to the fixes for CVE-2012-3411, but it seems weird that UDP and TCP would be treated differently.

It's not great that we're adding to a thread on Unbound, but since we already started...

On Tue, Feb 13, 2024 at 10:52:09PM +0100, Solar Designer wrote: On Tue, Feb 13, 2024 at 12:06:42PM -0800, Alan Coopersmith wrote: On 2/13/24 06:07, Yorgos Thessalonikefs wrote: DNSSEC protocol vulnerabilities have been discovered that render various DNSSEC validators victims of Denial Of Service while trying to validate specially crafted DNSSEC responses.

There are two known vulnerabilities: CVE-2023-50387 (referred here as the KeyTrap vulnerability) and CVE-2023-50868 (referred here as the NSEC3 vulnerability). Similarly, dnsmasq 2.90 was published today to address these: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2024q1/017430.html And fixes for these two CVEs were merged into PowerDNS today:

https://github.com/PowerDNS/pdns/pull/13781 There are also three PRs (13782, 13783, 13784) with back-ports to other supported branches. I hope PowerDNS will also be sending a proper advisory in here. Turns out there is a PowerDNS advisory here:

https://blog.powerdns.com/2024/02/13/powerdns-recursor-4-8-6-4-9-3-5-0-2-released

but really it should be posted to oss-security as well.

Alexander

On Tue, Feb 13, 2024 at 12:06:42PM -0800, Alan Coopersmith wrote: On 2/13/24 06:07, Yorgos Thessalonikefs wrote: DNSSEC protocol vulnerabilities have been discovered that render various DNSSEC validators victims of Denial Of Service while trying to validate specially crafted DNSSEC responses.

There are two known vulnerabilities: CVE-2023-50387 (referred here as the KeyTrap vulnerability) and CVE-2023-50868 (referred here as the NSEC3 vulnerability). Similarly, dnsmasq 2.90 was published today to address these: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2024q1/017430.html And fixes for these two CVEs were merged into PowerDNS today:

https://github.com/PowerDNS/pdns/pull/13781

I hope PowerDNS will also be sending a proper advisory in here.

Alexander

Hi Sebastian,

On 10/27/25 13:40, Sebastian Pipping wrote: Hello Stuart,

On 10/27/25 20:45, Stuart Henderson wrote: On 2025/10/27 19:51, Sebastian Pipping wrote: Also, fixes without a CVE will not be backported downstream. That depends on the downstream. I'm happy to learn which downstreams backport security issues without a CVE, in practice. Do you have an example or two?

³ E.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075904

On Mon, Oct 27, 2025 at 09:37:03PM -0400, Demi Marie Obenour wrote: instance, I suspect that OPNsense generates dnsmasq and Unbound configuration files from data provided in the web UI. And OpenWRT. Definitely. Not sure how much validation there is.

-- Ian

On 10/27/25 4:40 PM, Sebastian Pipping wrote: Hello Stuart,

On 10/27/25 20:45, Stuart Henderson wrote: On 2025/10/27 19:51, Sebastian Pipping wrote: Also, fixes without a CVE will not be backported downstream. That depends on the downstream. I'm happy to learn which downstreams backport security issues without a CVE, in practice. Do you have an example or two?

Thanks and best

Sebastian Hello,

There is a Linux distro you may not be aware of called "Gentoo" that does this all the time. :) (Fun fact: there's a Gentoo Developer with the same last name as you.)

In general, the security team is quite happy to backport an issue upstream claims is important, even if for example they requested a CVE but haven't gotten one yet. Conversely, if upstream swears up and down that the CVE is bogus and the patch shouldn't be backported (or the patch is rejected), then Gentoo Security is unlikely to backport it, and probably nobody else would either.

The point of a CVE isn't to "prove" that something is a vulnerability. The point of a CVE is to raise awareness of a vulnerability by getting everyone to talk about it using the same machine-readable name. The distinction isn't an accident.

-- Eli Schwartz

On Mon, 27 Oct 2025 at 19:26:47 -0700, nightmare.yeah27 () aceecat org wrote: On Mon, Oct 27, 2025 at 09:37:03PM -0400, Demi Marie Obenour wrote: I suspect that OPNsense generates dnsmasq and Unbound configuration files from data provided in the web UI. And OpenWRT. Definitely. Not sure how much validation there is.

smcv

On 10/27/25 09:34, Alan Coopersmith wrote: Among the new CVE's published this weekend were these from the VulDB CNA:

CVE-2025-12198

A vulnerability has been found in dnsmasq up to 2.73rc6. Affected is the [...] CVE-2025-12199

A vulnerability was found in dnsmasq up to 2.73rc6. Affected by this [...] CVE-2025-12200

A vulnerability was determined in dnsmasq up to 2.73rc6. Affected by this [...]

The folks on the dnsmasq mailing list also pointed out the version claimed is a release candidate from 10 years ago, not anything current:

https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2025q4/018338.html

(The current stable release of dnsmasq is version 2.91 from March of this year.)

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Hi,

On Mon, Oct 27, 2025 at 09:40:35PM +0100, Sebastian Pipping wrote: Hello Stuart,

On 10/27/25 20:45, Stuart Henderson wrote: On 2025/10/27 19:51, Sebastian Pipping wrote: Also, fixes without a CVE will not be backported downstream. That depends on the downstream. I'm happy to learn which downstreams backport security issues without a CVE, in practice. Do you have an example or two? Another very recent example is https://lists.debian.org/debian-security-announce/2025/msg00200.html

It is about: https://discuss.tryton.org/t/security-release-for-issue-14290/8895 https://foss.heptapod.net/tryton/tryton/-/issues/14290

While it would be nice that a identifier exists for this issue (has not yet happend), this was not blocking doing an update.

Regards, Salvatore

Demi Marie Obenour <demiobenour () gmail com> writes: On 11/1/25 15:35, Russ Allbery wrote:

This is a bit of an "ask the Lazyweb" question since I have done only minimal research, but is there any way for me to declare, as the software maintainer, what I consider to be the security boundaries of the software in a way that can be at least partially machine-readable? I know there are tons of modeling languages for building software, imposing or checking access control, etc., but is there a way for me to label a free software project to communicate information such as "edit access to the configuration file is arbitrary code execution by design"?

Even this gets tricky. For instance, it is trivially unsafe to pass untrusted input to a shell without properly escaping it first. However, if the untrusted input is properly escaped, then it is the shell's job to process the data correctly. The same goes for kernel command lines in libvirt XML configurations, SaltStack reactor YAML, Vim script command arguments, and almost certainly many, many more situations that I am not even aware of. Certainly, I'm simplifying. Developing some sort of language to talk about this is more than an afternoon with a Markdown editor. But at least in theory, it feels like it should be possible to say things like that in some sort of structured way.

untrusted-input: unsafe untrusted-input: if-escaped untrusted-input: safe

Obviously this is massively oversimplified, needs more thought than a lazy Saturday afternoon in an email message, and humans will probably still need to interpret it. I very much doubt you can describe these things in a way that's truly unambiguous.

But even that very simple example is somewhat helpful, no? If the program declares "untrusted-input: unsafe" and you get a CVE submission complaining about the escaping mechanism not working, well, the maintainer said right there in black and white that they don't intend for that to be a safe operation even with escaping, so go talk to the maintainer if that makes you unhappy, but this is probably not a CVE.

It's an interesting point that bash's policy is more like "if-escaped", although honestly bash is probably just a bad example and there should be some entirely separate option like "interpreter" to capture the case that the input is interpreted as a program in some programming language with properties way too complicated to capture in this sort of mechanism.

Anyway, I don't mean to try to hash out the details of such a language here because all the points you're raising are good ones and this is exactly why I was wondering if someone has already done the work to think through all of this. :) In the dnsmasq case, it definitely isn't okay to pass a fully untrusted config file. However, I think it is reasonable to allow IP or MAC addresses and certain DHCP option values to come from sources that are less than fully trusted, provided that they are valid and properly encoded. Sure, that's the sort of thing that ideally the maintainer should be able to capture in some sort of structured way.

They also should be able to capture the opposite! There should be some mechanism to say "regardless of whether you think this should be safe, I am not going to maintain this software in such a way that I will make any guarantees about its safety." You may not like that position, but that's the point: It communicates useful information that you really want to know! And does so in a way that isn't quite as confrontational as a lot of these CVE arguments end up being, and is happening before someone finds some problem instead of after.

Also, this seems useful to know as a user of the software. In the absence of any additional information, I may make assumptions about what is and isn't safe that are wrong. I'd rather find out that the maintainer disagrees with me before I deploy the software somewhere critical.

Ideally everyone would write wonderful documentation about these edge cases and everyone would read all of the documentation before deploying software, but, well, you know.

I don't know if there's some sweet spot here for a machine-readable policy that is sufficiently useful to be worth the additional effort of writing the labels. Maybe the answer is just "that's what the documentation is for; maintainers should write better documentation and users and security researchers should actually read it." But it feels like that's what we're trying right now and I'm not sure it's working that well.

something more machine-readable would help, but it might.

-- Russ Allbery (eagle () eyrie org) <https://www.eyrie.org/~eagle/>