So CopyFail CVE-2026-31431 is a thing.

[gregkh@social.kernel.org]

@corsac @joshbressers @wdormann @Viss Linux makes it very "easy", just update your kernel to the newest version. What's preventing that from happening for your systems?

[corsac@mastodon.social]

@gregkh @joshbressers @wdormann @Viss End users in IT systems either large or small corps, administrations etc. don’t just get their kernel from kernel.org and rebuild them. They use kernel binaries, usually from a distribution or maybe rebuilt from by their IT.
Most the various containers runtime similarly run on distro kernels.
Not sure the ratio of running kernels coming straight from kernel.org but I’d guess small

[uecker@mastodon.social]

@gregkh @icing @joshbressers @wdormann @Viss "it is not easy to decide who should be on the list, so we can not even have list with Linux distros hat should obviously be on list" argument seems rather unconvincing though.

[wolf480pl@mstdn.io]

@joshbressers
As a user, I don't care if my software has vulnerabilities, only if it has ones that the attackers know of.

But if vulnerabilities are so plentiful, what's the chance of a security researcher finding the same vuln that an attacker would find? Is the idea that findng & reporting vulns makes us all more secure still true?
@gregkh @wdormann @Viss

[thesamesam@social.treehouse.systems]

@wdormann Don't forget that the kernel didn't coordinate any sort of backports being ready for stable.

The kernel people obviously did coordinate the mainline fix as they communicated the report they received to the maintainer.

If LTS branches can't get fixes like this, just discontinue them.

The only reason we got releases with fixes in is because Eric Biggers stepped up when he saw nobody was doing it.

[di4na@hachyderm.io]

@joshbressers @gregkh @wdormann @Viss i have thoughts
1. It probably was like that before LLMs even. Look at your dependency reports for all the projects your company have. It has not been clean in nearly a decade. Not because too many vulnerability. Because too much FOSS. These were tools (and compliance) built with the vendors world of the 90s/early 00s in mind.

2. I think we can go far faster. Faaaar faster. Our tooling is crap, noone use it and we have not even tried. But i think we have different toolings and going faster in mind. See the github "want" list from @andrewnez for one take on it. I have more.

3. There are systemic problems there that can be looked at systemically. It will not be a quick fix but eh. We have been living with this for years, we don't need a quick fix.

4. The whole idea of vuln feed is probably dead though. It never made a lot of sense in a language package manager enabled world anyway. Only in this 90s/00s view.

5. Part of going faster is probably going to be a software engineering organisation of work problem. The SDLC, the Agile and the whole way we produce code in commercial software is probably the biggest problem here. It is fundamentally inefficient, probably for systemic reasons (i have some theories there, with some evidential support from research). But that links to the rest.

[di4na@hachyderm.io]

@gregkh @joshbressers @wdormann @corsac @Viss sooo many things.

But they are not inherent to the kernel. Most software producing org are organised to slow down deployment and delivery. People are scared of changes. And the tooling to make changes less scary is ... Not well invested into.

[di4na@hachyderm.io]

@gregkh @joshbressers @wdormann @corsac @Viss

Here is a small thing to think about.

The whole point of cve is to allow you to not update.

That may sound strange but think about it. The whole point is that as long as we do not reveive a massive panic alert from this limited source, then we do not have to update.

This is why it has become so central. Orgs are fundamentally wired against updates.

[ariadne@social.treehouse.systems]

@joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na it would be cool if vulnerability databases could synchronize with each other using activitypub or similar

[corsac@mastodon.social]

@Di4na @gregkh @joshbressers @wdormann @Viss that’s call risk management and it’s not necessarily a bad thing. And people have been (and still are) burned by updates. I don’t think it’s a good reason to never update but I can’t blame people for being cautious, especially since I’m not in their shoes and don’t know all their concerns

[ra6bit@infosec.exchange]

@ariadne @joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na If only we had some sort of... "Open Source" Vulnerability Database.. as a clearing house. Some sort of non-profit org could maintain it probably

someone should get on that

-waits for attacks from angry squirrels-

[le_suisse@social.gerbet.me]

@ariadne @joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na The Vulnerability Lookup folks are working on something close

GCVE-BCP-03 - Decentralized Publication Standard

Decentralized Publication Standard Version: 1.5 Status: Published (for public review) Date: 2026-03-10 Authors: GCVE Working Group BCP ID: BCP-03 This guide is distributed under CC-BY-4.0. Copyright (C) 2025-2026 GCVE Initiative. Introduction This document describes the decentralized publication model that allows GNAs to publish their vulnerability information directly, without relying on a centralized system. It also outlines the access methods GNAs use to distribute published vulnerabilities through various mechanisms.

(gcve.eu)

[di4na@hachyderm.io]

@corsac @gregkh @joshbressers @wdormann @Viss I mean, yes, this is kinda my point above But also, they are also burned (and not less) by not updating. It is just not considered the same way in the stats and not seen as the same thing. Because not updating is always in the past *after* the incident

[ancoghlan@mastodon.social]

@joshbressers The one case where downstream vendors can still get advance notice? When they're actually directly employing people on the project level security response teams (which is a potentially double edged sword from the project's side, since it means volunteers don't have to do security response without compensation for their time, but risks bringing those dubious corporate incentives you mentioned up to the project level)

[corsac@mastodon.social]

@Di4na @gregkh @joshbressers @wdormann @Viss unfortunately I think there a lot of people (IT services) having been burned more badly by updating than not updating. I still think people should do it (especially because mass vulnerability exploitation seems to usually happen for stuff fixes months ago) but still just blaming them for not doing doesn’t work. Not sure it’s really the Linux kernel the concern here though.

[di4na@hachyderm.io]

@corsac @gregkh @joshbressers @wdormann @Viss I think it is not true, but it is because we do not burn people for not updating

[siddhesh_p@mastodon.social]

@joshbressers @gregkh @wdormann @Viss this may be true for the Linux kernel, especially with the resignation that the Linux CNA will assign a CVE for most reports, but it doesn't align with my anecdotal experience as glibc CNA. It's likely because we have significantly less volume (12 so far this year, with roughly twice as many reports) and we tend to be picky about what we assign to a CVE id to.

I'd argue that the kernel is special here and doesn't represent the ecosystem.

[joshbressers@infosec.exchange]

@Di4na @gregkh @wdormann @corsac @Viss

Yeah, this

Which then goes back to your comments about our tooling being horrid and makes updates slow and painful

[joshbressers@infosec.exchange]

@ra6bit @ariadne @gregkh @wdormann @Viss @andrewnez @Di4na

Every single time an open source database has been tried it has failed spectacularly. For whatever reason the consumers of that data take and give nothing back then the project dies

[joshbressers@infosec.exchange]

@Le_suisse @ariadne @gregkh @wdormann @Viss @andrewnez @Di4na

Yes! The #GCVE folks are really on the ball about all this

I would be willing to bet a milkshake they will be one of the more authoritative sources in the future