Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

openwall.com

Post reply on HN
Print view View original

461–470 of 578 posts

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

#461

Post by Dylan16807 »

maybewhenthesun wrote: post #380
SOLAR_FIELDS wrote: post #309

Earlier quoted context omitted.

Agree, but then where does the accountability lie? Presumably with the kernel maintainers themselves, correct? SOMEONE dropped the ball here. If we can't point the finger correctly, that seems like a problem in of itself.

The distros dropped the ball. imho. One of the (main) tasks of the distro is watching the changed of you upstream packages for important changes. This is slightly complicated by the fact that the linux kernel considers all bugfixes security fixes, so it's quite a lot to read it all. But that's life. The kernel developers are not wrong as it's nearly impossible to be sure a bug in the kernel is not (also) a security p…

The patch wasn't even listed as fixing a bug.

"There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly."

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

#462

Post by Dylan16807 »

steve1977 wrote: post #413
lillecarl wrote: post #409

Earlier quoted context omitted.

Human beings

Qualified by what?

Are you implying it requires expertise to figure out the ten (plus or minus a factor of two) biggest distros? I think most people that understand the context of the question can figure out pretty similar lists.

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

#463

Post by hnfong »

SOLAR_FIELDS wrote: post #322
akerl_ wrote: 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…

> In terms of something actionable, and maybe someone more well versed in how the distros work can tell me why this is a bad idea, but shouldn't there be a documented process and channel for critical CVE's to be bubbled out to distro maintainers who then have some sort of SLA for patching them and sending them downstream to end users? Perhaps incentives are not aligned to produce this outcome.

Who decides who is a trustworthy distro maintainer? In the open source world everyone is equal, no favorites are chosen. If your point is that the distros backed by companies making at least $x million revenue a year should get priority disclosure... pretty sure somebody will take issue with this.

And it's not like a hypothetical issue either. Given the high stakes, bad actors are highly incentivized to masquerade as some small scale niche distro until they get their effectively free zero day CVE.

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

#464

Post by anthk »

morpheuskafka wrote: post #344
lifis wrote: post #57

Earlier quoted context omitted.

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.

SDF used NetBSD. In the 90's they switched for a while for RH under X86. Worst era ever, very insecure. Now they use NetBSD X86-64.

On Hyperbola GNU/Linux, they will shift into OpenBSD, they got fed up with the corporate slopware (and propietary Linux became). They will still make Hyperbola BSD GNU-license compatible, from core to the userland tools.

In my case, I wish Emacs and GNU developers embraced plotutils and left out Gnuplot (is not GNU at all; worse, it conflicts with the GPL) and made Texinfo independent of LaTeX to produce PDF and HTML files with equations. Groff + troff+pic+eqn already do that, no Texlive needed. So can mandoc under OpenBSD, no magic needed, everything under few MB's.

Texlive it's huge (full instal it's over 7GB) and the so-called free FSDG is not 100% free, at all. With just that GNU Emacs would be truely GNU-standalone, relying on GNU tools for plots under Emacs' Calc and Texinfo books exported into PDF. A good plus for security.

Once you get that working, the rest would just follow their way. Also, GNU Hurd being developed with propietary LLM's/SAAS it's a disgrace against what GNU stands for too. They can go back to the right path, but they need will, for sure.

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

#465

Post by QuiEgo »

akerl_ wrote: post #332
SOLAR_FIELDS wrote: post #322

Earlier quoted context omitted.

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…

To be more blunt: if you’re paying for a product, the vendor owes you whatever things they committed to. If you’re a Redhat customer and your agreed SLA with Redhat for this kind of security fix was passed by, go be mad at Redhat. (I don’t think Redhat is bad here, they’re just the vendor most known for a commercial offering from the lists here. I would say the same thing about Ubuntu Pro) Otherwise, it’s on the end…

Agree on this so hard. Why does everyone expect instant patches and SLA-like infrastructure from unpaid volunteers?

If you want that, buy a commercial distro of linux, or use Windows. That's a huge part of Microsoft's value proposition to enterprise - they pay people to stay on top of security patches for you. Same with RedHat and others.

Expecting anything of unpaid volunteers is unreasonable.

> THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

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

#466

Post by lizknope »

tremon wrote: post #302
da_chicken wrote: post #265

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…

I'm on Fedora 43 and tried to hack myself with the python script. It didn't work on kernel 6.19.12-200.fc43.x86_64 which has a build date of April 12, 2026

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

#468

Post by systems_glitch »

nirava wrote: post #392
pamcake wrote: post #351

Earlier quoted context omitted.

Look, if they namedrop specific distros in their announcement (marketing) blog post as affected, I think a heads-up before publishing that is appropriate and expected. I don't think they would have gotten as much flame if it weren't for how the RHEL 14 mention and such were put. This is a security company with a professional(?) communications department banking on pointing fingers at distro maintainers. We are not ta…

Exactly. Any security person absolutely KNOWS that the distros are still going to be vulnerable. They're exploiting this process loophole to knowingly cause chaos and gain notoriety. At this point this is not really white-hat/ethical hacking anymore. Ofc the kernel-distro security loophole is stupid and should be patched ASAP, but that doesn't absolve this company of wrongdoing.

We all know that's what it is, I don't know why people aren't willing to just say it.

It has a domain, it has a logo, they were going for maximum impact because it's their business.

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

#469

Post by anthk »

nromiun wrote: post #420
anthk wrote: post #396

Hyperbola GNU was save because they still use Python 3.8 for both political and stable reasons.

Python 3.10 is only used for the exploit. You can easily rewrite it for 3.8 as well. The vulnerability itself does not require Python at all.

True. At least I can disable the module in Syslinux as a workaround.

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

#470

Post by akerl_ »

spookie wrote: post #458
tptacek wrote: post #275

Earlier quoted context omitted.

It is literally not the vulnerability researcher's problem to solve or address this.

Brother, it is a simple email to a mailing list. They are professional security researchers, they must know this is the way it is done in the ecosystem. Kicking the can around leads nowhere.

Have you considered that maybe it’s not the way it’s done?

It’s certainly a thing some people do. But there is not a unified consensus on how to handle vulnerabilities. Different security researchers (or, in fact, the same researchers releasing different findings) can and do take many different courses of action.

Post reply on HN