Top
Best
New

Posted by unsnap_biceps 18 hours ago

Copy Fail(copy.fail)
1020 points | 369 commentspage 7
oncallthrow 14 hours ago||
[flagged]
pkoiralap 13 hours ago||
Does anyone have a workaround for it? Edit: I don't understand why the comment would be downvoted.
angch 12 hours ago|
I used, for debian based systems:

  printf "# CVE-2026-31431\nblacklist algif_aead\ninstall algif_aead /bin/false\n" | sudo tee /etc/modprobe.d/blacklist-algif_aead.conf >/dev/null && sudo update-initramfs -u
baggy_trough 17 hours ago||
Is this fixed in any stable release kernel yet?
Wingy 17 hours ago|
7.0-rc1 has a tag with it:

    % git describe a664bf3d603d
    v7.0-rc1-10-ga664bf3d603d
I suspect this means the stable 7.0 has it too.
TehCorwiz 17 hours ago||
It does not behave as described on EndeavorOS (arch-based) running kernel 6.19.14-arch1-1. I receive the error:

Password: su: Authentication token manipulation error

I'm guessing this means it's already patched?

john_strinlai 17 hours ago||
yes, it was reported on march 23rd, patches on april 1.

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

marshray 17 hours ago||
No it hasn't.

Ubuntu before 26.04 LTS (released a week ago) are currently listed as vulnerable.

Debian other than forky and sid are currently listed as vulnerable.

This is a disgrace.

john_strinlai 16 hours ago||
Disclosure timeline

    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/)
kernel 6.19.14-arch1-1, the kernel in question from the parent comment, has been patched.
marshray 15 hours ago||
The lesson here being... compile your own kernel from git sources every few days?

Give up entirely on non-virtualized container security?

This is not sarcasm. I'd finally given in and started learning about docker/podman-style OCI containerization last week.

john_strinlai 15 hours ago|||
in this specific case, they offer an alternative mitigation if your chosen distro has not updated yet:

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
marshray 15 hours ago||
Thanks!

I'd do 'umask 133' in front of the echo out of paranoia.

Out of curiosity, was the asterisk after '2>/dev/null' intentional? I had not seen that idiom before.

john_strinlai 15 hours ago|||
the asterisk is my oops, trying to format the comment in italics to differentiate my comment from the text provided by the author. sorry for the confusion
ranger_danger 15 hours ago|||
And I would do chattr +i disable-algif.conf
x4132 11 hours ago|||
are you sure containerization would be more secure? this is also a rootless podman escape. the lesson here is to not give random people shell access to your systems.
dimastopel 17 hours ago||
same result on my arch machine as well.
eaf7e281 14 hours ago||
I'm impressed that such a serious problem popped up out of nowhere.

In my opinion, this mostly affects countries that are still using outdated systems, especially critical systems.

This gives bad actors a direct route to the root. Having an easily accessible root is not funny.

pixel_popping 15 hours ago|
Yet, some people will still continue to say that "AI" isn't ready to replace (or strongly assist) our workflows, sure, some of the best humans devs left a vulnerability that serious (It's extremely serious, so many container as a service are vulnerable) for 9 years and an agent found it in 1 hour, maybe it's time to wake up and accept that it's UNSAFE to not use AI for security review as well?
collinmcnulty 15 hours ago|
A human security researcher found the core issue and an agent searched for where to apply it. I don’t think “an agent found it in one hour” is a fair summary of what happened.
marshray 13 hours ago|||
"The starting insight — that splice() hands page-cache pages into the crypto subsystem and that scatterlist page provenance might be an under-explored bug class — came from human research by Taeyang Lee at Xint. From there, Xint Code scaled the audit across the entire crypto/ subsystem in roughly an hour. Copy Fail was the highest-severity finding in the run."

So, if anything, this might argue against the presence of huge quantities of high-severity bugs in this part of the Linux kernel (that could be found by "Xint Code"-class scanning systems).

pixel_popping 15 hours ago|||
I was a bit rough, agreed, but the overall point is still correct, I kinda want to emphasize that I've also ran hundred of loops recently (combination of opus-4.6/gpt-5.4/gemini-3.1-pro-preview) toward a Rust codebase that we manage and that we deemed secure after many audits and found 2 serious issues as well in it, this was also audited externally by a third party that we've paid, which makes me genuinely scared of releasing anything without deep AI verification nowadays.

Anybody has the same feeling?