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

501–510 of 578 posts

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

#501

Post by baggy_trough »

staticassertion wrote: post #438
baggy_trough wrote: post #247

Earlier quoted context omitted.

What is your interpretation of why Greg KH released a version of 6.12 with this fix in it today, other than to help distributions avoid this vulnerability?

Why would he ever... not release a new version? I don't get what you're trying to say - I'm stating Greg's explicit policy on the topic. If he did something outside of that policy, that wouldn't change anything.

If he doesn't believe in the "concept of vulnerabilities" then it is remarkable that he released a 6.12 targeted on this one fix. Why would he do that otherwise?

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

#502

Post by franktankbank »

xeeeeeeeeeeenu wrote: post #2

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…

> but apparently it's the responsibility of whoever finds the vulnerability

Aka a white hat professional which should be a prized function richly rewarded. Do you really want these things to be calcified into a government function?

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

#503

Post by harshreality »

Avamander wrote: post #496
worthless-trash wrote: post #368

I believe this is the side effect of having upstream manage the CVE process. The distros dont get any involvement until release, welcome to the suck.

This is the effect of "every vulnerability is a bug" and "we can't rate the severity of any vulnerabilities". Which very clearly results in "bugfixes" (security patches) not making it everywhere in time because it's just simply ridiculous to ask for each downstream consumer to rate the severity of everything on their own. It's easy to shit on CVEs, some even put out shit CVEs, but at the same time contribute absolute…

They can't. Linux has too high a profile. Any additional "in group" that had access to embargoed critical security information would have a much higher chance of being compromised.

The solution is not to tell more people that patch xxxxxx is a critical security bugfix that needs distros to roll new kernel versions immediately.

Major vendors (all the cloud providers) will have security teams that can have the bug mitigated in a few minutes once they're notified.

For everyone else...

Part of the solution is that distros need to stop believing that their distro kernel branches are any better than linux-stable, and use linux-stable and engage with the linux-stable list and patchsets if they're concerned about what's going into them.

Part of the solution is each distro needs a process for pushing critical updates (module blacklists, ebpf patches) to address things like this without forcing all distro users to reboot, which many won't do promptly anyway.

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

#504

Post by sersi »

gregkh wrote: post #425
sersi wrote: post #412

Interesting comment by Greg Kroah-Hartman when asked why the kernel team doesn't notify distros directly > Nope, sorry, we are NOT allowed to notify anyone about anything "ahead of time" otherwise we will have to tell everyone about everything. That's the only policy by which all the legal/governmental agencies have agreed to allow us to operate in, so we are stuck with it. I'd be interested in knowing more about tha…

The members of the kernel security team are not allowed to tell their employers anything that happens on the security list. They are there as individual members, not as employees. And try to define "major distros" in a way that actually means anything viable. If you just want to count users, then that would only be Android (everything else is a rounding error.) After Android, that would be Yocto, and then Debian. All…

Thanks for the reply (and thanks for the work you do)! Fair enough. And the issue is also that without some form of vetting you run the risk of disclosing the 0 day too early?

About that "That's the only policy by which all the legal/governmental agencies have agreed to allow us to operate in, so we are stuck with it.", you mean that if you disclose selectively, then you become liable for damages? or was it a more direct conversation with legal/governmental agencies?

And for a bug like this, what is the policy with backporting patches to lts branches? Since it was corrected in mainline on april 1st but only backported after the public disclosure. Do you delay backporting to minimise any attention on the security issue?

I guess that having a patch for that land on all the LTS branch would signal to any would be attacker that it's a significant security issue...

Sorry for all the questions but I'm genuinely interested.

EDIT: Just read your blog post at http://www.kroah.com/log/blog/2026/01/02/linux-kernel-securi... which does answer a lot of my questions...

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

#505

Post by akerl_ »

zamalek wrote: post #493
voxic11 wrote: post #443

Earlier quoted context omitted.

What rules were not followed here?

Tons of distros were not informed.

Is that a rule? Are there rules?

These researchers found a vulnerability in the Linux kernel. They could have just written a blog post and put it online, or not told anybody, or sold it. But instead they decided to tell the Linux kernel devs, and give them time to act before publishing.

And your beef is that you’ve decided they needed to also inform individual downstream projects that use the Linux kernel? Why? Which ones?

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

#506

Post by lokar »

I don’t see what the fuss is about. Sometimes the reporter will go above and beyond beyond to try to coordinate a broad response, sometimes they won’t

No one serious should consider the kernel (on its own) a good security boundary (and basic containers don’t count either).

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

#507

Post by CodesInChaos »

saysjonathan wrote: post #182
CodesInChaos wrote: post #170

Earlier quoted context omitted.

> Who knows how many shared hosting providers were hacked with this. I'd consider a shared hoster which allows users to run their own (native) code and doesn't use VMs for tenant isolation extremely irresponsible in 2026.

This is probably more common than you think. VMs are expensive, both in resources and cost (if you’re using something commercial). OS-level isolation (shared kernel, cgroups, namespaces) is used pervasively

Modern VMs, e.g. using Firecracker shouldn't be that expensive. I think it's crazy that Kubernetes doesn't use a VM per pod model, especially since it was started by security conscious google.

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

#508

Post by sophacles »

lokar wrote: post #506

I don’t see what the fuss is about. Sometimes the reporter will go above and beyond beyond to try to coordinate a broad response, sometimes they won’t No one serious should consider the kernel (on its own) a good security boundary (and basic containers don’t count either).

Nonsense the kernel owns huge swaths of the IO path.

For example:

It is responsible for all ethernet and IP layer operations, and handles TCP, etc. (By default, there's ways to move these things into userland, but in 99% of cases, programs open a socket, and exchange buffers with the kernel - the kernel does the rest).

You're telling me that the kernel should not be a security boundary against malformed packets? That it's no big deal if some malformed packet can crash a machine, cause remote code execution, or cause the system to perform poorly (all real things that have been possible in most tcp/ip stacks, including linux)?

Hell (ip|nf)tables firewalling is a security boundary, and it is implemented in the kernel. If you configure a rule and the kernel code handling that rule has a bug that allows bad traffic - isn't this a case of the kernel literally advertising itself as a security boundary and failing?

This is where some genius usually steps in and says "well thats why you use a hardware firewall hurr durr - but those are just boxes running a tcp/ip stack with help from some chips that can assist the operations. Problems there:

* The hardware or firmware or even the linux kernel running on such boxes may also have bugs, letting bad traffic through to the hosts/servers.

* There are categories of network stack bugs with packets that look like good traffic that can still be exploited on the host's kernel.

(Aka defense in depth requires the kernel to be the best security boundary it can be also).

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

#509

Post by zamalek »

akerl_ wrote: post #505
zamalek wrote: post #493

Earlier quoted context omitted.

Tons of distros were not informed.

Is that a rule? Are there rules? These researchers found a vulnerability in the Linux kernel. They could have just written a blog post and put it online, or not told anybody, or sold it. But instead they decided to tell the Linux kernel devs, and give them time to act before publishing. And your beef is that you’ve decided they needed to also inform individual downstream projects that use the Linux kernel? Why? Which…

> Is that a rule?

No, it's commonly followed practice: https://en.wikipedia.org/wiki/Coordinated_vulnerability_disc...

I'm all for lighting a fire under the developer's ass, but we live in an imperfect world and the biggest problem that we have is end-users. We may have applied the mitigation on day 0, and updated as soon as the kernel landed in our distro - and if some of us didn't then we've even got savvy users in that "don't update fast enough group" (which is fine, which is human, but is said imperfection).

Major distros should at least have gotten a few days of notice for something this catastrophic. It doesn't help that the kernel is fixed if "normies" aren't able to access it on day 0. For reference, the standard is 30 for the developer to fix and 90 for it to land on machines. Even 30+7 would have been a substantial improvement.

Ethical security research involves ethics, and maybe they aren't referenced in university/college any more - but here's what I was taught: https://www.acm.org/code-of-ethics .

> 1.1 Contribute to society and to human well-being, acknowledging that all people are stakeholders in computing.

> [...] Computing professionals should consider whether the results of their efforts will [...] and will be broadly accessible.

> 1.2 Avoid harm.

> (Honestly, all of it)

> 2.3 Know and respect existing rules pertaining to professional work.

> 3.1 Ensure that the public good is the central concern during all professional computing work.

> People—including users, customers, colleagues, and others affected directly or indirectly—should always be the central concern in computing.

Maybe other code of ethics for CS exist; I'd like to know which ethics these ethical researchers were following.

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

#510

Post by lokar »

sophacles wrote: post #508
lokar wrote: post #506

I don’t see what the fuss is about. Sometimes the reporter will go above and beyond beyond to try to coordinate a broad response, sometimes they won’t No one serious should consider the kernel (on its own) a good security boundary (and basic containers don’t count either).

Nonsense the kernel owns huge swaths of the IO path. For example: It is responsible for all ethernet and IP layer operations, and handles TCP, etc. (By default, there's ways to move these things into userland, but in 99% of cases, programs open a socket, and exchange buffers with the kernel - the kernel does the rest). You're telling me that the kernel should not be a security boundary against malformed packets? That…

That’s mostly true, I really had in mind local exploits

At the same time, you should use application layer proxies (eg http) that have little or no privileges in your system, nothing else running, as restricted as possible, etc. don’t expose more general hosts to direct raw IP traffic from the internet.

Post reply on HN