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.

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.

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

For immediate mitigation, block AF_ALG socket creation via seccomp or blacklist the algif_aead module:

    echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
    rmmod algif_aead 2>/dev/null

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

    2026-03-23Reported to Linux kernel security team
    2026-03-24Initial acknowledgment
    2026-03-25Patches proposed and reviewed
    2026-04-01Patch committed to mainline
    2026-04-22CVE-2026-31431 assigned
    2026-04-29Public disclosure (https://copy.fail/)

they state that the write-up is forthcoming. presumably there is some additional steps or modifications that will be detailed in the 'part 2'.

"Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."

you are reading about it now because it has been patched.

i bet if i told you their names, you would instantly know what vulns those are.

its easier to talk about things with names. it hurts no one. it takes approximately no effort or time.

CVEs are, for whatever reason, like the only thing on the planet that people seem to have a problem with when they receive a name. i am not sure why.

(do you comment this same type of thing on github, microsoft, apple, etc. posts? all of these comments seem absolutely tame compared to the vitriol in those threads. most top comments here are supportive. most of the negative ones are constructive.)

i have never heard someone outside of tech circles (e.g. HN) mention openness, freedom, or customization, even as a passing comment.

they use a phone to access mainstream apps (youtube, instagram, reddit, maybe their bank) and text/call. mention "apk" or "fdroid" and their eyes start to glaze over.

cheaper devices, sure, i agree with that as being the differentiator to the average non-techie. the rest is, at least in my experience, absolutely a "HN view".

if only people could choose to have or not have a credit score. that would be cool. unfortunately, equifax/transunion/experian are some of the original data vacuums and assign one whether you want one or not.

based on what?

its a rhetorical question.

the question is asked to make a point rather than to be answered.