Live data from Hacker News

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

openwall.com

321–330 of 578 posts

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

#321
post #298

Earlier quoted context omitted.

> the reporter should not be the one responsible for reporting separately to every single downstream of the thing they found a vuln in. Not "separately to every single downstream", there is the "linux-distros" mailing list for disclosures: https://oss-security.openwall.org/wiki/mailing-lists/distros This random blogpost from 2022 serves as a proof that disclosing kernel vulnerabilities to the distros list is a well-k…

Why is it the job of the kernel to notify the distros? Why isn't it the job of the distros to keep up on upstream security disclosures? Expecting a FOSS project to go track down all of its (millions of?) users seems like a very unreasonable expectation, and is well outside of their scope of responsibility. People have gotten so used to the Github flavour of free-labour, social-network-style FOSS that they've forgotte…

> Why isn't it the job of the distros to keep up on upstream security disclosures?

They can't, because (responsible) security disclosures are private, _not public_. That's the whole point of the system: notify the developers in private ahead of time (usually 30, 60 or 90 days) so they can write, test and roll-out the fixes before you release the info to the whole world. This is to minimize the time between when bad actors gain access to the exploits vs. when users install the patch. So "keeping up on security disclosures" cannot ever be a 'pull' process.

Usually the maintainers of the big distros are part of (private) security mailinglists and receive such info. Just not in this case it seems.

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

#322
post #316

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.

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 deeper issue at play here. You might say "well, there's no implicit chain of trust here". You might be right, but is that really the most effective way of doing things? Of course Linux is Use it at your Own Risk, but is there not a concept of "we as a collective community should get together and try not to drop the ball on some serious shit?"

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.

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

#323
post #116

Earlier quoted context omitted.

Yep, I'd be fine with that. My bank has insurance, and my money would be returned.

And what is the insurance in the Linux case, for which the analogy was being made?

Linux was informed properly, and the vuln was not disclosed until 30 days after the kernel was patched.

The real debate here is what went wrong with getting that info downstream, and whose responsibility was that?

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

#324
post #260
post #36

Earlier quoted context omitted.

Imagine how much quicker the distros would have reacted if they were given a heads up a month ago. But, sure, I guess kudos to this company for not being actively criminal, and merely bumblingly incompetent and overly eager to get their marketing pitch out the door.

to which distros? how do you ensure fairness? Do you report this to the maintainer of Red Star OS (north korea)? The kernel security team was given the heads up a month ago. At that point it is their decision.

There are channels like the distro security mailing list https://oss-security.openwall.org/wiki/mailing-lists/distros for this purpose.

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

#325
post #119

Earlier quoted context omitted.

Those groups care about whether millions of computers are vulnerable, likely including your computer. If "immediate public disclosure" was done in all cases every vuln would be exploited and patches would be much lower quality. Shortening the disclosure timeline might be a good idea, 90 days is starting to feel long.

Millions of computers are still vulnerable. Not-knowing about it doesn't mean the vuln isn't there :p

But now millions more people know about how to exploit it who didn't before. I don't see why you're struggling with this.

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

#326
post #119

Earlier quoted context omitted.

Millions of computers are still vulnerable. Not-knowing about it doesn't mean the vuln isn't there :p

But now millions more people know about how to exploit it who didn't before. I don't see why you're struggling with this.

You can't bully me into agreeing with you. Why are you struggling with that?

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

#327
post #31

Earlier quoted context omitted.

The disclosure was more about marketing than security. From the disclosure page: > Is your software AI-era safe? > Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem. [...] > [Try Xint Code] More chaos makes their product seem even more attractive.

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.

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

#328

Earlier quoted context omitted.

It's such a bizarre viewpoint. I wonder when Linus will see sense. IMO it's pretty obviously not a view that they seriously hold, it's just one of those technical justifications people come up with to avoid admitting something they don't want to admit - in this case that Linux has a poor security track record.

I think it's an extension of the premise that you should just be taking the whole stable tree with all its patches constantly, whether they're labeled as security fixes or not, because you can never really know for sure some bugs weren't security bugs. I don't agree with the premise, but I do think it's a sincerely held one.

The kernel begrudgingly admitted of the existence of LTS releases, they really don't like long-lived kernels and people not tracking at or near the latest release.

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

#329

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…

rmmod just tells you it's not loaded; you'd have to delete the module to prevent it auto-loading.

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

#330

Earlier quoted context omitted.

The kernel team has been at odds with the CVE process and the oss-security community about this stuff for many, many years now. It's a big part of why the kernel team established a CNA and started flooding CVE notifications; they don't believe that security problems are different than non-security problems, and refuse to establish norms or policies based on the idea that they are.

> […] they don't believe that security problems are different than non-security problems, and refuse to establish norms or policies based on the idea that they are. They believe there is no difference being able to get root and not being able to get root ? It seems to me that to-be(-root) and not-to-be(-root) are quite different.

No, they believe that almost all bugs in an operating system kernel are also likely to be security bugs. The ones which get domain names, POC exploits, and CVE assignments are the ones which were found by security researchers. But the bugs that get found and fixed by kernel developers regularly without fanfare are also very likely to be exploitable. It's just that nobody took the time to cook up an exploit chain. To kernel maintainers, it's silly to assign CVEs to just some of the likely exploitable bugs just because a security firm found them. So they decided to take the reigns and handle CVEs themselves, to ensure all potentially exploitable bugs are marked as such.
Post reply on HN