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

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.

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.

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

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.

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

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.

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

Ah, got it. Thank you.

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

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

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.

llms love that though

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

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.

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.

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.

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)

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

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

Technical writeup is also slop I fear

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

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

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

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.

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

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.

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

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.

>I need to know what the code does before I run it.

its literally code meant to exploit your system. you should be running it in an environment built for that already.

you dont test exploit pocs on your daily driver.

> you dont test exploit pocs on your daily driver.

Do you just like making fake points and pretending other people said them?

go ahead and explain your point, rather than be cryptic, if you you want to have an actual conversation about it.

you said "I need to know what the code does before I run it.".

you know its an LPE. the mechanisms of the exploit are fully explained. what more do you need to know? please imagine yourself in the position of the kernel security team who would have received this poc in the first place when you answer, because that is the intended context of the poc.

if you think the kernel security team is going to get tripped up over "os as g", you have a crazy low view of the team.

While your at it you can enter your credit card details to see if they've been leaked.

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.

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

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

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

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

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.

PRINCIPLES.md

What would you suggest instead?

Nordic Semi, or maybe ST Micro. I've got an STM32WB on my bench at the moment with sensitive coulomb counting and it looks very promising but without all those radios. Of course with all those radios (ie, if you need LoRa on a watch... which is a design decision I'm also skeptical of) then Nordic has a good track record.

Different use case (environmental data recorder) but our current product uses an STM that turns on an ESP32 (not trusting that sleep mode) when it needs radio, to run on 2 AAs forever.

Do you have any info you can share on this recorder? Sounds really interesting!

http://supermechanical.com/pickup Been in production hell thanks to tariffs (wrote a lot about it) but should ship by summer.

For an application using bluetooth low energy, a Nordic NRF52840 turned out to be the winner.

Not the newer more energy efficent nrf54 series?

Ooh I'll take a look! Sometimes I get behind the times because I have to find a favorable dev board.

> TPU 8i pairs 288 GB of high-bandwidth memory with 384 MB of on-chip SRAM

Wow. Just Wow. I presume that's for each chip, and there are 1152 chips in a pod so that's 331TB HBM and 442TB SRAM per pod. Just wow.

That would be 442GB not TB of SRAM.

Aggregating on-chip SRAM is not a useful metric. AFAIK there are no interconnect between two chips at SRAM level so they cannot be shared .

Is it me or is that aluminum already developing some stress cracking?

Post actual results, make a blog post. Don't just say "this sucks" without tangible evidence.

Otherwise you're doomed to "sample size of one" level of relevance.

I have the opposite experience: random HN/Reddit comments saying “this sucks” or “whoa this is a huge improvement” are the only benchmark that means anything. Standard benchmarks are all gamed and don’t capture the complexity of the real world.

Then your internal benchmarks will be in the post-training set and you’ll have to make new ones.

I may already have but I'm pseudonymous on this website.

The synth engine is an implementation of https://soniccharge.com/microtonic Not sure what "accurate" means in your context though?

How closely it replicates microtonic's, would be my assumption

Yes, and with virtually zero context, which makes an enormous difference for TTFT on the MoE models.

Correct, also with the context growing, the conversations cannot continue at the initial speed either. Gimmick or not, this is very sci-fi compared to 10-20 years ago.

This should be the top comment