So CopyFail CVE-2026-31431 is a thing.

If you're on the Ubuntu platform, 26.04 is not affected. 18.04 through 25.10 are indeed affected, but no fixes are available.

If you're on another platform, check with your vendor for update availability.

@wdormann

If you're using an obscure distro like "Debian", you may not have a fix available.

@wdormann which would mean every Chromebook.

@wdormann

i have 2 debian 12, kernel 6.1.0-42-amd64 which are not affected.

1 debian 12 - kernel 6.1.0-38-amd64 affected, event with algif_aead unloaded

@randomized
Interesting that some Debian 12's are not affected, while a fully-patched 13 is affected. 🤔

@wdormann amusingly, it does not appear to be a thing on musl.

@rootwyrm @wdormann Likely just a limitation of that particular PoC

Or RHEL.
I suspect that some people use that?

@wdormann The fix for Debian for users who don't need algif_aead (i.e. most of them): rmmod algif_aead ; find /lib/modules -name algif_aead.ko -exec rm '{}' \;

@marshray @wdormann the PoC works against the kernel and I already tweaked it as necessary for musl.

What I'm seeing in musl is that it appears to be failing at step 3 with all suid binaries (I tried several,) possibly because they all set BIND_NOW, or because they don't link against the kernel.

@rootwyrm @wdormann https://hachyderm.io/@dalias/116490206427142497

@wdormann

It's even better, the suggested mitigation does not work on RHEL-family systems: https://x.com/grsecurity/status/2049610274840158481?s=20

While this vulnerability seems to be discovered using AI ("Xint Code"), I have to assume that they also let the AI decide how to do the vulnerability coordination as well.

• major builds are out as of this writing 😂
  
  No distros have official updates for CVE-2026-31431. Fedora 42 and newer have updates, but no official advisory or acknowledgement of CVE-2026-31431. So with them it's unclear if it's even intentional. Red Hat, Ubuntu, Amazon Linux, and Suse all have advisories as of now, but NO updates.

• disable the algif_aead module as a mitigation. 😂
  
  Bespoke distros like RHEL don't use a module, it's compiled into the kernel.

I can't figure out what the Xint Code angle is with this copyfail stuff. On one hand, yes, it is a true vulnerability that affects a LOT of Linux distros available. And they did submit the bug for fixing to the upstream kernel people.

BUT the CVE has only existed for a week. And NONE of the distros IN THEIR ADVISORY had updates available at the time that they pulled the trigger for publication of the shiny copy.fail website.

I struggle to think of how this even happens. In all my years of infosec, you're either on board with doing CVD (e.g. coordinating with the former CERT/CC) or you're not (dropping 0day). But this all fits bizarrely in the middle. The publication gives the guise that they did the right thing, (and please use our AI services). But at the same time, they clearly chose to release the vulnerability details and functional exploit before any distro had the ability to properly do anything about it.

Either these Xint Code (Theori) people have a hidden agenda or ulterior motive that we aren't aware of yet. Or they're just really bad at coordinated vulnerability disclosure. You pick.

If you're curious about IOCs for copyfail, look in syslog for:
NET: Registered PF_ALG protocol family
for attempts to exploit copyfail on systems that use the vulnerable code as a module. For systems that have the vulnerable code compiled into the kernel, like RHEL, you'll see this line on every boot.
And at least for this particular flavor of exploit, a wall-clock nearby:
process 'su' launched '/bin/sh with NULL argv: empty string added`
is an indication of successful exploitation.

But it's worth noting that the "process launched" stuff is merely what this one ITW PoC will leave behind. Other exploitation techniques do not provide the above.

As such, perhaps looking for alg: No test for authencesn is perhaps more useful for looking for evidence of the affected endpoint being used.

@wdormann
Ok for Ubuntu, but I can’t find the first one on RHEL 10, instead I have:
kernel: alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac(sha256-avx2),cbc-aes-aesni))

@patpro
RHEL will have NET: Registered PF_ALG protocol family in the log on boot, as it's built into the kernel.
Not as a kernel module.

@wdormann OK so in that case it can’t be seen as an IOC on RHEL, is that correct?

@patpro
Correct.
That's what I indicated in my post.

for attempts to exploit copyfail on systems that use the vulnerable code as a module

@wdormann Sigh, as nerd with a homelab working on really understanding stuff this chaos and lack of documentation doesn't help. From what your saying my main 4 distros are all impacted w no patches in sight. My distros, picked in part to mitigate single point of failure of an individual distro: Mint, MX, Kinoite (Fedora immutable), and Manjaro.

@CliffsEsport
All of those are vulnerable except for Fedora, if it has updates installed.
If you're the only user of these systems, then you have much less to worry about than multi-user systems.

@wdormann sidenote : I personally tested against several Amazon Linux 2023 (aged a few months to 2 days), all of them are immune to this exploit.
(default 'recommended' image, no tweaks)

@squalouJenkins
Hmm, that does not jive with what Amazon says

@wdormann thanks for this. I checked out from the website after I noticed the Claude Code sheen on the site and seeing discourse about the PoC.

Figured someone wanted to acclaim fame for chucking a few dollars in the token machine, and getting it 80% right. Now the actual smart people can figure out the rest.

@wdormann @CliffsEsport fedora was vulnerable to me (maybe not if a kernel got released in the last few hours but otherwise yes it’s vulnerable )

@letoams @CliffsEsport
Up-to-date Fedora (42 or later) are not affected at the time of publication (Yesterday).
At least on this Fedora 42 system, the kernel was built on April 23 and in stable 2 days ago. Not a few hours ago.

@wdormann weird,
I get the same result (error on .splice) on amzn out of the box as on my desktop after applying mitigation

@squalouJenkins
Oh, splice is a python error. Not that the platform isn't vulnerable.

Interestingly, though, even with a new-enough python version, it still appears as not affected (prompt for password).

Given that Amazon Linux 2023 is kernel 6.1.166 (package built on March 23), and the fix for CVE-2026-31431 didn't happen until 6.1.170.

Perhaps something other than a true fix is interfering with the successful exploitation? 🤔

@wdormann @letoams @CliffsEsport confirmed up to date Fedora 43 is also not vulnerable but not if installed kernel is before 6.18.22

@chillybot @letoams @CliffsEsport
Right, Fedora seems to be the odd one out in that they seem to actually be on top of kernel versions.

What went wrong with this case?

Theori appear to have only contacted the linux kernel devs with the vulnerability, as opposed to going the usual CVD route that includes all of the major Linux distros.

Why is this a problem? Since the linux kernel became a CNA, there has been a flood of CVEs for the Linux kernel. The Linux kernel devs' arguments is that any given kernel flaw could presumably be leveraged to behave as a vulnerability, and it's not worth their time to determine "vulnerability" or "not a vulnerability". Everything gets a CVE.

Now the case with copy.fail? It was indeed reported to the kernel devs. And it got a CVE. A single CVE buried in flood of all of the Linux kernel CVEs.

And it appears that every distro on the planet was blindsided by this proven-exploitable vulnerability because they were not given any warning. Or even any suggestion to pick this single CVE out of the sea of Linux kernel CVEs as worth cherry picking.

Much to the chagrin of the Linux devs, RHEL doesn't use up-to-date Linux kernels. They cherry pick CVEs to backport to their chosen kernel version. (e.g. the latest and greates RHEL 10.1 uses 6.12.0, which was released November 17 2024). And in this world where bad actors like Theori don't involve vendors in vulnerability coordination, and just about every Linux kernel bug gets a CVE, this workflow fails. Hard.

Good times...

@wdormann Thanks! After rereading my post, I didn't intend it as any criticism towards you, hope it didn't come across that way. Just frustration with the CVE & related ecosystem.

@CliffsEsport
No, none taken.

The CVE ecosystem is a mess. And even more so a mess when it comes to the Linux kernel.

This is a shining example of what can go poorly in such a world.

@wdormann This was one of the reasons I pushed so hard to standardize on a rolling release version; because it was easier to deal with reverting to a known good version with breakage than trying to keep track of all the CVEs with different distros and whatever kernel they are packaging for what release cadence for a particular flavor/variant/age/release/support.

I'm still behind, but an understandable behind.

@squalouJenkins
And interestingly, even downgrading to an older kernel (to ensure that nothing got backported into this otherwise vulnerable 6.1.166 kernel) still gives the same results. 🤔

@wdormann I get that this was supposed to be a huge ad for Xint Code but the sloppy disclosure really just makes them look incompetent 💀

@k8ie
Yes, it's clear that it was published as a "Look at us!" vehicle.

But their abysmally bad coordination put every Linux user on the planet at risk, and is clear evidence that they don't care about anybody other than themselves.

@wdormann I wrote about what happens when vulnerability triage (in a broader sense) fails under the pressure from the expected surge of LLM discovered triage in the link below.

I totally missed what you have highlighted here as a case where the CVE, CVD systems fail not because a vuln is not reported but because it is not appropriately (or accurately?) enriched and the report is subsequently lost in the noise.

https://codeberg.org/tzafaar/Buffers_overflow_into_policy/src/branch/main/briefing%20notes/geer-unmitigatable-surprise-llm-age.md

@aristot73
Unless something changes, it won't be the last time this happens with the Linux kernel. 😕

@wdormann cves turning into marketing vehicles for every company thats a cna is also undoubtedly creating problems in this vein

@wdormann And a CVSS 7.8 won't standout when only 8.0+ typically get patched by OS. LPE are very underrated by CVSS.

Unlike what the buffoons at Theori published as a "mitigation", the folks at Red Hat actually published a viable mitigation for CopyFail CVE-2026-31431.

Specifically, edit your grub (or whatever you use to load your kernel) configuration to have one of the following arguments:
initcall_blacklist=algif_aead_init
initcall_blacklist=af_alg_init
initcall_blacklist=crypto_authenc_esn_module_init

With such boot arguments to the Linux kernel, the affected bits won't be reachable.

@Viss @wdormann every AI vulnerability company wants to find something juicy, and have no idea how to coordinate the findings

@joshbressers @Viss
If only there were human beings out there who had any sort of experience with coordinating vulnerabilities... 😂

@wdormann @Viss I mean, in their defense we're not easy to find outside a very specific bubble

And we have historically been gigantic assholes

As mentioned earlier in this thread, the su corruption route was only one possible strategy to be used by this exploit.

Here's another variant of the exploit that doesn't have to rely on such things to achieve its goal.

For example, the simple escalate argument simply removes the password requirement for su'ing to root. There are other payloads also possible.

Such exploits will not have process 'su' launched '/bin/sh IOCs in the syslogs. Perhaps all that is relevant is the alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac-sha256-lib,cbc-aes-aesni)) part. But there's no evidence of what was done.

There's also a C version of it that works quite well. Even supports aarch64.

@wdormann @joshbressers @Viss I love it how people think that "coordination of vulnerabilities" is actually something that can be done these days. Think of just who uses the software in question, and who should, and should not, be on such a list to get a "early disclosure notification".

As I have said for quite some time now, all early-disclosure lists are leaks, otherwise why would your government allow them to be in existence?

Software, and specifically open source software, runs the world. So should the whole world be on that notification list? :)

@gregkh @joshbressers @wdormann @Viss So just to clarify: In your view, would it have been equally fine to announce without contacting the Linux security team?

@deftpunk @joshbressers @wdormann @Viss no one did contact the kernel security team before they announced this. It was nice enough that they sent us a bug report and we got it fixed and pushed out to the latest stable kernel releases. That's all I can ever hope for.

@wdormann The mitigation to block the modules on boot is good. There is one drawback tough - it requires a reboot. Something that may not be immediately feasible in every environment. On RHEL, this is, however, needed, as algif_aead is part of the kernel.

@alcastronic
"Good" is a weird way to describe something that only works on some distributions.

@wdormann did the initial CVE have a CVSS score and LPE written all over it?
The kernel patch I saw only says "revert to previous way of doing things"

@gunstick
The original (and current) CVE entry is merely the commit message.

Which is unintelligible nonsense for anyone other than a Linux kernel developer.

@gregkh @deftpunk @wdormann @Viss

It's going to be a wild couple of years

I do think you're right that the traditional disclosure model is gone forever

But this one feels different. It was pretty obvious this was going to be a big one. Most CVEs are extremely lame and will never lead to anything

But some are a big deal. And those can get drown in the great CVE garbage patch

I have no idea what to do about those though, especially in open source

@joshbressers @gregkh @deftpunk @Viss

I get it that a lot of the world uses Linux.

But what if...
In an alternate universe, before publication of the flashy copy.fail writeup with public exploit code, the vulnerability was (for example) reported to the linux-distros mailing list, where the major linux distros are present. And they could hear why this particular vulnerability might want to be on their radar more than the rest of the sea of Linux kernel CVEs? (Universality, reliability, to-be-published exploit code, etc.)

Would this alternate universe be:

@wdormann @gregkh @deftpunk @Viss

Do I think this would have helped? I'm willing to say it probably wouldn't have hurt. But if the players would have asked for a long embargo, that could have been bad

Not telling the kernel security team is super lame, that should be the minimum bar

@joshbressers @gregkh @deftpunk @Viss

The maximum embargo for said list is 14 days.

@wdormann @gregkh @deftpunk @Viss

I'm too far removed to know all the process now

4 days is pretty good, yeah

@joshbressers @deftpunk @wdormann @Viss Honestly, there was nothing "obvious" about this one being a "big one" compared to all of the bugs we get, and fix, on a daily/weekly basis in the kernel.

The ONLY thing different here from those bugfixes, was that someone made a web site, a simple reproducer, and announced it to the world. For 99.9% of the bugs we fix, that are reproducible like this, no one ever does that. That we know of...

In other words, this was just another Tuesday for us.

@wdormann @joshbressers @deftpunk @Viss Not ALL of the distros are on linux-distros. So that is one thing. The other being that I don't care what happens on linux-distros, for many public reasons I refuse to deal with them anymore, and strongly encourage no one else to do so either.

@joshbressers @gregkh @deftpunk @wdormann @Viss Here is my take. Just publishing it and letting people catch up, without the "disclosure" is ok.

What is not ok is spreading misinformation and trying to make yourself look bigger than it is, yelling "patch now" when no patch exists, etc

Yeah we need to patch. We know. That is a job for our tooling to tell us. Not the people getting social and possibly marketing clout out of it.

@Di4na @joshbressers @gregkh @deftpunk @Viss

Yes, the fact that the official advisory said Update your distribution's kernel package and Most major distributions are shipping the fix now when not a single distribution on the planet had an updated kernel package is evidence that the whole publication was a "Look at us!" vehicle, and everybody else on the planet be damned!

I can't say that it's a lie because I can't prove that they knew it was wrong.

Side wonder: Can something written by AI never be called a lie? 🤔

@gregkh @deftpunk @wdormann @Viss

I do wonder sometimes how many of those CVEs you file could be a privilege escalation with a proper reproducer

I'm sure it's not zero

@joshbressers @deftpunk @wdormann @Viss Loads of them.

@joshbressers @wdormann @deftpunk @Viss What do you mean, they told us, we fixed it, it got in some stable kernels, and so our work on the security team was done. The CVE team assigned a CVE after a while, and even gave it a CVSS score.

The fact that no distro popped up that used older kernel versions to do the real work to backport to older kernels seems to be everyone's major problem here. That is outside of the kernel security team's work entirely. So take it up with the distros that people are paying support for to do this for them?

And yes, Debian was vulnerable, that is not good, and once it was noticed people worked hard and quickly to fix that. Not bad for a community-based distro that no one pays for in my opinion.

@gregkh @deftpunk @wdormann @Viss

You said this wasn't reported to the kernel security team

From where I sit (and I'm not in the middle of this) it seems like if you plan to make a website and give something a name, tell the securiy team

If you're OK with the current process though I shall trust you on this, you're the expert, I'm just the peanut gallery

@joshbressers @deftpunk @wdormann @Viss the "announcement of a public web site and exploit" was not sent to the kernel security team. If you look at the timeline they published, they show what they sent the kernel security team and when, which seems to be correct to me.

@wdormann
With "good", I was referring to RHEL's proposal that requires a reboot to become effective.

@gregkh @deftpunk @joshbressers @wdormann @Viss How did 'The CVE team assigned a CVE after a while' work? I see the docs say it's the reporters job to tell the CVE team; but hmm that CVE assignment was ~3 weeks after the fix went in mainline - is there something that could help there? e.g. did linux-security give the CVE guys a nudge, or remind the original reporters they needed to do that?

@penguin42 @deftpunk @joshbressers @wdormann @Viss I honestly don't remember, and if I did, we don't publish who asked for CVE ids from us as that's generally not a good idea to do so (and is not a requirement for being a CNA).

@gregkh @joshbressers @wdormann @Viss so there's absolutely no middle ground? When there is clearly a bug with security impact, give the distros list a week notice (two weeks max, per their policy). If it leaks, outcome is no worse than not notifying distros. The researcher can even do it instead of the kernel. At scale (Linux!) this seems like a Pareto distribution: major distros cover disproportionally most users.

@wdormann weird because I had a successful test on up to date f42 yesterday …

@letoams
Got a snapshot that you can revert to?
I'd like to see the evidence (along with showing the current kernel version).

@zmanion @joshbressers @wdormann @Viss Why is linux-distros somehow "special" enough to get these types of announcements and not everyone else? How exactly would you explain that to your favorite government entity?

The CEO of Theori / Xint has a damage-control thread explaining why they chose to release the vulnerability details in a way that left all of the Linux distros in the dark.

TL;DR: With AI in the mix, the old way of coordinating vulnerabilities doesn't scale anymore.

@wdormann TL;DR: lame AI excuse award for laziness and incompetene

@ReneRebe
Yeah.

I mean, fine, you can say that Qualys is doing it this way too. But TBH, I got the impression that the Qualys example was found after the fact when everything blew up, as opposed to purposefully modeling your workflow after Qualys.

But the real red flag is this:

Patch first. Update your distribution's kernel package to one that includes mainline commit a664bf3d603d — it reverts the 2017 algif_aead in-place optimization, so page-cache pages can no longer end up in the writable destination scatterlist. Most major distributions are shipping the fix now.

No human being on the planet would have concluded such a thing. Anyone with half a wit would know for a fact that no distribution had updates at the time that copy.fail was published. Not even one of the FOUR DEMO DISTROS IN THE PAGE ITSELF. 🤦‍♂️

This all was AI-driven YOLO attention seeking, and the linked thread from Brian is just damage control.

@wdormann Hi Will. Shouldn't/couldn't the Linux security team have imposed an embargo and coordinated with the distro's?

@aristot73
In an ideal world, yes.
But they're not interested in doing such things.
For reasons, presumably.

@wdormann wow.... 🤦‍♂️

@wdormann

"From that prior experience, we assumed distros had ways to learn about upstream security-critical bugs. We never needed to notify them explicitly before."

Which roughly translates as : "We know nothing of how the linux dev ecosystem works and do not care."

@wdormann the thing I don't get about this whole situation is, if they really are genuine in their plight to make the world a better place (which doesn't not preclude making "paid for" products), I don't see why they can't raise awareness of what they perceive is a critical issue without just dropping the PoC. They're mutually exclusive and plenty of people have successfully done exactly that, while holding back the exact details until later. Sure, other people will poke if given vague direction but the damage and panic is done by making it instantly and easily achievable.

Even with the context continually being given and expanded on, it still feels like nothing more than an excuse for attention to "buy our awesome product" through thinly veiled bragging rights.

@wdormann if these ai systems are so fast, cheap, and omnipotent, it seems like they couldve used "xint" to determine that downstream hadn't patched yet🤔 ai changes the equation, okay fair enough. we were also completely naive, our powerful ai kept us out of the loop🤨

@gregkh @wdormann @Viss

This post got into my head. I think you're right, the days of coordination are over

So I wrote it down
https://opensourcesecurity.io/2026/05-vulnerability-economics/

@joshbressers @gregkh @wdormann @Viss Nice, just my conclusion: if embargoes ever made sense, that time is over.

#curl notifies distros about upcoming CVEs, but a good part of curl applications will notice them a year (or ten) from now. Maybe. They probably just update to a newer version without reading the CVEs. 💁🏻‍♂️

(I hold special views about LTS releases with hand-picked patches - but maybe another time😌)

@joshbressers I will quote this in many presentations in the future because it is so true:

"The Kernel assigns lots of CVEs. They say it’s because they don’t really know how the Kernel is being used, so they err on the side of caution. Companies hate this because they have to deal with a lot of CVEs. Does the Kernel do this because it’s easier or do they have some sort of secret nefarious reason? Probably because it’s just easier and they have zero downside to disclosing and moving on. "

@icing @joshbressers @gregkh @wdormann @Viss All these arguments may or not be true, but I still do not quite see why - for copy fail - downstream open-source projects such as Debian were not notified during the embargo time?

@uecker @icing @joshbressers @wdormann @Viss There was no "embargo time". And again, Linux does not notify anyone because if we did, we would have to notify everyone.

It's as if no one reads my long posts about this topic explaining it all...

@joshbressers @gregkh @wdormann @Viss aren’t the "users" missing from the equation? In the end we do it for them and we need them to fix their systems, and we need it to be easy for them to fix their systems.

Also there are a lot of open source companies, whether software developers, support providers, integrators, administrators, or a combination.

Also governments which are users, regulators, contributors…

Economics are hard indeed

@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?

@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

@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.

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

@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-

@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.

@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.

@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

@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

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

https://gcve.eu/bcp/gcve-bcp-03/

@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

@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)

@ancoghlan

I'm not opposed to a company employing people at a given project to get some advanced notice

The devil is in the details, but I think in many cases it could work

@joshbressers @ariadne @gregkh @wdormann @Viss @andrewnez @Di4na (that’s the joke)

@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.

@siddhesh_p @gregkh @wdormann @Viss

Every project is really its own ecosystem

I think glibc does a really good job with CVEs

But I suspect if you go from 12 a year to 12 a month your process will have to change

It's possible you would adopt the "give it a CVE and move on" approach, or because there is so much attention from the distros you could get some extra help to deal with the volume

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

It's a very valid question that gets asked quite a bit

It *seems* like it's something should work. But sadly it doesn't

@gregkh @joshbressers Of course companies hate it.

Plenty for bad reasons.

But also for reasonable ones: Who can afford to reboot all machines every few days? 6.18 averaged a stable release every ~5.6 days, 6.12 averaged one every ~6.15 days.

If you continually ask for unrealistic things ("All users of the xyz kernel series must upgrade." > once a week), folks *have* to stop listening after a while.

What do you expect folks to actually do with prod systems?

@gregkh @joshbressers What you are describing is called a "negative externality".

sounds like software distributors now get to experience what most users used to experience: all of a sudden a problem that someone else knew about but we didn't needs to be figured out and dealt with urgently. disclosure procedures made the situation more comfortable for the distributors, but not so much for the users, who got the whole story at once and had to react promptly, instead of as a developing story. maybe this new development levels the playing field a little, making things really inconvenient for everyone. that sort of moral justice is not much of a consolation, alas 😕

CC: @gregkh@social.kernel.org @wdormann@infosec.exchange @Viss@mastodon.social

@buherator @joshbressers @gregkh
I wouldn't call it an externality, since it only affects those who use Linux.

It's not like you had a perfectly peaceful software ecosystem and suddenly someone started making Linux, which makes you suffer even if you don't use Linux.

No, it only hurts you if you do use it, and the alternative is no Linux at all.

@gregkh @joshbressers It's kind of a shame how fast CVEs have become meaningless. There's so much compliance overhead associated with them that goes nowhere.

@ra6bit @ariadne @joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na And then we could have spectacular arguments about what to assign those vulnerabilities where finders argue for maxing out everything even when the vuln is unreachable in practice. (*screaming from the curl maintainers in the distance*)