Conversation

The Linux Kernel project was made an official CVE Numbering Authority (CNA) with exclusive rights to issue CVE identifiers for the Linux kernal in February this year.

While initially this looked like good news, almost three months later, this has turned into a complete and utter disaster.

Over the past months, the Linux Kernel team has issued thousands of CVE identifiers, with the vast majority being for trivial bug fixes and not just security flaws.

Just in May alone, the Linux team issued over 1,100 CVEs, according to Cisco's Jerry Gamblin—a number that easily beat out professional bug bounty programs/platforms run by the likes of Trend Micro ZDI, Wordfence, and Patchstack.

https://news.risky.biz/risky-biz-news-the-linux-cna-mess/

2
1
0

@dangoodin I think that's overly alarmist. @gregkh has talked about this in public. IMO a lot of the "the world is ending" talk is from folks that already had completely unsustainable vuln management practices based around a broken CVE assignment and scoring system, and it's not because the Kernel security folks are doing something wrong it's because the way people update and assess software is broken.

@joshbressers @kurtseifried

2
1
0

@dangoodin One man's bug is another man's security flaw, especially in kernel space.

I recommend this blog post talking about how the traditional way CVE was working isn't going to cut it any more. Not because, but despite of what the kernel team does: https://opensourcesecurity.io/2024/06/03/why-are-vulnerabilities-out-of-control-in-2024/

And if you are working on a custom kernel build, you should assess all these fixes for security anyway. And if you don't you shouldn't care and pay your vendor to handle it.

0
0
0

@camdoncady @dangoodin @gregkh @joshbressers @kurtseifried There's a non-vuln-management problem, which is that CVEs are used to inform a lot of academic work; the Linux kernel team using different issuance criteria than everyone else is going to break a lot of academic research.

0
0
0

@kurtseifried @camdoncady @dangoodin @gregkh @joshbressers I haven't dug in. I'm assuming researcher who Dan quoted is reasonable in saying LK is over-assigning and responding to Camdon's claim that it doesn't matter. If the researcher is wrong, my point isn't relevant.

That said, if two CNAs are making different issuance decisions with similar facts, then that seems worrisome to me.

3
0
0

@adamshostack @kurtseifried @camdoncady @dangoodin @gregkh I guarantee different CNAs make different decisions all the time

The definition of a vulnerability isn't nearly as concrete as it should be. There's a ton of subjectivity in all this data

1
0
0

@joshbressers @kurtseifried @camdoncady @dangoodin @gregkh The definition of vuln is exceptionally concrete... compared to the definition of exposure. 😇

More seriously, at the level of a few it matters much less than at the level of hundreds.

1
0
0

@adamshostack @kurtseifried @camdoncady @dangoodin @gregkh

It's really not though

I've been in many meetings where the definition has been twisted around to call something just a bug

You can see this all the time when a security researcher submits a finding and whoever they are reporting it to declares it not a vulnerability. I guarantee every researcher has many stories like this

0
0
0

@kurtseifried @adamshostack @camdoncady @dangoodin @gregkh @joshbressers I don't think the Linux team is performing any kind of malicious compliance, this is just a good faith effort to actually document all possible vulnerability that is showing weaknesses in the process, hidden because other orgs instinctively moderate how they assign CVE IDs and get away with lip service, like your eg of only assigning when external parties already know of the issue.

1
0
0

@kurtseifried @adamshostack @camdoncady @dangoodin @gregkh @joshbressers this Linux consensus was already that they have a ton of churn and code which is public knowledge and may be publicly used, so they would have a huge number of trackable items if they got serious a about documentation, which is what predictably happened.

This is an opportunity to review CVE and the reality of the Linux kernel more than anything else

0
0
0

@adamshostack @kurtseifried @dangoodin @gregkh @joshbressers I'm not sure that "it doesn't matter" is an accurate characterization of my original position - I said that "complete and utter disaster" was "overly alarmist". I think this does matter, I just happen to think that the good outweighs the harm, and we'd still be on a bad path when it comes to CVEs even if the kernel team became a CNA and then never issued a CVE number.

I admit I hadn't thought much of the academic research angle when I originally responded to Dan above. Having given it some more thought, I don't think it changes my position. I've long been of the opinion that the kernel development really stands alone a process and a product, and using the kernel as the lens to assess the open-source community in general isn't a great idea. I think for most academic research, you'd want to tread the kernel separately. If you are doing research on Linux kernel vulnerabilities, then CVEs are probably not the best proxy for "total vulnerabilities" anyways. There's research (that Greg utilizes when deciding what commits to pull into the stable branch as security-relevant) that shows that different subsystems don't assess the security considerations of bugs the same way, so they use a ML ("classic ML", you don't need an LLM for this I don't think) to classify commits. I think it's linked on the OSS podcast page from Greg's episode. So - if you're doing kernel security research, you need to be looking at more than just CVE counts.

I'll give you my opinion on why folks are so bent out of shape about having more CVEs assigned by the kernel maintainers: because for years, commercial companies have been grabbing open-source dependencies by the truckload in order to quickly ship features (read: make money), without having any sort of plan for how they might contribute back or how they would meet their obligations to consumers for keeping their commercial products updated and secure. OSS isn't a "supply chain", it's a natural resource being strip-mined. For years, these companies have been doing the bare minimum in the form of grudgingly patching critical vulnerabilities (frequently only when a POC was published against their product, otherwise they are happy to claim "not reachable in *my* code path" faster than anyone could do a thorough analysis). These same companies then have the temerity to go back to the OSS maintainers and ask them to assess the impact to the *downstream product* - and when they don't like the answer, they accuse unpaid volunteers of "not doing their job."

Microsoft and Red Hat have trained a generation of managers (and devs, honestly) that you can just write software and then run it, without maintenance, for decades. In a world that is as connected and full of malicious actors that doesn't work. At the same time, the propagation of cyber security standards (RMF, SOC, PCI, etc.) have created a so-called security culture that revolves around compliance and not an honest assessment of risk. When you combine those with the growth of CVEs (which was already happening before the kernel went down this path - and also I've seen no credible argument that the kernel team contributed to the NVD falling flat on it's face), you get a ton of gnashing of teeth and wailing.

CC: @campuscodi since I'm really responding to him and not to Dan

0
1
0
@joshbressers @camdoncady @dangoodin @gregkh @kurtseifried @Di4na We don't know if vulnerabilities are "out of control", because Greg KH decided to prove his "CVE != vulnerability" point by simply spamming the database :-(.
1
0
1
@joshbressers @camdoncady @dangoodin @gregkh @kurtseifried @Di4na "CVE-2023-52882: clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change". "CVE-2024-36020: i40e: fix vf may be used uninitialized in this function warning". "CVE-2024-36022: drm/amdgpu: Init zone device and drm client after mode-1 reset on reload".
0
0
0

@kurtseifried @camdoncady @dangoodin @gregkh @joshbressers I'll defer to you on the CNA rules issue. On the academic side, I think that "all models are wrong and some models are useful." It's not only ok for an academic to say "We'll use X to represent this and focus on another research question," but possibly preferable for them to not try to redefine what a vuln is.

For example, if I'm doing static analysis research, then I can either "Use CVEs" as a reference dataset, or I can define some other reference. I shudder to think what that other would end up being.

0
0
0

@kurtseifried @camdoncady @dangoodin @gregkh @joshbressers I dunno how you can ignore wordfence until you move to a static site generator. 😜

0
0
0

@kurtseifried @adamshostack @camdoncady @dangoodin @gregkh @joshbressers to be honest if every security issue under the sun is given a proper CVE id (which to amusement and surprise of people is not the case right now : most folks in this list would be very much aware of this IMHO) no one will have time to deal with all of them. since one CNA is actually responsibly putting CVE details out people ave issues.

wordfence, patchstack and likes are mostly wp bugs. I know from my own research there is a lot more where that is coming from and its just tip of an iceburg. every time i have looked at that ecosystem more issues are identified. should we not assign cve's considering an obscure plugin is not important for all or should we focus on better cve details so that people have some semblance of what to keep in mind what to ignore.

1
0
1

@kurtseifried @camdoncady @dangoodin @gregkh @joshbressers How does that help with a static analysis project? My mental model here is "I wrote a new tool that takes source code and emits vulns, and I use CVEs to see if my tool finds all of them"

0
0
0

@anant @kurtseifried @adamshostack @camdoncady @dangoodin @gregkh I used to be on the side of more IDs, because we should be tracking everything

But I think we need to clean up the data first. We already can’t actually handle the volume of IDs we have. More won’t solve any problems

But proper and correct data would solve many problems

1
0
0

@joshbressers @kurtseifried @adamshostack @camdoncady @dangoodin @gregkh are they mutually exclusive cant we aim for more better tracking as well as more detailed data

1
0
0
@kurtseifried @joshbressers @camdoncady @dangoodin @gregkh @Di4na Yes, I'm saying there's a lot of CVEs that should be rejected, and I gave some examples. If you believe Greg is acting in good faith, you can try to reject a few and cc me.
0
0
1

@anant @kurtseifried @adamshostack @camdoncady @dangoodin @gregkh they might be mutually exclusive. More ids without better data will probably have unexpected results

Better data has no obvious solution today

0
0
0
@kurtseifried @anant @joshbressers @adamshostack @camdoncady @dangoodin Thank you for noticing, I spent a lot of time on making this information able to be created automatically as it is quite valuable for people to be able to EASILY, and programatically, determine if they should, or should not, even look at this specific entry. Everyone does actually know what small % of the 80,000+ files in the kernel they build into their image, and what versions they are running, right? If not, they have bigger issues than random CVE entries...

Side note, I create all the json from a set of wonderfully horrible bash scripts that parse the semi-free-flowing kernel git commit logs and branches to determine the information needed:
https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/scripts/bippy
https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/scripts/dyad
https://git.sr.ht/~gregkh/linux-stable_commit_tree/tree/master/item/id_found_in
0
2
8
Edited 8 months ago

@kurtseifried @pavel @camdoncady @dangoodin @joshbressers @gregkh that is because they cannot.

This is what the "spam" is revealing. Not that they are bad CVE. That noone had the adequate ressources for it.

So once it is used as it should, everyone panick. Work-as-imagined vs Work-as-designed vs Work-as-done

0
0
0
@kurtseifried @Di4na @camdoncady @dangoodin @joshbressers @gregkh If you want to assign me work, you have to do some research. Are you saying that turning git commits into CVEs without analysis is okay, and rest of the world now has obligation to do analysis and follow whatever process "auhority" demands?
0
0
1
@kurtseifried @joshbressers @camdoncady @dangoodin @gregkh @Di4na Greg publicly says that he creates CVEs for any bug, not just for vulnerabilities. Rejecting such CVEs one-by-one is not going to fix that.
1
0
1
@Di4na @camdoncady @dangoodin @joshbressers @kurtseifried @gregkh Is copy/pasting stable git commits into CVE database "the way it should be used"?
0
0
0

@pavel @camdoncady @dangoodin @joshbressers @kurtseifried @gregkh except this is taking the pov that he can knows if that bug is a vulnerability or not.

It happens that this is not easy and that the CVE process is indeed to start as such and then revoke it is not. This is how it was designed.

1
0
0
@kurtseifried @Di4na @camdoncady @dangoodin @joshbressers @gregkh "Linux kernel" did the work? Take a look at the CVEs. Its clearly copy/paste from changelog, not "work" being done.
0
0
1
@Di4na @camdoncady @dangoodin @joshbressers @kurtseifried @gregkh "he can knows" -- that's not english. Yes, sometimes it may be hard to decide if something is vulnerability or not. But sometimes it is very easy to see that it is not vulnerability, and we get it in CVE anyway. Look at the CVE below. It is clear that's a random bug, not anything attacker can exploit. It would be clear to Greg, too, if he spent 30 seconds analyzing it. But he did not. Plus, those copy/pasted descriptions make no sense. CVE-2023-52882 "Description
In the Linux kernel, the following vulnerability has been resolved: clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change While PLL CPUX clock rate change when CPU is running from it works in vast majority of cases, now and then it causes instability." Is it considered ok to generate CVE descriptions that are not even close to valid english?
1
0
1
@pavel @Di4na @camdoncady @dangoodin @joshbressers @kurtseifried Pavel, the very next sentence in the text says "This leads to system crashes and other undefined behaviour."

{sigh}

You are now blocked.
1
0
1
@gregkh @Di4na @camdoncady @dangoodin @joshbressers @kurtseifried Yep, clearly having some english sentences in the text is enough. Good work! Also great example of quality of the CVE entries you produce, unfortunately.
0
0
0