5 ms·

It seems there was some kind of confusion during the disclosure process, because the vendors aren't treating this vulnerability as serious and it remains unpatc

It seems there was some kind of confusion during the disclosure process, because the vendors aren't treating this vulnerability as serious and it remains unpatched in many distros. https://access.redhat.com/security/cve/cve-2026-31431 https://access.redhat.com/security/cve/cve-2026-31431 "Moderate severity", "Fix deferred" https://security-tracker.debian.org/tracker/CVE-2026-31431 https://security-tracker.debian.org/tracker/CVE-2026-31431 https://ubuntu.com/security/CVE-2026-31431 https://ubuntu.com/security/CVE-2026-31431 https://www.suse.com/security/cve/CVE-2026-31431.html https://www.suse.com/security/cve/CVE-2026-31431.html

baggy_trough 5mo ago
The upstream stable kernels (6.12.85, etc.) are out now with the fixes.
Tuna-Fish 5mo ago
Yeah, by ubuntu's own guidelines linked on that page, this should be priority: high, but instead it's marked as medium.
- no-name-here 5mo ago
  That was fixed, it’s now marked high.
- deleted 5mo ago
  [deleted]
MarleTangible 5mo ago
Seems like distros consider it a medium risk because it doesn't involve remote code execution and requires local access. Though it allows local root privilege escalation which is considered high priority. https://ubuntu.com/security/cves/about#priority https://ubuntu.com/security/cves/about#priority > Medium: A significant problem, typically exploitable for many users. Includes network daemon denial of service, cross-site scripting, and gaining user privileges.
- oskarkk 5mo ago
  Strange that it's not classified as "high", which specifically includes "local root privilege escalations". > High: A significant problem, typically exploitable for nearly all users in a default installation of Ubuntu. Includes serious remote denial of service, local root privilege escalations, local data theft, and data loss.
  - amarant 5mo ago
    It is high now, someone at canonical is paying attention it seems
- deleted 5mo ago
  [deleted]
- deleted 5mo ago
  [deleted]
- mghackerlady 5mo ago
  it's not like this couldn't be chained with some other exploit to get remote access to get remote root access which seems like a bit of an issue
- daveoc64 5mo ago
  Ubuntu seems to have updated the page to say that it's a high priority now.
- markhahn 5mo ago
  if your model is that linux is just about single-user desktops, this local exploit isn't too bad. or if your model is nothing but DB servers or the like. mystifying to me that shared, multi-user machines are not thought of. for instance, I administer a system with 27k users - people who can login. even if only 1/10,000 of them are curious/malicious/compromised, we (Canadian national research HPC systems) are at risk. yes, this is somewhat uncommon these days, when shell access is not the norm. but consider the very common sort of shared hosting environment: they typically provide something like plesk to interface to shared machines with no particular isolation. can you (as a website owner or 0wner) convince wordpress/etc to drop and execute a script? yep.
wangman 5mo ago
RedHat has also changed it to "Important severity" and "Affected" now.
staticassertion 5mo ago
It was already known to attackers (or basically anyone watching) weeks ago when the patch hit the kernel but it wasn't communicated by upstream as a vuln (because Linus and Greg do not believe that vulnerabilities are conceptually relevant to the kernel).
- still_grokking 5mo ago
  Will this continue like that even when the prophesied Mythos Vulnocalypse hits the Kernel? This stance doesn't seem sustainable any more to me.
  - staticassertion 5mo ago
    The response from Greg was that Mythos proved that upstream was right all along and that they'll continue to do things the same way. That's my recollection, at least - pretty sure it was something like that, could have been even worse though and I'm misremembering. The stance was never sustainable, hence linux LPEs being constantly available. The solution is to treat your kernel as impossible to secure. Notably, gvisor users are not impacted by this CVE. Seccomp also kills this CVE.
    - still_grokking 5mo ago
      How about SELinux, like on Android?
      - staticassertion 5mo ago
        I assume that wouldn't help here but I could easily be wrong. (Assuming if you're asking if SELinux would block this exploit).
      - nromiun 5mo ago
        To even get the su binary on Android you have to patch the OS. So this exploit can't work on Android. Because there is no su binary to target. Update: Just tried it on Termux and as expected even creating an AF_ALG socket requires root access.
Neil44 5mo ago
I thought that. surely people are going crazy right now owning anything with an our of date Wordpress exposed.
AntiUSAbah 5mo ago
I'm schocked that ubuntu is aware of this and the prv lts is not patched yet :| wtf
- Yokohiii 5mo ago
  upgraded today and they've put the kernel module install override in place. (wsl2/ubuntu)
DooMMasteR 5mo ago
Yeah, it was also staged for release on the affected kernel branches a while ago, but almost all still had the window open and only tonight got the merged across all maintained kernel versions. It's not good... and surely not "responsible/planned" disclosure.
stefanor 5mo ago
As far as we can tell, nobody disclosed it to the distributions, only to the kernel security team (who did not reach out to distributions). So the distributions are all scrambling now. Good lesson in how not to do disclosure.
- baggy_trough 5mo ago
  Why wouldn't the kernel security team reach out to distributions?
  - stefanor 5mo ago
    The Linux project's view is that almost all kernel bugs are security vulnerabilities. They don't treat something like this as anything special. I can understand that PoV, but it doesn't fit with distributions' approach to security. So, in practice, one has to reach out to distributions individually, or use distros lists on openwall.org to coordinate with all distros.

baggy_trough 5mo ago

The upstream stable kernels (6.12.85, etc.) are out now with the fixes.

Tuna-Fish 5mo ago

Yeah, by ubuntu's own guidelines linked on that page, this should be priority: high, but instead it's marked as medium.

no-name-here 5mo ago
That was fixed, it’s now marked high.
deleted 5mo ago
[deleted]

MarleTangible 5mo ago

Seems like distros consider it a medium risk because it doesn't involve remote code execution and requires local access. Though it allows local root privilege escalation which is considered high priority. https://ubuntu.com/security/cves/about#priority https://ubuntu.com/security/cves/about#priority > Medium: A significant problem, typically exploitable for many users. Includes network daemon denial of service, cross-site scripting, and gaining user privileges.

oskarkk 5mo ago
Strange that it's not classified as "high", which specifically includes "local root privilege escalations". > High: A significant problem, typically exploitable for nearly all users in a default installation of Ubuntu. Includes serious remote denial of service, local root privilege escalations, local data theft, and data loss.
- amarant 5mo ago
  It is high now, someone at canonical is paying attention it seems
deleted 5mo ago
[deleted]
deleted 5mo ago
[deleted]
mghackerlady 5mo ago
it's not like this couldn't be chained with some other exploit to get remote access to get remote root access which seems like a bit of an issue
daveoc64 5mo ago
Ubuntu seems to have updated the page to say that it's a high priority now.
markhahn 5mo ago
if your model is that linux is just about single-user desktops, this local exploit isn't too bad. or if your model is nothing but DB servers or the like. mystifying to me that shared, multi-user machines are not thought of. for instance, I administer a system with 27k users - people who can login. even if only 1/10,000 of them are curious/malicious/compromised, we (Canadian national research HPC systems) are at risk. yes, this is somewhat uncommon these days, when shell access is not the norm. but consider the very common sort of shared hosting environment: they typically provide something like plesk to interface to shared machines with no particular isolation. can you (as a website owner or 0wner) convince wordpress/etc to drop and execute a script? yep.

wangman 5mo ago

RedHat has also changed it to "Important severity" and "Affected" now.

staticassertion 5mo ago

It was already known to attackers (or basically anyone watching) weeks ago when the patch hit the kernel but it wasn't communicated by upstream as a vuln (because Linus and Greg do not believe that vulnerabilities are conceptually relevant to the kernel).

still_grokking 5mo ago
Will this continue like that even when the prophesied Mythos Vulnocalypse hits the Kernel? This stance doesn't seem sustainable any more to me.
- staticassertion 5mo ago
  The response from Greg was that Mythos proved that upstream was right all along and that they'll continue to do things the same way. That's my recollection, at least - pretty sure it was something like that, could have been even worse though and I'm misremembering. The stance was never sustainable, hence linux LPEs being constantly available. The solution is to treat your kernel as impossible to secure. Notably, gvisor users are not impacted by this CVE. Seccomp also kills this CVE.
  - still_grokking 5mo ago
    How about SELinux, like on Android?
    - staticassertion 5mo ago
      I assume that wouldn't help here but I could easily be wrong. (Assuming if you're asking if SELinux would block this exploit).
    - nromiun 5mo ago
      To even get the su binary on Android you have to patch the OS. So this exploit can't work on Android. Because there is no su binary to target. Update: Just tried it on Termux and as expected even creating an AF_ALG socket requires root access.

Neil44 5mo ago

I thought that. surely people are going crazy right now owning anything with an our of date Wordpress exposed.

AntiUSAbah 5mo ago

I'm schocked that ubuntu is aware of this and the prv lts is not patched yet :| wtf

Yokohiii 5mo ago
upgraded today and they've put the kernel module install override in place. (wsl2/ubuntu)

DooMMasteR 5mo ago

Yeah, it was also staged for release on the affected kernel branches a while ago, but almost all still had the window open and only tonight got the merged across all maintained kernel versions. It's not good... and surely not "responsible/planned" disclosure.

stefanor 5mo ago

As far as we can tell, nobody disclosed it to the distributions, only to the kernel security team (who did not reach out to distributions). So the distributions are all scrambling now. Good lesson in how not to do disclosure.

baggy_trough 5mo ago
Why wouldn't the kernel security team reach out to distributions?
- stefanor 5mo ago
  The Linux project's view is that almost all kernel bugs are security vulnerabilities. They don't treat something like this as anything special. I can understand that PoV, but it doesn't fit with distributions' approach to security. So, in practice, one has to reach out to distributions individually, or use distros lists on openwall.org to coordinate with all distros.