I'd really like to read a well researched article that sums up how Linux distros reacted to the massive influx of #Linux #kernel CVE that started ~half a year – both for their #LinuxKernel packages and their live-patching offerings.

But I guess that is an enormous amount of work that no media outlet in this world is willing to pay anyone for writing. 😕

Slide taken from @gregkh's "Why are there so many kernel CVEs?" talk he gave at OSS China yesterday (https://social.kernel.org/objects/c9979d9f-399f-428b-ac56-c41598076dfa ) #LinuxKernel

@kernellogger
Do most distros care? Don't they just rely on the kernel development community to fix security holes and then just pull and release the latest kernels when they become available? I guess bigger companies like Red Hat would want to get involved themselves and push CVE fixes upstream, but I'm sure many distros wouldn't do a thing?
@gregkh

@solarisfire @gregkh

"Don't they just rely on the kernel development community to fix security holes and then just pull and release the latest kernels when they become available": some do, but some (many?) do not; among them are Ubuntu and its derivatives, which quite a few times even managed to ship kernels with new releases that were EOL already -- and then also remained on it for months or years…

And for live patching it's not a simple "pull in the changes" at all…

@kernellogger @gregkh I think the number of distros that do modify the kernel in some way is relatively small (Although it's usually distros with a larger install base that do).

Sure RHEL, Ubuntu, SUSE, Fedora, and Clear Linux are known for applying their own patches to the Linux kernel or running custom kernels. But a lot of this is backported code from future kernels into older ones, and anything new they develop usually gets pushed upstream.

Live patching is a dark art...

@kernellogger @gregkh Very few CVEs have something to do with security vulnerabilities!

@pavel @kernellogger Yeah. The “every bug in the kernel is a security issue, because it affects (at the very least) availability” puts a huge burden on everyone downstream of the kernel team. According to Spender (of grsec), most of these automated CVEs can’t even be triggered, let alone exploited, and some actually exploitable bugs are missed by the automated CVE assignment.

Imho it’s active sabotage of the already not great CVE system.

@schrotthaufen @pavel

not getting into the "are all those #Linux #kernel CVE really appropriate" debate, but that aspect is one of the reason why looking closer would be *a good thing* and likely lead to interesting results.

@schrotthaufen @pavel @kernellogger CVE assignment is ANYTHING but automatic. All changes are reviewed by 4 people in different ways and we vote/discuss them all, in public. Anyone is welcome to help us with this review, it's only about 34 changes a day to keep on top of.

Yes, once we agree "this commit should get a CVE" we have tools to make the assignment and publish the notice in an automated way, but all CNAs have something like that (if they don't they are wasting a lot of time doing it by hand.)

@gregkh @kernellogger @pavel

> CVE assignment is ANYTHING but automatic.
Guess I misremembered the methodology you outlined some time ago, then. Thanks for clearing that up.

@schrotthaufen @kernellogger Could I get a pointer to Spender's message? I know something is very wrong with kernel CVEs, but having security person backing me up would be nice :-).

@schrotthaufen @gregkh @kernellogger Greg is misleading you. There are manual steps, but their criteria is "is it a bug" not "does it have anything to do with security".

@kernellogger @gregkh please add an alt text 🙌

@solarisfire @kernellogger @gregkh Eh Clear Linux barely patches the kernel (we patch some defaults etc and backport a few things from -next at times.. but very very light).. instead Clear Linux stays on current stable kernels very aggressive, while we provide the current last-two-LTS-kernels as well as an option. We update almost always within a day of the stable team releasing ... and we can do that because we barely patch things.

@fenruspdx @kernellogger @gregkh Oh cool, guess I got my wires crossed. I personally really like the aggressive approach to sticking close the the stable kernel 🙂

@pavel @kernellogger @schrotthaufen @gregkh I don't get how that's misleading. He didn't say anything to the contrary.

@solarisfire @fenruspdx @gregkh

FWIW, Fedora is also pretty close to latest stable and does not patch much (but a bit more that Arch Linux)

But I'm pretty sure your "the number of distros that do modify the kernel in some way is relatively small" claim is wrong. Debian, openSUSE Tumbleweed are also pretty close and do not patch that much, but for most others it's different.

@kernellogger @fenruspdx @gregkh I don't see how smaller distros have the resources to do CVE fixes or modifications to the kernel, when they can just use mainline and put development effort into other parts of the OS.

Sure distros like CachyOS replace schedulers and do performance tweaks, but they're not working on kernel CVEs alone surely?

A lot of the more security focused distros just sit on the LTS kernel.

Qubes OS is interesting in what it does with the Kernel.

@kernellogger @gregkh For Debian the new process has been really helpful and made our lifes simpler. Previously we had to collect the CVE references from various sources (MITRE CVE feed, cross checks with RH Bugzilla, oss-sec etc) and now we simply parse all the data from the cve-linux-announce feed.

The only thing that changed for users is that we no longer issue advisories with CVE summaries (like https://lists.debian.org/debian-security-announce/2023/msg00013.html), but now only list the CVE IDs. That would be too time-consuming...

@jmm @gregkh

Cool that Debian benefits. 👍

I guess Arch Linux, Fedora and openSUSE Tumbleweed also benefit or do not care much.

But it's likely different for all the others that do not follow stable or longterm kernels closely… 😬