91–100 of 545 posts
Earlier quoted context omitted.
As of this comment, Debian Stable ("Trixie", though I hate codenames) doesn't have a fix in place and remains vulnerable, or at least their CVE tracker shows it as such: https://security-tracker.debian.org/tracker/CVE-2026-31431
"Debian Stable ("Trixie", though I hate codenames)" You can also call it Debian 13.
For mitigation, the page currently basically just says: > Update your distribution's kernel package to one that includes mainline commit a664bf3d603d But it isn't very clear to me what Kernel version you can expect that to be in. For Arch/CachyOS, the patch seems to be included in 6.18.22+, 6.19.12+ and 7.0+. If you're on any of the lower versions in the same upstream stable series, you're likely vulnerable right now…
https://github.com/torvalds/linux.git
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git as remotes:
git log --all --grep 'crypto: algif_aead - Revert to operating out-of-place' '--format=%H' | xargs -I '{}' git tag --contains '{}' | sort -u
v6.18.22
v6.18.23
v6.18.24
v6.18.25
v6.19.12
v6.19.13
v6.19.14
v7.0
v7.0.1
v7.0.2
v7.0-rc7
v7.1-rc1Earlier quoted context omitted.
The fact that they have no idea RHEL 14, probably the most well known enterprise distro, is not a thing, and yet they "directly verified on it" casts some doubt on seriousness.
I don't know what to tell you. I'm sure you have them dead to rights on Linux distro knowledge reliability, but the exploit here is real, and the vulnerability researchers they have on staff are also real. Xint is not generally a slop factory. It's ironic that the one thing LLMs can't do reliably in this space is "write copy for humans" (I don't trust them for that either).
The fetishism of "byte count" (here, as "732 byte python script") needs to stop, especially when in a context like this where they're trying to illustrate a real failure modality. Looking at their source code [1] it starts with this simple line: import os as g,zlib,socket as s And already I'm perplexed. "os as g"? but we're not aliasing "zlib as z"? Clearly this is auto-generated by some kind of minimizer? Likely bec…
But the fact that it's not a kernel-exec LPE and it's reliable across kernels and distributions is important; it's close to the maximum "exploitability" you're going to see with an LPE. Which the page does communicate effectively; it just gilds the lily.
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 "Moderate severity", "Fix deferred" https://security-tracker.debian.org/tracker/CVE-2026-31431 https://ubuntu.com/security/CVE-2026-31431 https://www.suse.com/security/cve/CVE-2026-3143…
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 > Medium: A significant problem, typically exploitable for many users. Includes network daemon denial of service, cross-site scripting, and gaining user privileges.
> 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.
The fetishism of "byte count" (here, as "732 byte python script") needs to stop, especially when in a context like this where they're trying to illustrate a real failure modality. Looking at their source code [1] it starts with this simple line: import os as g,zlib,socket as s And already I'm perplexed. "os as g"? but we're not aliasing "zlib as z"? Clearly this is auto-generated by some kind of minimizer? Likely bec…
> I would absolutely never approve review of any code that used this. How often do you review, and subsequently block the release, of PoCs in this sort of context? Sounds like you've faced this a lot. I always thought code quality mattered less in those, as long as you communicate the intent.
Earlier quoted context omitted.
Android is smarter than setuid + system partitions aren't writable.
System partitions being non-writable has nothing to do with the vulnerability - it allows modifying the cache of any file that you can open for reading. Not using setuid anywhere means you'd have to build a slightly more clever exploit, but it's still trivial - just modify some binary you know will run as root "soon". But... I didn't check, but IIRC the untrusted_app secontext that apps run in is not allowed to open…
The fetishism of "byte count" (here, as "732 byte python script") needs to stop, especially when in a context like this where they're trying to illustrate a real failure modality. Looking at their source code [1] it starts with this simple line: import os as g,zlib,socket as s And already I'm perplexed. "os as g"? but we're not aliasing "zlib as z"? Clearly this is auto-generated by some kind of minimizer? Likely bec…
> I would absolutely never approve review of any code that used this. How often do you review, and subsequently block the release, of PoCs in this sort of context? Sounds like you've faced this a lot. I always thought code quality mattered less in those, as long as you communicate the intent.
If you have a choice between pointing out the byte size of the exploit, and not pointing out the byte size of the exploit, pointing it out is virtually always the wrong choice.
In both cases, doing the right thing is less work. So somebody is going the extra way to ensure they are doing it wrong. If they didn't care, they'd end up doing it right by default.
Earlier quoted context omitted.
Android is smarter than setuid + system partitions aren't writable.
Its not writing to the partition though is it? It is polluting the cache page via a write with a buffer overrun in the kernel. I don't think buffer overruns follow permissions.