Live data from Hacker News

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

openwall.com

341–350 of 578 posts

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

#341
post #316

Earlier quoted context omitted.

It looks like the expected thing happened. The kernel devs patched the kernel. The kernel devs have a pretty known, straightforward stance in how they ship fixes for anything, because anything in the kernel can be a security problem. Distro maintainers can see kernel changes. Some distros aggressively track new changes. Others backport what they feel are relevant. Others don’t do either. Users pick what distro they u…

The fact that you had to take a whole paragraph to explain the contortionist arrival at something that isn't even really super clear after you explained it (you kinda pointed the finger both at end users and at distro maintainers simultaneously) and essentially boils down to "well, you as the end user need to be following kernel CVE's and can't trust distro maintainers to do it" does in fact indicate that there is a…

The real advantage of Microsoft is that there is someone you can sue!

Linux like every open source project is just a bunch of people who are YOLOing it. Not something you use for your fortune 500 critical mission infrastructure.

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

#342
post #302

Earlier quoted context omitted.

"Didn't go anywhere"? The kernel devs patched it! They patched it weeks ago! The kernel security team needs to communicate security problems in their own releases, because that is where the distros are already looking. Requiring the security researcher to do it is insane. Should a security researcher that identifies a vulnerability in electron.js need to identify every possible project using electron.js to communicat…

The kernel devs patched it! They patched it weeks ago FTFA: > I see that on the 11th of April 6.19.12 & 6.18.22 were released with the fix backported. > Longterm 6.12, 6.6, 6.1, 5.15, 5.10 have not received the fix and I don't see anything in the upstream stable queues yet as I write. I wouldn't go so far as to call this "the kernel devs patched it". Virtually none of the kernels that distro's are actually using toda…

None of this impacts disclosure norms. One important reason the clock starts ticking faster once any patch lands is that for serious attackers, the patch discloses the vulnerability. That's quadruply so in 2026, when many orgs are automatically pumping Linux patches through LLM pipelines to qualify them for exploitability.

But it's been at least 15 years since "reversing means patches are effectively disclosures legible mostly to attackers" became a norm in software security. And that was for closed-source software (most notably Windows). The norms are even laxer for open source.

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

#343

Earlier quoted context omitted.

To be clear, the vulnerability existed in Linux, not in Xint Code. It existed whether this group disclosed it or not. Knowledge of it and exploits may have already been bought and sold among various groups with various motives including crime, terrorism, or cyberwarfare who likely made good money off it if this happened. In that world, the vulnerability has more value to those who seek to exploit it for their own mot…

Yes, and that's why we have the responsible disclosure protocol. It wasn't correctly followed here.

There is no such thing as "the responsible disclosure protocol". There's really no such thing as "responsible disclosure" at all, but "the responsible disclosure protocol" is a term I have literally never heard before. (I've been a vulnerability researcher since the mid-1990s, for what it's worth.)

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

#344
post #57

For context, the author of the linked post, Sam James, is a Gentoo developer. Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Who knows how many shared hosting providers were hacked with this. It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. One would hope th…

The Linux kernel is not usable as a security boundary, so anyone who wants to do "shared hosting" and not be hacked needs to use something else, like gVisor or firecracker VMs The only important system that uses it as a security boundary is Android and there is mitigated by the fact that APKs need user approval, plus strict SELinux and seccomp policy plus the GrapheneOS hardening, and in this case the mitigations suc…

I thought that was the entire design goal of the Unix model, didn't it originate in the times when hundreds of users logged on to a shared mainframe? There are still public Unix servers like SDF out there. SELinux is just an extra layer so that if someone gets root (ex. due to an exploit in your setuid code or cron jobs etc) it's not game over.

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

#345

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 this exploit it's trivial to jump from one container to another neighbor container. I've tried it and succeeded. So containers don't protect you, only a VM.

> I've tried it and succeeded.

How so?

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

#346
post #86

Earlier quoted context omitted.

… I used quotes to wrap something that I was saying. I even called out that it was something I was saying, as a more accurate variant of what you’d claimed I meant.

and I prefaced my quotes with the statement "So I feel like the argument reduces into". I mean, idk what punctuation I'm supposed to use there that doesn't offend you, but I just figured we can all read words and it was clear that I wasn't saying you said that, but rather, as I read the argument it was reducable to that and I took issue with that potential reduction. The idea about the available exploit space and how…

You could try to make that case either way, but as has been pointed out by others all over this thread, the system we've landed on (90/+30) is industry standard after over two and a half decades of experimentation.

Anything else inevitably has worse for the public good.

Having spent that entire time and then some on both offensive and defensive teams, I assure you longer delays after notification do NOT decrease the overall risk to the public.

There's a reason we've landed where we have as a security community.

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

#347

Earlier quoted context omitted.

Not really confusing. Linux is a sacred cow. There would be a lot of people gloating if this happened to MS.

Microsoft has a long and sordid history of cheerfully doing anything they can to fuck everyone over just to make a few more percentage points of profit. Linux is a free kernel that literally revolutionized the computing landscape.

Yes, this is the sacred cow status being referred to.

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

#348
post #37

For context, the author of the linked post, Sam James, is a Gentoo developer. Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Who knows how many shared hosting providers were hacked with this. It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. One would hope th…

> It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Yes, this was clearly a marketing stunt to promote Xint code. I, for one, will never use Xint code and will advise everyone to never use it. To anyone working there: enjoy your 15 minutes, I hope this backfires right in your face.

I doubt it will and I hope it doesn't.

External security research happens for one of only a few reasons typically:

1) hobbyists who are learning or just like to do it for fun 2) bug bounties (good luck with those in most open source) 3) marketing for security companies 4) non-public research going to CNO/CNE

If you want to kill 3, the output of 1 will not come close to 4 and the public is NOT better off with fewer public bugs.

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

#349

The Bleeping Computer link below mentions a potential remedy until a patch is ready. https://www.bleepingcomputer.com/news/security/new-linux-cop...

This workaround only applies to kernels with the impacted code compiled as a module. RHEL, Fedora, and Gentoo (we use a modified Fedora config) all are configured to build this in directly. Without a patch or config change (as Sam from Gentoo was alluding to), those distributions remain vulnerable.

For compiled-in kernels you can also work around it without rebooting via apparmor, seccomp or SELinux at the least, there may be eBPF or other methods too.

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

#350
post #281

Earlier quoted context omitted.

that is basically how all large companies behave anyway. socialize the losses (bailouts, layoffs, negative economic impacts in the communities they reside, etc.) and privatize the gains.

> that is basically how all large companies behave anyway And do you agree with that behaviour?

nope
Post reply on HN