Why does it matter? I know the answer and this is a philosophical complaint, but the purpose of CVE is simply to make sure that people are talking about the same bug, not as a certification of importance or impact.
In this particular case, the poster is complaining that 3 CVEs were assigned for memory corruption vulnerabilities reachable only from the dnsmasq configuration file. I didn't read carefully, but the presumption that config file memory corruption bugs aren't vulnerabilities is problematic, because user input can find its way into configurations through templating; it depends on how innocuous the field triggering the bug is.
Vulnerabilities can and often are chained together.
While the relevant configuration does require root to edit, that doesn’t mean that editing or inserting values to dnsmasq as an unprivileged user doesn’t exist as functionality in another application or system.
There are frivolous CVEs issued without any evidence of exploitability all the time. This particular example however, isn’t that. These are pretty clearly qualified as CVEs.
The implied risk is a different story, but if you’re familiar with the industry you’ll quickly learn that there are people with far more imagination and capacity to exploit conditions you believe aren’t practically exploitable, particularly in highly available tools such as dnsmasq. You don’t make assumptions about that. You publish the CVE.
has anyone tried the PoC for CVE-2025-12198 from that chinese site on a version more recent than rusty? It wants a signup with a mainland china phone number, and i only have a taiwanese fax machine.
The affected version 2.73rc6 is quite interesting, because it is from 2015, and it is not the version the relevant code was introduced in, that is even older (guessing 2.62). Why fuzz some random release candidate from ten years ago?
Even more interesting v2.77 from 2017 (commits 5614413 and 2282787 to be precise) changed the code and added an (++i == maxlen) check at the place that is being highlighted by CVE-2025-12198 as lacking an (i < maxlen) check. The commit message says it fixed a crash and thanks a friend for fuzzing the config file.
Now i am not well versed in heap smashing with C, so don't confuse my lack of skill with an expert opinion, but i have a hard time understanding how that check is circumvented in recent versions of the code. Any explanation would be welcome.
But more than that someone should verify if this PoC works in recent versions. As a prerequisite it should be shared internationally.
I pentest network devices (amongst other things) for a living, and the way these usually work is that they have dnsmasq running in the background and to accept user config values, templating is used to generate dnsmasq-specific configuration files which are then fed into dnsmasq. I cannot overstate how common this method is.
Some devices do this more securely than others. If you're able to inject newlines, it's highly likely that you can already achieve command execution by injecting directives. I wrote a bit about this technique here: https://blog.nns.ee/2025/07/24/dnsmasq-injection-trick/ (sorry for the self-plug). I think it's up to the device vendor to do this securely and not a concern for dnsmasq.
However, in this case, I feel like the concern is elsewhere and not the sole responsibility of the device vendors. Even if the vendor does templating securely, the vulnerable config options could still trigger the bug in dnsmasq itself and give some advantage to the attacker. Assuming the vulnerabilities themselves are legit, I'm finding it difficult to classify these issues as "bogus".
If you ever open up a CVE calculator you'll see pretty clearly that the calculation is in isolation, as part of a chain.
Sure, CVE isn't optimal but virtually no model is. It's the whole point basically to provide a simplification of reality to be able to reason about it.
How do CVEs get issued? Where do I apply, who makes decisions, and what software is covered by them?
I know these questions are technically answered out there on the internet. But I looked into it a couple of years ago after finding a horrible bug in a popular npm package and the answers weren't clear to me.
The first issue being raised is that replacing the configuration file shouldn't count as a vulnerability. Usually I'd agree, but the fact that it causes memory corruption from user input warrants at least a low severity report.
If we can't prove that a vulnerability is exploitable, we have to keep our assumptions minimal. If the memory corruption vuln is provably unexploitable, a future code change could surface it as a plausible exploit primitive. It can also point to a section of code that may have been under-speced, and may serve as an signal to pay more attention at these sections for related bugs. Also, it doesn't seem right to assume that the config files will always be under a privileged directory.
The second issue being discussed iun the mailing list is that it's LLM slop. While the reports do seem to be AI generated, I haven't seen any response about the PoC failing, but maybe there is a significant problem where a lot of PoCs are fake.
So many assumptions. As commander Data may have said today, "the most elementary and valuable statement in security, the beginning of wisdom, is 'I do not know.'"
Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files
(seclists.org)55 points by JawsofDeath 20 hours ago | 49 comments
Comments
In this particular case, the poster is complaining that 3 CVEs were assigned for memory corruption vulnerabilities reachable only from the dnsmasq configuration file. I didn't read carefully, but the presumption that config file memory corruption bugs aren't vulnerabilities is problematic, because user input can find its way into configurations through templating; it depends on how innocuous the field triggering the bug is.
While the relevant configuration does require root to edit, that doesn’t mean that editing or inserting values to dnsmasq as an unprivileged user doesn’t exist as functionality in another application or system.
There are frivolous CVEs issued without any evidence of exploitability all the time. This particular example however, isn’t that. These are pretty clearly qualified as CVEs.
The implied risk is a different story, but if you’re familiar with the industry you’ll quickly learn that there are people with far more imagination and capacity to exploit conditions you believe aren’t practically exploitable, particularly in highly available tools such as dnsmasq. You don’t make assumptions about that. You publish the CVE.
The affected version 2.73rc6 is quite interesting, because it is from 2015, and it is not the version the relevant code was introduced in, that is even older (guessing 2.62). Why fuzz some random release candidate from ten years ago?
Even more interesting v2.77 from 2017 (commits 5614413 and 2282787 to be precise) changed the code and added an (++i == maxlen) check at the place that is being highlighted by CVE-2025-12198 as lacking an (i < maxlen) check. The commit message says it fixed a crash and thanks a friend for fuzzing the config file.
Now i am not well versed in heap smashing with C, so don't confuse my lack of skill with an expert opinion, but i have a hard time understanding how that check is circumvented in recent versions of the code. Any explanation would be welcome.
But more than that someone should verify if this PoC works in recent versions. As a prerequisite it should be shared internationally.
Some devices do this more securely than others. If you're able to inject newlines, it's highly likely that you can already achieve command execution by injecting directives. I wrote a bit about this technique here: https://blog.nns.ee/2025/07/24/dnsmasq-injection-trick/ (sorry for the self-plug). I think it's up to the device vendor to do this securely and not a concern for dnsmasq.
However, in this case, I feel like the concern is elsewhere and not the sole responsibility of the device vendors. Even if the vendor does templating securely, the vulnerable config options could still trigger the bug in dnsmasq itself and give some advantage to the attacker. Assuming the vulnerabilities themselves are legit, I'm finding it difficult to classify these issues as "bogus".
Sure, CVE isn't optimal but virtually no model is. It's the whole point basically to provide a simplification of reality to be able to reason about it.
I know these questions are technically answered out there on the internet. But I looked into it a couple of years ago after finding a horrible bug in a popular npm package and the answers weren't clear to me.
Can a CVE be issued in retrospect?
The first issue being raised is that replacing the configuration file shouldn't count as a vulnerability. Usually I'd agree, but the fact that it causes memory corruption from user input warrants at least a low severity report.
If we can't prove that a vulnerability is exploitable, we have to keep our assumptions minimal. If the memory corruption vuln is provably unexploitable, a future code change could surface it as a plausible exploit primitive. It can also point to a section of code that may have been under-speced, and may serve as an signal to pay more attention at these sections for related bugs. Also, it doesn't seem right to assume that the config files will always be under a privileged directory.
The second issue being discussed iun the mailing list is that it's LLM slop. While the reports do seem to be AI generated, I haven't seen any response about the PoC failing, but maybe there is a significant problem where a lot of PoCs are fake.
So many assumptions. As commander Data may have said today, "the most elementary and valuable statement in security, the beginning of wisdom, is 'I do not know.'"