Re: Questionable CVE's reported against dnsmasq

[Pedro Sampaio <psampaio () redhat com>]

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

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

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.

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?

-- 
Pedro Sampaio | Red Hat Product Security
851525C5A98E9DEB7E650ABDFAC8296FBC674B8F