Another rule for NULL dereference

[catenacyber]

Query PR

github/codeql#16524

Language

C/C++

CVE(s) ID list

Most results are not yet fixed nor disclosed... About half of the top 100 C projects have at least one report.
Some reports are kind of duplicates when there is a vendor dependency which is in multiple projects...
How should I go about it ?

CWE

476

Report

The vulnerability is a NULL dereference.
2.
A function may return NULL, and its return value is not checked before passing it to another function which dereferences it, also without checking it.
3.
This query was inspired by a real bug cf OISF/suricata#11098
4.
I first worked on the query on Suricata database, then I ran it on the top 100 C projects to refine it.
I guess there are still a few false positives to address, when there is a disguised check against the pointer being NULL (like checking an integer representing a size greater than zero)
5.
Most results seem to come from ignoring malloc or such return.

Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc).

• Yes
• No

Blog post link

No response

[p-]

Hi @catenacyber

Regarding your question:

Most results are not yet fixed nor disclosed... About half of the top 100 C projects have at least one report.
Some reports are kind of duplicates when there is a vendor dependency which is in multiple projects...
How should I go about it ?

per the rules:

The issue should include details of any vulnerabilities found by your query, as a list of CVEs. To be considered, your query must find at least one CVE that was not previously found by an existing query, in a released version (older releases are also permitted) of an open source project that is actually used (no demo, training, vulnerable on purpose). Submissions without at least one result won't be considered. In case of a new CVE, don't create an issue until the coordinated disclosure process for those vulnerabilities is complete, because the issue will be publicly visible.

So it can be a new CVE (after the disclosure process), or an existing CVE your query would have been able to identify using the source code of an older version of a project.

[catenacyber]

There will be one CVE for Suricata whose fix is OISF/suricata#11098 but the CVE ID will come with the next Suricata release...

Thanks for your answer but my question was rather how to go on disclosing that many bugs.
(Most projects will not consider it a security issue to ignore that malloc may return NULL, even if some projects do...)

[p-]

For a bounty submission of type "all for one" one CVE ID should be enough (as long as your query is able to detect it).
As for disclosing the other bugs: your query seems to yield a lot of results. However, that doesn't necessarily mean that all those findings have a security impact. So I assume it could take a lot of manual work to actually find out which of those findings are worth reporting (e.g. if a remote attacker can crash a server). So if you want to do this it could make sense to narrow the focus on server applications first.

[catenacyber]

Ok, so I will get back to you when I have at least one CVE id.
I will do some manual work to find which ones are the most interesting to report. (For now, I reported 2 besides the one in Suricata)

[catenacyber]

This Suricata bug has CVE 2024-38536 cf GHSA-j32j-4w6g-94hh

[xcorail]

Created Hackerone report 2616866 for bounty 599428 : [826] Another rule for NULL dereference

[xcorail]

Hey @catenacyber

how to go on disclosing that many bugs

As @p- suggested, there is no magic and you have to go through a difficult triage phase, then an even more complicated individual reporting phase where the reporting method varies per project, and so is the responsiveness.

Here are some criteria ideas to prioritize your reports and optimize your efforts:

• impact (+1 on Peter's suggestion on narrowing to server)
• responsiveness of the project to vulnerability reports: do they have PVR enabled, a security policy, a recent track record of CVEs or advisories, a healthy recent activity (bugs are fixed, PRs are reviewed)
• criticality score of the project

Then once you have a significant number of reports fixed / CVEs, publish a blog post with the pattern and the remediation, and how to use your CodeQL query to find it.

And then, optionally, you can point the other repos at the article, telling them that their repo contains an occurrence of the pattern. But note that it would be a sort of public disclosure, as you would need to open a public issue for that. So tread carefully. For example, don't do that if the repo has a security policy, use that security policy instead.

Good luck!

[catenacyber]

Thanks Xavier :-)

I will try to investigate some reports next week.

By the way, was I the last bounty ? cf #828

[catenacyber]

For the record, I investigated some reports, but did not find any that were not coming from an allocation returning NULL

There was GHSA-xw53-587j-mqh6 but I have no news about it

[catenacyber]

GHSA-xw53-587j-mqh6 is now public and CVE-2025-32787