Live data from Hacker News

Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

seclists.org

51–54 of 54 posts

Re: Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

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

Re: Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

#52
post #50
post #48

Earlier quoted context omitted.

You don't owe anyone anything when free. However, your reputation does depend upon treating security seriously. It's 2025, not 2005. So one should indicate "this is a hobby, and I have no time to deal with this" if so. Fair enough! However, if you have people paying for support, or you want them to see your software and become clients, or you do a project to showcase your skills? Security front and centre. My list of…

What started this is a case where you have to put weird stuff in a config file to trigger the CVE. If the people behind dnsmasq don't get paid or not enough, then it is perfectly fine if this is not a priority. We have a very popular product, lots of use in what is really the foundation of the internet and almost no support contracts. So you can turn the argument around, if you are not paying for software, consider i…

I think you're missing my point. Your code is your resume. It's also an advertisement for whether your product is worth donating to, helping with, buying, and whether you are an excellent coder and project maintainer or not.

A CVE, bogus or not, needs to be handled. If you don't, it reflects upon you. Hands down. No amount of "but it's for free" works to negate this. Ever. No one can demand anything of you, but your reputation will 100% be graded upon how you deal with such things.

This is the way the world works. This is how reputation works. Get over it. Deal with it. Understand it. No, you're not going to ever change this, unless you genetically engineer new humans. This is how humans, and human society has existed for millennia. You will never, ever, ever, change this. You will never explain an alternate to anyone. Ever.

Even if the CVE is bogus, you need to set the record straight, and it's almost akin to libel against your project and you. My suggestions about having a page listing all CVEs are fairly clear and to the point.

These suggestions help people asses your project and your reliability and competency. Yet at the same time? They reduce your effort and work!

Instead of debating endlessly on a mailing list, and instead of repeated bug reports, a well placed security page will take the lion's bulk of such things, answer them, and leave the project team free to not deal with questions on each CVE.

Such a list gives you an authoritative reason why the CVE is triaged as it is, you can point mailing list inquiries at it, WONTFIX bug reports at it, and you can even put your project's stance at the top of the page!

What I've been saying in these posts, is that organization overrules chaos. And that even if some weirdos disagree with you, or have silly expectations, you're crystal clear on things.

I think this is what you want. Your concerns about what people should expect, are dealt with via this method. I actually think we're aligned here, except (perhaps?) you think doing this is work.

It's not. It's the opposite of work. It's saving time.

Why?

Because you will never, ever, ever change human behaviour. Ever. Literally nothing has ever changed in, for example, how commercial transactions occur. This exact complaint could happen today over a used car:

https://www.guinnessworldrecords.com/world-records/537889-ol...

Every problem you've had with humans has been done endlessly billions of trillions of times. Just because it's a software project, doesn't mean it's any different than any other project. There have been volunteer, for free works since the inception of humanity. There have been people with unrealistic expectations, and the tug and pull therein.

I'll reiterate my original stance, just make it clear. Make it clear that you're dealing with CVEs. Part of this makes it eminently clear that the fly in the ointment is the persistent person with crazy expectations. Not your project.

Re: Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

#53
post #52
post #50

Earlier quoted context omitted.

What started this is a case where you have to put weird stuff in a config file to trigger the CVE. If the people behind dnsmasq don't get paid or not enough, then it is perfectly fine if this is not a priority. We have a very popular product, lots of use in what is really the foundation of the internet and almost no support contracts. So you can turn the argument around, if you are not paying for software, consider i…

I think you're missing my point. Your code is your resume. It's also an advertisement for whether your product is worth donating to, helping with, buying, and whether you are an excellent coder and project maintainer or not. A CVE, bogus or not, needs to be handled. If you don't, it reflects upon you. Hands down. No amount of "but it's for free" works to negate this. Ever. No one can demand anything of you, but your…

At the level of dnsmasq, I doubt they will care about resume.

CVEs are obviously important to you. I'm sure CVEs would be important to Dnsmasq, if they would get paid to handle them. So my guess is that they don't.

If they don't have the resources to deal with those CVEs (and I would certainly try to fix config errors that lead to crashes) despite being a hugely popular piece of software then they are just not going to deal with those CVEs, or report on them, etc.

The next step, given that Dnsmasq is used by big companies as well, might be to leave those CVEs out there on purpose. No money, no work.

If you expect that people are just not going to give you enough money then leaving out certain aspects of professionally maintained software is reasonable.

Re: Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

#54
post #2

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 presu…

I will add the version of dnsmasq this applies to is 10 years old, not a current version.
Post reply on HN