The Linux kernel giving CVEs to all bugfixes is sort of predictable

May 12, 2024

One of the controversial recent developments in the (Linux kernel) security world is that the Linux kernel developers have somewhat recently switched to a policy of issuing CVEs for basically all bugfixes made to stable kernels. This causes the kernel people to issue a lot of CVEs and means that every new stable kernel patch release officially fixes a bunch of them, and both of these are making some people annoyed. This development doesn't really surprise me (although I wouldn't have predicted it in advance), because I feel it's a natural result of the overall situation.

(This change happened in February when the Linux kernel became a CVE Numbering Authority; see also the LWN note and its comments.)

As as I understand it, the story starts with all of the people who maintain their own version of the kernel, which in practice means that they're maintaining some old version of the kernel, one that's not supported any more by the main developers. For a long time, these third parties have wanted the main kernel to label all security fixes. They wanted this because they wanted to know what changes they should backport into their own kernels; they only wanted to do this for security fixes, not every bugfix or change the kernel makes at some point during development.

Reliably identifying that a kernel bug fix is also a security fix is a quite hard problem, possibly a more or less impossible one, and there are plenty of times when the security impact of a fix has been missed, such as CVE-2014-9940. In many cases, seriously trying to assess whether a bugfix is a security fix would take noticeable extra effort. Despite all of this, my impression is that third party people keep yelling at the main Linux kernel developers about not 'correctly' labeling security fixes, and have been yelling at them for years.

(Greg Kroah-Hartman's 2019 presentation about CVEs and the Linux kernel notes that between 2006 and 2018, 41% of the Linux kernel CVEs were fixed in official kernels before the CVE had been issued, and the average fix date was '-100 days' (that is, 100 days before the CVE was issued).)

These third party people are exactly that; third parties. They would like the kernel developers to do extra work (work that may be impossible in general), not to benefit the kernel developers, but to benefit themselves, the third parties. These third parties could take on the (substantial) effort of classifying every bug fix to the kernel and evaluating its security impact, either individually or collectively, but they don't want to do the work; they want the mainstream kernel developers to do it for them.

The Linux kernel is an open source project. The kernel developers work on what is interesting to them, or in some cases what they're paid by their employers to work on. They do not necessarily do free work for third parties, even (or especially) if the third parties yell at them. And if things become annoying enough (what will all of the yelling), then the kernel developers may take steps to make the whole issue go away. If every bug fix has a CVE, well, you can't say that the kernel isn't giving CVEs to security issues it fixes. Dealing with the result is your problem, not the kernel developers' problem. This is not a change in the status quo; it has always been your problem. It was just (more) possible to pretend otherwise until recently.

(This elaborates on part of something I said on the Fediverse.)

Sidebar: The other bits of the kernel's CVE's policy

There are two interesting other aspects of the current policy. First, the kernel developers will only issue CVEs for currently supported versions of the kernel. If you are using some other kernel and you find a security issue, the kernel people say you go to the provider of that kernel, but the resulting CVE won't be a 'kernel.org Linux kernel CVE', it will be an 'organization CVE'. Second, you can't automatically get CVEs assigned for unfixed issues; you have to ask the kernel's CVE team (after you've reported the security issue through the kernel's process for this). This means that you have to persuade the kernel developers that there actually is an issue, which I think is a reaction to junk kernel CVEs that people have gotten issued in the past.


Comments on this page:

By Ian Z aka nobrowser at 2024-05-13 14:35:37:

the story starts with all of the people who maintain their own version of the kernel, which in practice means that they're maintaining some old version of the kernel, one that's not supported any more by the main developers

There is a hidden contradiction above. The story in fact starts with not supported any more by the main developers . If there were reasonable LTS versions of the kernel, distributions would use them. And there are some, but too few and far between.

-- Ian

By cks at 2024-05-13 16:16:00:

LTS versions of anything are a lot of generally thankless and grinding work. The main kernel developers are not obliged to take on this extra work just because people would like LTS versions of the kernel, no more than any project is obliged to do LTS releases and then support them for years and years. I'm honestly surprised that the kernel developers have any LTS releases, never mind one that goes back to the end of 2018 (that's longer than Ubuntu will give you free Ubuntu LTS).

With the Linux kernel as with any other open source software, we get (only) the support that the project decides to provide. People using software they get for free have no moral right to demand more than is on offer. That the Linux kernel has become quite important to the world and it would be nice to have more frequent and older LTS versions doesn't create an obligation for the kernel developers to do a lot of grinding extra work for free.

(I feel quite strongly that the importance of a project cannot create substantial extra obligations on the part of the people working on the project. We do not get to insist that other people take on more work just because their project got popular. In my view, this is a core fallacy at the heart of a lot of "software supply chain security" stuff, and I think things like the Linux kernel CVE handling are the tip of an iceberg of open source reactions to it.)

By Ian Z aka nobrowser at 2024-05-13 19:50:59:

With the Linux kernel as with any other open source software, we get (only) the support that the project decides to provide. People using software they get for free have no moral right to demand more than is on offer. That the Linux kernel has become quite important to the world and it would be nice to have more frequent and older LTS versions doesn't create an obligation for the kernel developers to do a lot of grinding extra work for free.

I'm not really arguing about moral rights, more about finding a workable solution; and I'm more interested in the viewpoint of a distribution maintainer than the end luser.

What is a distribution supposed to do, especially one like Debian which:

- is truly a mostly volunteer project (unlike the kernel!)

- releases "when ready" about every 2 years while there's a kernel release every 3 months

I don't know of a good answer, in the medium run maybe using kernels from Ubuntu but longer term that would possibly lead to a death spiral as users would feel it's not a "real" distribution.

So when I hear your insistence on the rights of developers, even though I agree in principle I'm afraid the end effect is that corps (like those behind the kernel now, and for a long time, plus Canonical) win, and volunteers lose.

Written on 12 May 2024.
« Where NS records show up in DNS replies depends on who you ask
Some ideas on what Linux distributions can do about the new kernel situation »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun May 12 23:23:23 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.