For Linux kernel vulnerabilities, there is no heads-up to distributions • Hacker News Board

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#221

Post by nubinetwork » Thu, Apr 30, 2026, 10:06 PM UTC

aduwah wrote: post #71

semiquaver wrote: post #7

> Note that for Linux kernel vulnerabilities, unless the reporter chooses to bring it to the linux-distros ML, there is no heads-up to distributions. Why would they imply it is incumbent on the reporter to liaise with distributions? That seems to assume a high level of familiarity with the linux project. Vulnerability reporters shouldn’t be responsible for directly working with every downstream consumer of the linux…

Especially since the reporter is explicitly asked not to notify the distro teams first. https://docs.kernel.org/process/security-bugs.html ```As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully unde…

I don't get why the initial reporter should have to do that legwork. The kernel maintainers should be doing that.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#222

Post by Skywalker13 » Thu, Apr 30, 2026, 10:07 PM UTC

Denvercoder9 wrote: post #217

Skywalker13 wrote: post #214

I have checked all the servers (bookworm, bullseye) that I manage, and none of them have the algif_aead module loaded. Seems not fatal to all non-patched systems.

Not having the module loaded doesn't mean you're not vulnerable, the kernel loads the module on-demand when it's needed. I tried the exploit on such a system, and it worked. However, not having the module loaded does mean that in normal operation you don't need the module, so the proposed mitigation of disabling the module is safe in the sense that it won't disrupt anything.

I don't know what exactly can load this module but the servers are running for many weeks and I suppose that if something will load this module, it stays loaded until the next reboot.. no ?

I tried to rmmod on all servers and rmmod always returns `ERROR: Module algif_aead is not currently loaded`, that's why I think it's fine. Of course I take a look on https://security-tracker.debian.org/tracker/CVE-2026-31431 for the updates.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#223

Post by esseph » Thu, Apr 30, 2026, 10:13 PM UTC

eaf7e281 wrote: post #104

jasonmp85 wrote: post #51

Earlier quoted context omitted.

Does it? Now that I see their name again in this context they're blacklisted for life.

Same. They do become famous, but not in a wholly positive way.

I used to think the context of the fame mattered. At least in the US, it does not.

Hell, Crowdstrike is still purchased.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#224

Post by judemelancon » Thu, Apr 30, 2026, 10:13 PM UTC

tptacek wrote: post #215

judemelancon wrote: post #207

Earlier quoted context omitted.

I think I must misunderstand. Are you saying that you upgrade and reboot every production system that you administer to apply each commit to the kernel (branch it's using) essentially immediately? That doesn't make sense to me for a few reasons, but I struggle to find a different reading that applies "upgrade and reboot on a moment's notice" to the "slipped into mainline linux" scenario. Kindly help me to do so.

No: your posture with respect to having to cycle servers is a super complicated subject and you address it both with process and with architecture (for instance: you can be blasé about things like CopyFail if you don't allow multitenant shared-kernel in your design in the first place). But no matter what process and design you have, if you're hosting sensitive workloads, you always have to be in a position where you…

Oh, I thought you meant "everyone" in a sense including actual human persons and the devices on their home network.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#225

Post by Denvercoder9 » Thu, Apr 30, 2026, 10:15 PM UTC

john_strinlai wrote: post #216

Denvercoder9 wrote: post #212

Earlier quoted context omitted.

Two things can be true simultaneously: the Linux kernel ecosystem should have done better at communicating this to their downstreams, and publicly sharing the exploit was irresponsible. It is not the responsibility of the initial reporter to communicate to distributions, but the fact that those responsible failed to do that, doesn't give everybody else a free pass.

> publicly sharing the exploit was irresponsible they did it in the established industry standard way that probably every single security researcher you can think of follows (for good reason, i would add). whoever did the marketing on "responsible disclosure" was a genius. tptacek says it much better than me: " "Responsible disclosure" is an Orwellian term cooked up between @Stake and Microsoft and other large vendor…

In my world, responsibility is not just checking a box of following industry practice. Responsibility, as Wikipedia puts it on their social responsibility page, is working together with others for the benefit of the community. And yes, sometimes that's a bit larger burden than would ideally be the case. It's an imperfect world, after all -- and let's not forget the disclosure as it happened also placed a larger burden than ideal on people scrambling to patch.

And it's not as if I'm asking for a lot of effort. One mail to the security team of a popular distro "hey, we have found this LPE that we'll release with exploit next week, it's patched upstream already in this commit, but you don't seem to have picked it up" would likely have been enough.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#226

Post by cozzyd » Thu, Apr 30, 2026, 10:15 PM UTC

sjpb wrote: post #128

SoftTalker wrote: post #40

Earlier quoted context omitted.

It's a local vulnerability at least. How many people do you let log in to your router? With the way linux is used these days, I'd guess the number of systems with untrusted local users is pretty limited. Even with shared hosting, you generally have root in your VM or container anyway. Unless this enables an escape from that? Still the risk that people who run "curl | bash" without care could get bitten, but usually i…

> With the way linux is used these days, I'd guess the number of systems with untrusted local users is pretty limited Things like HPC clusters are multiuser & don't entirely trust their users. If they did we wouldn't need users/groups/permissions etc in the first place.

Yes. Not even just HPC clusters, shared login servers are pretty common in academia. I manage several in our lab. Sure, we mostly trust the users against malice more or less but not so much against incompetence. A malicious vscode plugin would run rampant in this space.

And then there are users running claude-cli and friends who may just find it convenient to use a local root exploit to remove obstacles.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#227

Post by Denvercoder9 » Thu, Apr 30, 2026, 10:15 PM UTC

Skywalker13 wrote: post #222

Denvercoder9 wrote: post #217

Earlier quoted context omitted.

Not having the module loaded doesn't mean you're not vulnerable, the kernel loads the module on-demand when it's needed. I tried the exploit on such a system, and it worked. However, not having the module loaded does mean that in normal operation you don't need the module, so the proposed mitigation of disabling the module is safe in the sense that it won't disrupt anything.

I don't know what exactly can load this module but the servers are running for many weeks and I suppose that if something will load this module, it stays loaded until the next reboot.. no ? I tried to rmmod on all servers and rmmod always returns `ERROR: Module algif_aead is not currently loaded`, that's why I think it's fine. Of course I take a look on https://security-tracker.debian.org/tracker/CVE-2026-31431 for t…

> I don't know what exactly can load this module

Well, for one thing, opening an AF_ALG socket, as the exploit does.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#228

Post by john_strinlai » Thu, Apr 30, 2026, 10:17 PM UTC

lambda wrote: post #77

selectively wrote: post #68

Earlier quoted context omitted.

Researchers are under no obligation to engage in coordinated disclosure and are free to sell 0day for profit. Just fyi. Be glad it was disclosed at all. Be glad a patch was available prior to release.

If they want to be seen as responsible rather than opportunistic, then yeah, they should do a proper coordinated disclosure. Sure, they have no legal obligation to disclose, but we all also have no legal obligation to buy their services. Blacklisting bad actors like this is the right move to discourage this kind of behavior.

>they should do a proper coordinated disclosure.

they did a proper coordinated disclosure, following the industry standard 90+30 process. that is why the exploit dropped 30 days after the patch landed.

the kernel team should have communicated with their downstream about the importance of the patch. that is the kernel security team's responsibility -- and they are much better positioned to do that than crossing your fingers and hoping every reporter will contact every distro every single time there is a vulnerability.

there are very good reasons disclosure works this way, backed by a couple of decades of debate about it.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#229

Post by 0x0 » Thu, Apr 30, 2026, 10:19 PM UTC

tptacek wrote: post #215

judemelancon wrote: post #207

Earlier quoted context omitted.

I think I must misunderstand. Are you saying that you upgrade and reboot every production system that you administer to apply each commit to the kernel (branch it's using) essentially immediately? That doesn't make sense to me for a few reasons, but I struggle to find a different reading that applies "upgrade and reboot on a moment's notice" to the "slipped into mainline linux" scenario. Kindly help me to do so.

No: your posture with respect to having to cycle servers is a super complicated subject and you address it both with process and with architecture (for instance: you can be blasé about things like CopyFail if you don't allow multitenant shared-kernel in your design in the first place). But no matter what process and design you have, if you're hosting sensitive workloads, you always have to be in a position where you…

I find it curious to call someone dropping a weaponized root exploit before major distros or even LTS kernel git branches have patches ready "good guys". This could have been handled with much more grace.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#230

Post by da_chicken » Thu, Apr 30, 2026, 10:21 PM UTC

Denvercoder9 wrote: post #212

john_strinlai wrote: post #157

Earlier quoted context omitted.

i have no problem with disclosing a vulnerability 30 days after its patched in the thing you reported to. (in fact, for those unaware, this is the same policy that google's project zero uses: "90+30" https://projectzero.google/vulnerability-disclosure-policy.h... ) the real problem is: > It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. the report…

Two things can be true simultaneously: the Linux kernel ecosystem should have done better at communicating this to their downstreams, and publicly sharing the exploit was irresponsible. It is not the responsibility of the initial reporter to communicate to distributions, but the fact that those responsible failed to do that, doesn't give everybody else a free pass.

No, this was already timed disclosure. This is very common and widely accepted. 90+30 is what Google Project Zero uses, for example. The security researcher has met their ethical requirements already. This is entirely on the kernel's security team for failure to communicate downstream. That is their responsibility.

The thing is, malicous actors are already monitoring most major projects and doing either source analysis or binary analysis to figure out if changes were made to patch a vulnerability. So, as soon as you actually patch, you really need to disclose because all you're doing by not disclosing the vulnerability is handing the bad actors a free go. The black hats already know. You need to tell the white hats, too, so they can patch.