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 distros after that are mere fractions of overall users compared to those 3 by number of running systems alone.

If you want to count it as "$ spent on Linux" then that cuts out Android and Yocto and Debian as those distros are free, and would focus purely on the tiny installed base of paid Linux systems, and cut everyone else out.

So what is a fair way to do this other than "we notify no one, and tell everyone to always update their systems to the latest stable releases that we support."

Especially as there is no way for us to determine your use case (i.e. if a specific bug is a vulnerability for you or not.)

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...

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 sandboxed with user account,…). That put Debian, Ubuntu, Rhel, Fedora, Arch,… installation as the juicest targets.

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.

Just a wild guess:

Given the potential impact a severe security issue in the kernel (like this one), it seems that the only process that is acceptable for government agencies of various countries (that deal with intelligence and national security) is to either keep secrets from everyone, or disclose them to everyone.

Otherwise, the entities on the priority disclosure list would basically have free access to zero day vulnerabilities. Then every country with a national intelligence agency would invent a distro and try to squeeze themselves onto that list, and things would become very political and ugly if the agents of any country can't get into that list...