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 that policy... Seems that there should be exceptions for the major distros.
Of course, major distros who have contracts with SLA could also pay for someone to be on the kernel security team and get a heads up like that..
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.)
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 (looking back at my git logs) have a custom kernel to work around a driver issue and 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...