The #CVE count of the #Linux #kernel is not looking good these days compared to any other #OS is it. Maybe time to switch to #FreeBSD or some other system which doesn't claim to find hundreds of significant vulnerabilities every day

But no seriously what the fuck is @gregkh trying to achieve here? Before, I could use a CVE count as an argument to spend time upgrading #Linux: "there have been found 5 vulnerabilities in the version we use, we should upgrade to the latest". These days, CVEs are useless for that purpose, everyone knows that pretty much every single one of the thousands of "CVEs" affecting the kernel version we're on is bogus so they aren't useful for that purpose any more so we stay on old kernels for longer

@mort @gregkh

Using CVE counts as an argument this way has always been bogus though, regardless of what is currently happening.

@Foxboron No.

@mort

Of course it has. CVE identifiers have been misinterpreted/misused/misunderstood this way for years.

@Foxboron No

@mort @Foxboron You can keep saying no all you want; it doesn’t make it any more true. CVEs have basically never been an accurate representation of changes that have security impact. Actually trying to do this remains an open problem that requires significant resources.

@mort @Foxboron You’re upset that the situation went from “these are 10% of the security bugs and each one is definitely bad” to “this is 100% of the security bugs and maybe 10% of them are definitely bad”. Neither helps you solve the problem you have of “should I update”.

@mort @Foxboron i scrolled briefly through the list of cves assigned last friday and it looks like the largest chunk are memory safety issues. maybe you should update your kernel... though most of them are in optional components. maybe it would be useful to include metadata on the cve describing what kconfig you need for the affected code to be compiled in

@mort Hey, @jls, I know you're now almost finished with that book of yours. However, what about changing the subject slightly and explaining memory management in #FreeBSD instead?

@mort Are you listening to yourself? The system which reports fewer security issues is more secure? Really? Then you should switch to #OpenBSD, because they hide their security errors best!

@mcepl That's not what I'm saying. I'm saying that if there are enough exploitable vulnerabilities in Linux to fix a hundred of them every single day consistently, clearly it's not a very secure operating system

If there's not enough exploitable vulnerabilities to do that but they're publishing a hundred CVEs per day regardless, that's just a DDOS attack against a deeply imperfect yet useful vulnerability reporting system

@mort

And yet until yesterday you were using it happily persuaded that it is secure, and if Greg took over FreeBSD and start reporting CVEs on it, you would be persuaded that it is insecure as well? It is just reporting!

@mcepl Well I knew there were issues, nothing is perfect, but I was under the impression that it was secure enough that you couldn't fix a hundred exploitable vilnerabilities per day and still go strong a month later, yeah.

@mcepl If FreeBSD started publishing a hundred CVEs about exploitable vulnerabilities per day I would have the same reaction to that

@mort

Have you watched https://youtu.be/HeeoTE9jLjM ?

@mcepl Maybe, I can't recall and I don't think it's very relevant.

@mort

And of course @BrodieOnLinux@linuxrocks.online published very detailed analysis of the issue on https://youtu.be/g_yrk7BXLRI

@mort @mcepl it is relevant, Greg is explaining there his plan to troll the cve system and so now he does exactly that. Cc @ljs

@vbabka @mort @mcepl Honestly I don't really see the point in going over it all again when @gregkh just >/dev/null's people who point out the issues.

As much as I respect the big G, it's not really a conversation if it's one way is it...

Everyone knows the issues, everyone knows it's a troll, but it is what it is :) :) :)

@vbabka @mort @ljs @mcepl I am not trolling anything, I am working within the requirements of the CVE system at the request of the people who run it. We are doing so because other entities were abusing the CVE system for the Linux project in the past, so in order to take control of it, we must work within the constraints with which we are placed.

And that means assigning CVEs to everything that meets the definition of vulnerability as defined by cve.org. If you, or anyone else notices a CVE we issue that does NOT meet that definition, please let us know and we will be glad to reject it.

Odds are other operating system kernels will start doing the same as Linux does, if they wish to be a CNA for their project. We aren't alone here, it's just that we report our fixes, others don't, or aren't actually developing any fixes. You be the judge of which is the case for various projects :)

@mort @gregkh s/fuck/hug/ 🌼

@gregkh @vbabka @mcepl @mort everything you say after 'I am not trolling' absolutely does not contradict the position that you are trolling (nor what you said in your talk about... err... trolling CVEs).

Trolling CVE = following the rules to the letter to demonstrate the rules are silly.

I mean I might not be as senior as Vlasta (which is probably why you're replying to him not me), but I did speak to other senior kernel people in person and EVERYBODY thinks this is what you're doing.

The issue are the downstream effects as collateral damage, but since your position is 'use stable kernels or I don't care' I guess you don't care ;)

@gregkh @vbabka @ljs @mcepl @mort No. You are trying to "burn them" , as you publicly said and is archived on youtube. You are assigning CVE numbers to bugs fixed in -stable kernels, without analysis if they constitute a vulnerability or not, copy/pasting patch title as vulnerability description... That is neither subset nor superset of real vulnerabilities. Plus you are not exactly welcoming when people try to reject an CVE.

@gregkh @ljs @mcepl @mort hmm interesting, afaik curl also became a CNA early this year and a glance at their list of vulnerabilities doesn't look anything like Linux's https://curl.se/docs/security.html so that would mean they are not doing what's expected of them?

@vbabka @mcepl @mort @gregkh @ljs given the differing focus, not to mention scale in terms of cobebase size or rate of change, I'm not sure comparing the number of CVEs Curl has with the kernel proves anything.

@MWelchUK @vbabka @mcepl @mort @gregkh @ljs

I only checked quickly but looks like the kernel has 125x as much code as curl.

I'm certain the kernel does not have 125x as many people working on triaging CVEs.

@mpe @vbabka @mcepl @mort @gregkh @ljs probably not. Though beyond both projects being open source, being their own CNA and being written for the most part in C, that's probably where the similarities end. Comparing them is a bit pointless.

@MWelchUK @mpe @mcepl @mort @gregkh @ljs didn't mean to just compare numbers, but the curl CVEs from 2024 look like the traditional stuff explaining a vulnerability etc. I'd expect even with the much smaller codebase they had fixes this year applied in git that would get a CVE by the current kernel process, but didn't.

@vbabka @mcepl @mort @mpe @gregkh @ljs Right and the kernel and Curl are two very different beasts, working in very different places in the OS stack and thus the impact from a given class of bug could be very different. In one case it could be a segfault, in the other a privilege escalation.

@ljs @mcepl @mort @vbabka Yes, I said "trolling" many years ago in jest as there was no way for the kernel community to actually create CVEs like that, it was a joke.

But what I'm saying now is that I am NOT trolling anyone. The number of CVEs created for the kernel is exactly what cve.org wants us to do here as now we ARE allowed to be a CNA. And by being a CNA, we must follow the rules of cve.org which is what we are doing. I have had many meetings with the cve.org employees and board about this, and everyone seems to be in agreement that what we are doing now is correct and should be done this way.

Again, I'm not trolling anyone, and again, the kernel development model has not changed, all that has changed is that finally we are marking all potential vulnerability fixes as CVEs.

Again, if anyone knows of any CVE entries that we have assigned that should not be CVE entries, please let us know.

@gregkh @mcepl @mort @vbabka Firstly, thanks for responding, it's appreciated.

Do you think CVEs as a concept are broken?

@ljs @mcepl @mort @gregkh @vbabka

Greg did a nice job explaining much of this here on a podcast I co-host

https://opensourcesecurity.io/2024/02/25/episode-417-linux-kernel-security-with-greg-k-h/

@ljs sorry for jumping in, there was another thread discussing this: https://pony.social/@thephd/112479768565249999

@triskelion thanks!

@joshbressers @mcepl @mort @gregkh @vbabka Does he answer the question I just asked?

As I feel that's absolutely fundamental (malicious compliance doesn't work if you admit it's malicious compliance).

@ljs @mcepl @mort @gregkh @vbabka he does explain it

The Linux kernel is one of the most widely used pieces of software on the planet. It’s in phones, space ships, and milking machines

They tag anything they think could be a problem without understanding the use case

As one would expect, this is a very wide net

@joshbressers @mcepl @mort @gregkh @vbabka that wasn't what I asked :)

It's a yes/no question.

@ljs @joshbressers @mcepl @mort @vbabka It's not a yes/no answer, that's not how the world works. One can hate the system but know that one must work within the system if one wishes to create change for the better. Much like we did for Linux adaption in the first place.

If you don't like CVEs, wonderful, just ignore them, they aren't causing you any issues. If you do like CVEs, great, I have loads of them for you :)

Again, the way CVEs for the Linux kernel were being allocated was broken and being abused by many corporations. We have now fixed that by hopefully making it work for _everyone_ who cares about CVEs, not just the few in the past that were taking advantage of it for their own gain. That is not "trolling", that is "working to fix the broken system that was previously in place".

@gregkh @mcepl @mort @joshbressers @ljs @vbabka > If you don't like CVEs, wonderful, just ignore them, they aren't causing you any issues. If you do like CVEs, great, I have loads of them for you :)
sir look
i like chocolate
but not like three tons of it

@lkundrak @mcepl @mort @joshbressers @ljs @vbabka What, you want people to slow down and NOT fix vulnerabilities? Or just not report them like we had been doing for the past decades?

All other operating systems are in the same boat, either they are not actually fixing things, or they are not reporting them. You ask them which it is...

@gregkh @joshbressers @mcepl @mort @vbabka I mean I think this is, in different (and more polite perhaps) words, the same as what I and others assumed you were doing :>)

The issue are downstream effects on enterprise kernels where suddenly workloads are increased dramatically.

The focus on CVEs as a measuring tool for this is broken obviously, debate is whether opening the flood gates is the right way to highlight that.

But as I said a few toots ago, I gather your position is 'the stable kernel is what you should be using' (correct me if I'm wrong), so I guess to you this is immaterial.

@gregkh @lkundrak @joshbressers @mcepl @mort @vbabka they're not vulnerabilities though right? They're things that 'could be' vulnerabilities...

Which I guess is the whole issue with CVEs in the first place.

@gregkh @mcepl @mort @joshbressers @ljs @vbabka reading the thread I feel like the "problem" gkh is referring to is "almost all kernel vulns go unreported and what is reported is often bogus" and the "problem" everyone else in this thread think is happening is just "what is reported is often bogus"

@ljs @joshbressers @lkundrak @mcepl @mort @vbabka What we are issuing meets the cve.org definition of "vulnerability" as defined by them.

Perhaps you are thinking the word means something different than it does in this context.

@gregkh @joshbressers @lkundrak @mcepl @mort @vbabka I mean 'demonstrably exploitable vulnerability'.

Many things 'could' be, only a few actually are.

And I think the breadth of CVE's definition is the underlying issue here, as many seem to be under the impression that an issued CVE implies it is a known, perhaps even already exploited issue that therefore must be resolved.

Rather than a fixes: tag assigned to something because you broke an antique system in some obscure edge case

@gregkh @mcepl @mort @joshbressers @ljs @vbabka I think the problem is mostly faced by maintainers of their own LTS kernel by simply applying CVE fixes, and that isn't working it anymore. Perhaps having an additional database on vulnerabilities exploited in the wild could help such downstream maintainers and those who prefer the old approach. Probably such a solution already exists :-)

@triskelion @gregkh @mcepl @mort @joshbressers @vbabka the issue is customers + regulatory agencies might well mandate these fixes :)

Which is all very broken. The question is whether opening the fire hose is the right way to fix it.

Which is exactly why there's controversy around this...

@ljs CVE number has never been the thing you are talking about. The whole purpose is to uniquely identify security issues so everyone knows they are referring to the same thing when they communicate. It is a damn good idea to get a CVE number early so you can start using that number in the research and root cause and fix. If you only get it at the end, the record is half lost.

@shironeko where did I say, exactly, that that's what CVE was?

@ljs
> I mean 'demonstrably exploitable vulnerability'.

to demonstrate a vulnerability is exploitable takes months of work and you should get a CVE number before you do any of that to document your process so it's searchable later.

@shironeko ok will give you 1 more chance to show you're in good faith before I block.

I never said this was what CVE was. You can't point out where I said that, because I didn't.

It's not helpful to jump in and add a false straw man argument to try to make me look silly.

And instead of admitting that, you quote me not saying that... I mean c'mon. :)

I repeatedly said 'this is the whole issue with CVEs' by which to be clear I mean people taking them to mean that rather than the actual definition which is as you say.

I was explicitly explaining what I meant in answer to what Greg asked.

The issue as I have said probably more than once are the downstream effects this stuff has in reality, which is causing harm to people.

Yes the whole thing is broken and stupid, but it's a question of whether this is the right solution.

@gregkh @ljs @joshbressers @mcepl @mort @vbabka People were "abusing" the system, so you turned "abuse" to eleven. Average CVE quality was better before.

@ljs okay, lemme get this straight,

You where arguing with Greg about the definition of vulnerability. Greg says his use refers to the CVE.org definition. You say your use of "vulnerability" refer to "demonstrably exploitable vulnerability".

At this point, since the topic is about CVE and when should a "vulnerability" get assigned a CVE number. I take it to mean you think only "demonstrably exploitable vulnerability" should be assigned a CVE number.

From your new response I take it that this was never your intent?

@shironeko The issue is that there's a huge uptick in CVEs because Greg is assigning them to anything with a fixes tag with not much filter on top of that.

Actually you could pretty much assign a CVE tag to every commit in the kernel because you know 'unknown bugs'. Something to keep in mind.

The issue are the downstream effects of this sudden uptick because customers of LTS kernels expect 'CVE patches to be ported'.

But all that has to be checked for stability as these patches often lead to instability...

Yes the fact that before people were treating CVE as meaning something other than it means was incorrect, and it got abused I'm sure, but the question is whether adhering to the letter of the law about what they are, knowing the downstream effects, is a good way to deal with this.

So the whole point is that people shouldn't take CVE to mean demonstrably vulnerable.

But opening a fire hose at them is maybe not how you should do that.

@ljs I see. So what is your proposed solution? On one side we have massively under-reported security issues and bogus reports and security theater, on the other side we have people footgunning themselves with a 12 gauge and absolutely refuses to stop.

@shironeko keeping things as before, with policy being bugs are bugs.

If people want to be stupid about CVEs let them :)

This approach has made the situation worse.

And really, do you think 'reporting' commit messages for a million things the vast majority of which will never be vulns will address any under reporting?

The ultimate solution is for customers to be informed about what CVEs are and are not and to use an alternative mechanism.

Perhaps this tidal wave will cause that to happen, but I just think of friends working at enterprise kernel companies whose lives have just got a lot worse.

Which is the only reason I'm commenting honestly!

@shironeko btw you are obviously in good faith so apologies for comment on that. I am totally fine with people (vociferously) disagreeing with me.

only issue is with those who are just having a dig or something, and just block as life's too short. So I misinterpreted you - sorry about that!

@ljs @mcepl @mort @joshbressers @gregkh @vbabka Yes, workloads have increased for enterprise distros (I'm directly affected). But blaming that on GregKH I think is shooting the messenger. Enterprise distros have ALWAYS had a duty to evaluate what they are shipping or not shipping. If anything, the kernel CNA is doing a great job of highlighting exactly how many bugs there are in the kernel.

I proposed that distros could collaborate and got essentially zero response: https://lore.kernel.org/all/20240311150054.2945210-2-vegard.nossum@oracle.com/

@vegard @mcepl @mort @joshbressers @gregkh @vbabka you are doing God's work there honestly!

To me this is the clear way forward - finding some means of SENSIBLY identifying security issues at a granularity customers + regulators can understand and assess.

I think there may be an ongoing educational issue however with customers/govts thinking in terms of CVEs that might be a big stumbling block.

It's less shooting the messenger I think overall (and note, I made sure to always tag Greg in so he could respond!) than asking - knowing the inevitable downstream effects, is this a good way of doing things?

And as to whether it's an intentional effort to try to get this kind of policy change.

I think pretty much it is.

I hope that it ends up being a positive outcome, it's not encouraging that people didn't respond to you there though. But it's great that you made the effort, and I think eventually this is the way forward.

@vegard @ljs @mcepl @mort @joshbressers @gregkh @vbabka Yes, but traditionally, CVEs were for vulnerabilities, not ordinary bugs.

@ljs @shironeko
Just to correct a misconception here, the Linux CNA hasn't contributed to a huge uptick in CVEs.

So far in 2024 there has been published 17k CVE entries and downstreams are perfectly capable of filtering this information.

The issue is that enterprise distros are dealing with more CVEs in the kernel specifically, which is problematic from a compliance perspective.

@Foxboron @shironeko there's a huge uptick in linux kernel CVEs and it is causing significant downstream issues.

So I'm not sure what the misconception/correction is here exactly?

@Foxboron @shironeko I mean the issue is enterprise kernels, but given stable kernels are not stable that basically means 'anyone who needs an actually stable kernel'.

And yes it's because of regulatory/customer requirements around a misconception of what CVEs are.

This is the issue under discussion re: downstream pain. I'm not sure anybody's claimed people can't grep 17k things? It's caused a ton of noise too obviously.

So yeah again confused as to the misconception here.

@ljs @shironeko

Ah! I read the sentence as the Linux CNA caused a huge uptick in CVEs in *general*, as in all issued CVEs.

@Foxboron @shironeko ah yeah no haha it's not that extreme :)

I mean I am hoping the overall outcome of this is that people move on to a more sensible scheme for tracking demonstrable vulnerabilities.

Ah man, computing is such a mess sometimes haha