Top
Best
New

Posted by ori_b 14 hours ago

For Linux kernel vulnerabilities, there is no heads-up to distributions(www.openwall.com)
Recent: Copy Fail - https://news.ycombinator.com/item?id=47952181 - April 2026 (466 comments)
432 points | 332 commentspage 2
lrvick 9 hours ago|
Was not disclosed to stagex, and I expect a lot of linux distros. Thankfully we were already on kernel 7.0 so not impacted
2OEH8eoCRo0 5 hours ago||
Seems silly. How many distros need to be notified? There are hundreds.
JasonHEIN 10 hours ago||
huh somehow seeing people not using ai to work is like wow moment which i cherish a lot these days
lionkor 7 hours ago|
You're likely in an echo chamber! Barely anyone I know uses AI as more than a fallible tool.
VladVladikoff 10 hours ago||
Hey Xint Code / tylerni7 <https://news.ycombinator.com/threads?id=tylerni7>, maybe you should improve your disclosure process as well? Maybe make it mandatory for users of your tool?
john_strinlai 10 hours ago||
they disclosed 30 days after the patch was merged in the thing they reported to.

its the same disclosure policy as google's project zero, and several other major players, so you should probably be trying to ping a lot more people

reporters should not be responsible for finding out and individually reporting to every downstream consumer. blame the kernel security team, who is in a much better position to coordinate notifications to individual distro security teams.

VladVladikoff 7 hours ago||
In the original thread they admitted multiple times that they rushed it out for marketing reasons.
john_strinlai 7 hours ago||
as an explanation for the misnumbered redhat version.

the disclosure itself followed a normal timeline, which you can view at the bottom of their blog post.

tptacek 9 hours ago||
The security research community would run you out on a rail if you tried to take a successful research product and attach mandatory disclosure norms to it.
VladVladikoff 7 hours ago||
Couldn't the product itself disclose to the vendors?
tptacek 7 hours ago||
No firm in the world would use a vulnerability research product that automatically disclosed to vendors.
Skywalker13 8 hours ago|
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.

Denvercoder9 8 hours ago||
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.

Skywalker13 8 hours ago||
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.

Denvercoder9 8 hours ago|||
> I don't know what exactly can load this module

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

bombcar 4 hours ago|||
rmmod just tells you it's not loaded; you'd have to delete the module to prevent it auto-loading.
TacticalCoder 7 hours ago||
> I have checked all the servers (bookworm, bullseye) that I manage, and none of them have the algif_aead module loaded.

But only Trixie (and testing/Sid) are patched (as I type this).

On Bookworm (and Bullseye), you want to add the module to list of blocked modules. It's a one-line change.