Earlier quoted context omitted.
Rather than the current situation, where they can pwn machines after the exploit is made public?
Yes. After the exploit is made public, the window of opportunity closes quickly.
Not if people don't get notified!
For Linux kernel vulnerabilities, there is no heads-up to distributions
491–500 of 578 posts
Re: For Linux kernel vulnerabilities, there is no heads-up to distributions
#492Earlier quoted context omitted.
You're freaking out about the exploit being written in Python and occupying only a small number of bytes. Are you the LLM that wrote Xint's terrible landing page? If so, I have questions.
Oh come on, you know what I'm saying. It's small when written in python, which means any skid can spew it into a server he's got a shell on and get root in 2 seconds. He doesn't need to hope there's already a compiler installed, nor does he need to download some big tool. Just: cat | python3 && su , Ctrl-D And I'm sure it can be refined into something much more likable to the spooky types, if they haven't already don…
Again, Linux LPE via either vulns or misconfigured permissions / binaries is common.
People who run servers that give out shell access to uses or randos already needed to contend with this.
Added later: you may find https://gtfobins.org/ fascinating or horrifying.
Re: For Linux kernel vulnerabilities, there is no heads-up to distributions
#493Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Coordinated_vulnerability_disc... > In computer security, coordinated vulnerability disclosure (CVD, sometimes known as responsible disclosure) I guess you can learn something new after 36 years. If you are referring to what you quoted, your pedantry and sharpshooting would result in an incomplete English sentence: "that's why we have the responsible disclosure" is missing a noun. Now th…
What rules were not followed here?
Tons of distros were not informed.
Re: For Linux kernel vulnerabilities, there is no heads-up to distributions
#494Earlier quoted context omitted.
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…
If you want to talk about possible exploiting being done. Then Android is out (userland is crippled) and I guess yocto as well (same issue). Not that they can’t be attacked, but because mostly what is there is static. As it’s a privilege escalation attack, that leaves us with anything that is running code by unverified users (vulnerable server software, linux shell services, untrusted software you think you’ve sandbo…
Oh... thank you for the reminder to try running the C version of this exploit on an Android phone over adb. The curiosity is now killing me.
Edit: for context, I work in embedded and the aarch64 version (PR #42 in the repo) has successfully popped every device I've tried it against except one where I have a custom kernel to work around a driver issue and (looking back at my git logs) accidentally forgot to enable the user-mode API for alg_aead specifically. Lucky mistake.
Re: For Linux kernel vulnerabilities, there is no heads-up to distributions
#495The most interesting exchange, related to disclosure, is this one: https://www.openwall.com/lists/oss-security/2026/05/01/3 > 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. greg k-h
As much as I like linux, this is stupid.
Distributions using outdated (sorry “stable”) kernels are stupid.
We are not 20 years ago, the world in which it made sense doesn’t exist anymore, but the industry is slow to move on. Just pick a long term release and update it regularly.
Re: For Linux kernel vulnerabilities, there is no heads-up to distributions
#496I 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 absolutely nothing towards providing a better alternative.
It's quite certain that both the Linux project and the Linux CNA needs to take some responsibility and put in some effort at communication and making it easier to triage.
Re: For Linux kernel vulnerabilities, there is no heads-up to distributions
#497Earlier quoted context omitted.
As much as I like linux, this is stupid.
Distributions using outdated (sorry “stable”) kernels are stupid. We are not 20 years ago, the world in which it made sense doesn’t exist anymore, but the industry is slow to move on. Just pick a long term release and update it regularly.
Yes.
Distros (point release distros) should use LTS kernels and keep up to date with them. Their "we'll maintain our own kernel branches" model either leads to many missed bugfixes, or duplicates Greg K-H's workload internally, for no practical benefit.
If a distro is suspicious of particular patches in the -stable tree, they could maintain a blacklist of them. However, instead of doing that and accruing overhead of possible future merge conflicts, they should hash out their concerns on the -stable mailing list.
Re: For Linux kernel vulnerabilities, there is no heads-up to distributions
#498Earlier 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.
>Brother, it is a simple email to a mailing list.
just as a note, its not as simple as firing off an email to linux-distros and calling it a day.
qualys, one of the big firms (10,000+ customers across 130 countries. i.e. "professional researchers"), has even taken a stance against emailing linux-distros because of the restrictions and policies involved:
> Although contacting the linux-distros list has been clearly beneficial
> (they have thoroughly reviewed and tested the patches, and were able to
> prepare their kernel updates beforehand), we have reached the conclusion
> that it has become increasingly difficult to coordinate the disclosure
> of kernel vulnerabilities with both groups (the Linux kernel security
> team and the linux-distros list), because they have very different
> policies. From now on, we will coordinate the disclosure of kernel
> vulnerabilities with the Linux kernel security team only. We also
> apologize in advance for this.Re: For Linux kernel vulnerabilities, there is no heads-up to distributions
#499Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Coordinated_vulnerability_disc... > In computer security, coordinated vulnerability disclosure (CVD, sometimes known as responsible disclosure) I guess you can learn something new after 36 years. If you are referring to what you quoted, your pedantry and sharpshooting would result in an incomplete English sentence: "that's why we have the responsible disclosure" is missing a noun. Now th…
I don't think you're going to bluff your way through this.
From elsewhere.[1]
> You: No, I wouldn't, because my own preferences are towards immediate disclosure.
And there it is. You could have said "I don't think responsible disclosure is a good idea" and moved on, but now we have whatever the fuck this is.
Bluffing sure as hell beats incapable of being wrong. I'll take it.
Re: For Linux kernel vulnerabilities, there is no heads-up to distributions
#500Earlier quoted context omitted.
i have no problem with disclosing a vulnerability 30 days after its patched in the thing you reported to. (in fact, for those unaware, this is the same policy that google's project zero uses: "90+30" https://projectzero.google/vulnerability-disclosure-policy.h... ) the real problem is: > It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. the report…
> the reporter should not be the one responsible for reporting separately to every single downstream of the thing they found a vuln in. It's 2026. We're more than 30 years into the Linux ecosystem. I don't believe this bullshit for a moment. Given how trivially users can implement mitigation, distributions could have done _something_ to protect their users prior to publication date. A handful of messages is all that…
>distributions could have done _something_ to protect their users prior to publication date.
yeah, distributions could be following the kernel updates more closely and they would have been patched prior to publication. mainline was patched 30 days before publication.
it is not the reporter's responsibility to babysit the linux distributions.