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.

On Fri, Nov 14, 2025 at 1:44 AM Peter Gutmann <pgut001 () cs auckland ac nz> wrote: Jacob Bachmeyer <jcb62281 () gmail com> writes: Ah yes, the universal arbitrary code execution exploit: simply replace the program text with malicious code. :-)

Can we call it CVE-Zero? :-P The best one I've run into is enabling an undocumented internal build option that turns on extra code for coverage/fuzz testing, then reporting it as a vuln while ignoring the fact that the debug code also implements SSLKEYLOGFILE which dumps the plaintext TLS master secret to the diagnostic output.

Aside from the OpenSSH pseudovulnerability that started all this, anyone else have any interesting stories? Crypto++ earned a CVE for documentation: CVE-2016-7420, <https://seclists.org/oss-sec/2016/q3/520>.

Folks outside the project ported the Crypto++ library to another build system, but did not use the same build flags that Crypto++ uses. Then an assert fired because the ported build was a debug build. Crypto++ caught a CVE for a DoS. The CVE folks told the Crypto++ library that the behavior should have been documented.

Jeff

Jacob Bachmeyer <jcb62281 () gmail com> writes: Ah yes, the universal arbitrary code execution exploit: simply replace the program text with malicious code. :-)

Can we call it CVE-Zero? :-P The best one I've run into is enabling an undocumented internal build option that turns on extra code for coverage/fuzz testing, then reporting it as a vuln while ignoring the fact that the debug code also implements SSLKEYLOGFILE which dumps the plaintext TLS master secret to the diagnostic output.

Aside from the OpenSSH pseudovulnerability that started all this, anyone else have any interesting stories?

Peter.

On Thu, Nov 13, 2025 at 10:34 AM Peter Gutmann <pgut001 () cs auckland ac nz> wrote: [0] For example modify the code/operating environment to introduce a security vulnerability, I'll let you decide whether this qualifies as impractical, unrealistic, stupid, or several of the above. In a different context, it's practical, realistic, and sometimes a smart choice. Many custom Android ROMs now have a switch in the settings that ignores the window secure flag, and yet another one which prevents them from knowing that a screencast is in progress. From the app developers' viewpoint (I mean, apps that display something sensitive), it is an intentionally introduced vulnerability in the OS. From the user's viewpoint, it's a useful feature.

-- Alexander Patrakov

On 5 Nov 2025, at 19:02, Pedro Sampaio <psampaio () redhat com> wrote:

On Wed, Nov 5, 2025 at 12:13 PM Olle E. Johansson <oej () edvina net <mailto:oej () edvina net>> wrote:

On 4 Nov 2025, at 18:59, Art Manion <zmanion () protonmail com <mailto:zmanion () protonmail com>> wrote:

On 2025-11-04 04:03, Olle E. Johansson wrote: On 3 Nov 2025, at 19:07, Art Manion <zmanion () protonmail com <mailto:zmanion () protonmail com>> wrote:

CVEs against dnsmasq (CVE-2025-12198, CVE-2025-12199, CVE-2025-12200) and Kamailio (CVE-2025-12204, CVE-2025-12205, CVE-2025-12206, and CVE-2025-12207) mentioned in this thread are not yet disputed and have no comments of this sort in their descriptions. I asked VulDB to mark the dnsmasq CVE IDs as disputed. The VulDB CNA decided to reject the dnsmasq CVE IDs. As part of the Kamailio project I can say that we did just become aware of these CVEs in your email. They do not make sense. Trying to get to the report, the config files used to provoke the issue can’t be downloaded.

We’ve gone back and this was our core developer’s reaction to the mail we got earlier to our security address:

"This is clearly spam, imo: vague/generic reporting, no explicit naming of Kamailio ... the email was not sent from the vuldb.com <http://vuldb.com/> server but from mc20a2201.dnh.net <http://mc20a2201.dnh.net/> ([185.46.57.114]) -- I would suggest to not clink on the links, they might lead to malware, etc... I understand both sides of this problem. Would it have helped if the VulDB notification included details such as these (from CVE-2025-12207)?

https://shimo.im/docs/vVqRMVMlrycMO63y/read For us that site is not trustworthy. It could be language/cultural issues. One example is that the actual configuration files for some reason can’t be downloaded and the error message is in a language I have no understanding of.

Trust is hard. We have to think about this. We get all kinds of strange emails to our security reporting email address so we’re very cautious unfortunately.

How can we create some kind of trust system so that any open source developer - from one person projects to large projects with massive funding - know that a report is worth reacting to?

/O - Art

It seems to be that there is a hidden stage during the PSIRT function that may require its own identification inside the CVE Program (which I assume is the highest source of truth for us at this moment?). And that stage is when a security issue is deemed not enough to become a full CVE, but it is still relevant for awareness purposes. Assigning a CVE ID only to have it disputed or rejected later seems like a process that is confusing and hard to manage. With bug bounties and other incentives to “file a CVE for your CV” normal bugs are reported as vulnerabilities, which cause a lot of work in all parts of the vulnerability management process. The amount of people spending time assessing these before finding out that they can be ignored will cost society a lot of money, resources and frustration.

In our case (Kamailio) getting a message directly from the CNA would have helped starting a dialogue, if we could somehow validate the CNAs messages. Disputes have no nuance and once the word is out, the possible damages are hard to revert. Oftentimes they stay perpetually open, and resolutions seem to not give any definitive answer, which adds to the confusion. Most CVE record consumers do not have a way to clearly differentiate and correctly prioritize them. Right. I haven’t looked into how various vulnerability management platforms handle this. Worth investigating. What if a new ID could be created for these cases, like a lower level CVE, which can help raise awareness, maintain discussion history, and issues could be elevated or degraded to it without them getting stuck at the never ending vendor CVE grinder, but still benefiting from the current CVE infrastructure? My personal vision is that we need a set of related objects for each CVE, much like the ADPs. CVEs will in many cases continue to have different opinions - with some vendors disputing them just to protect their brand and others wanting to add a different severity.

Anyway, I think this is an indication of a CNA that did not fully look into the issue.

/O

On 4 Nov 2025, at 18:59, Art Manion <zmanion () protonmail com> wrote:

On 2025-11-04 04:03, Olle E. Johansson wrote: On 3 Nov 2025, at 19:07, Art Manion <zmanion () protonmail com> wrote:

CVEs against dnsmasq (CVE-2025-12198, CVE-2025-12199, CVE-2025-12200) and Kamailio (CVE-2025-12204, CVE-2025-12205, CVE-2025-12206, and CVE-2025-12207) mentioned in this thread are not yet disputed and have no comments of this sort in their descriptions. I asked VulDB to mark the dnsmasq CVE IDs as disputed. The VulDB CNA decided to reject the dnsmasq CVE IDs. As part of the Kamailio project I can say that we did just become aware of these CVEs in your email. They do not make sense. Trying to get to the report, the config files used to provoke the issue can’t be downloaded.

We’ve gone back and this was our core developer’s reaction to the mail we got earlier to our security address:

"This is clearly spam, imo: vague/generic reporting, no explicit naming of Kamailio ... the email was not sent from the vuldb.com server but from mc20a2201.dnh.net ([185.46.57.114]) -- I would suggest to not clink on the links, they might lead to malware, etc... I understand both sides of this problem. Would it have helped if the VulDB notification included details such as these (from CVE-2025-12207)?

https://shimo.im/docs/vVqRMVMlrycMO63y/read For us that site is not trustworthy. It could be language/cultural issues. One example is that the actual configuration files for some reason can’t be downloaded and the error message is in a language I have no understanding of.

Trust is hard. We have to think about this. We get all kinds of strange emails to our security reporting email address so we’re very cautious unfortunately.

How can we create some kind of trust system so that any open source developer - from one person projects to large projects with massive funding - know that a report is worth reacting to?

/O - Art

On 2025-11-04 04:03, Olle E. Johansson wrote: On 3 Nov 2025, at 19:07, Art Manion <zmanion () protonmail com> wrote:

CVEs against dnsmasq (CVE-2025-12198, CVE-2025-12199, CVE-2025-12200) and Kamailio (CVE-2025-12204, CVE-2025-12205, CVE-2025-12206, and CVE-2025-12207) mentioned in this thread are not yet disputed and have no comments of this sort in their descriptions. I asked VulDB to mark the dnsmasq CVE IDs as disputed. The VulDB CNA decided to reject the dnsmasq CVE IDs. As part of the Kamailio project I can say that we did just become aware of these CVEs in your email. They do not make sense. Trying to get to the report, the config files used to provoke the issue can’t be downloaded.

We’ve gone back and this was our core developer’s reaction to the mail we got earlier to our security address:

"This is clearly spam, imo: vague/generic reporting, no explicit naming of Kamailio ... the email was not sent from the vuldb.com server but from mc20a2201.dnh.net ([185.46.57.114]) -- I would suggest to not clink on the links, they might lead to malware, etc... I understand both sides of this problem. Would it have helped if the VulDB notification included details such as these (from CVE-2025-12207)?

https://shimo.im/docs/vVqRMVMlrycMO63y/read

- Art

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.

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.

On 2025-11-02 03:30, Olle E. Johansson wrote:

On 1 Nov 2025, at 04:00, Solar Designer <solar () openwall com> wrote:

CVEs against dnsmasq (CVE-2025-12198, CVE-2025-12199, CVE-2025-12200) and Kamailio (CVE-2025-12204, CVE-2025-12205, CVE-2025-12206, and CVE-2025-12207) mentioned in this thread are not yet disputed and have no comments of this sort in their descriptions. I asked VulDB to mark the dnsmasq CVE IDs as disputed. As part of the Kamailio project I can say that we did just become aware of these CVEs in your email. They do not make sense. Trying to get to the report, the config files used to provoke the issue can’t be downloaded.

If you have access to edit the config files, there are much more simple ways to cause damage than to provoke a problem in the config file parser.

We will have an internal discussion but that will likely lead to the project disputing these CVEs. Hello Olle! I was going to do o the same for the Kamailio CVE IDs but defer to the project's decision. If you do decide to dispute, the first request should go to VulDB:

https://www.cve.org/PartnerInformation/ListofPartners/partner/VulDB

(I accidentally asked the MITRE CNA-LR first.)

Regards,

- Art

On 1 Nov 2025, at 04:00, Solar Designer <solar () openwall com> wrote:

CVEs against dnsmasq (CVE-2025-12198, CVE-2025-12199, CVE-2025-12200) and Kamailio (CVE-2025-12204, CVE-2025-12205, CVE-2025-12206, and CVE-2025-12207) mentioned in this thread are not yet disputed and have no comments of this sort in their descriptions. As part of the Kamailio project I can say that we did just become aware of these CVEs in your email. They do not make sense. Trying to get to the report, the config files used to provoke the issue can’t be downloaded.

If you have access to edit the config files, there are much more simple ways to cause damage than to provoke a problem in the config file parser.

We will have an internal discussion but that will likely lead to the project disputing these CVEs.

Best regards, /Olle

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