#copyfail

28 posts · Last used 2d

Back to Timeline
@jwildeboer@social.wildeboer.net · 2d ago

Ah, the #copyfail clickbait posts are coming. Here’s my contribution. On your Linux machine add

initcall_blacklist=algif_aead_init

to your kernel boot commandline (typically in grub). Reboot. You are now safe until the updated kernel packages become available. For distributions with the grubby command this is done as root with

grubby –update-kernel=ALL –args=”initcall_blacklist=algif_aead_init”

This mitigation comes courtesy of Red Hat. Our engineers keep you safe :)

268
12
284
@mgorny@social.treehouse.systems · 2d ago
Greg Kroah-Hartman: "If you look there are thousands of unfixed CVEs in the older LTS kernels right now, and if distros or users that rely on those older branches wish to see those resolved, they need to provide working backports to us to apply, as our first attempt did not work (which is why they are unfixed in those branches.)" Really asking for a "Pray tell us", given that nobody actually bothered disclosing the problem to downstreams and that the commit message was hiding it. Either way, apparently the great LLM-backed patch backporting process that #NVidia is so proud of doesn't really work. Upstream doesn't really care about #LTS branches, and they should be considered insecure by default. https://lore.kernel.org/stable/2026050114-supernova-angler-2de1@gregkh/ #Gentoo #Linux #CopyFail #security
25
9
27
In reply to
@gilles@toot.gagniard.org · 2d ago
@almalinux@fosstodon.org Test kernel installed on my servers and reboot done. No issue to report ! Thank you so much for your reactivity. #copyfail #almaLinux
0
0
0
@the_moep@mastodon.de · 3d ago
They: "On a scale from 1 to 10: How lazy are you?" Me: Using the copy fail exploit instead of sudo to avoid having to type my password #copyfail #linux #cybersecurity
176
0
126
@anthropy@mastodon.derg.nz · 3d ago

Did you patch your servers against CopyFail yet? #CopyFail #CyberSecurity #Security #Linux

Of course!
100.0% (4)
I like to live dangerously.
0.0% (0)
Please send help
0.0% (0)
4 votes Poll closed
View on mastodon.derg.nz
0
0
3
@JennyFluff@chitter.xyz · 4d ago
Note that if you the #copyfail exploit on your session, any terminal in it will be able to su without authentication (until next reboot I assume). hotpatch: https://lilting.ch/en/articles/linux-copy-fail-page-cache-root
1
0
1
In reply to
@AthanSpod@social.linux.pizza · 4d ago
@JennyFluff@chitter.xyz You can `echo 1 > /proc/sys/vm/drop_caches` to drop the caches, after you've done something like: $ cd /etc/modprobe.d $ cat > af_alg.conf blacklist af_alg blacklist algif_aead $ which blacklists the modules. Now, if you have legitimate use of af_alg, you can decide to only `blacklist algif_aead`, which worked to block the exploit on my Debian 13/trixie desktop running a locally-compiled 6.18.25 kernel. Dropping the caches clears what the exploit did (changing the contents of the cached version of `/usr/bin/su`, so that cached version is always used, not the on-disk version). #copyfail
5
0
2
@Larvitz@burningboard.net · 3d ago
Fresh gist: mitigating CVE-2026-31431 ("Copy Fail") on RHEL 8/9/10 with a tiny Ansible playbook. It blacklists algif_aead via a kernel boot arg (initcall_blacklist=algif_aead_init), reboots only when needed, and asserts the mitigation actually stuck after reboot. Idempotent & safe to re-run. https://codeberg.org/Larvitz/gists/src/branch/main/2026/20260501-CVE-2026-31431_RHEL_Mitigation.md #Ansible #RHEL #Linux #InfoSec #SysAdmin #DevOps #CVE #CVE_2026_31431 #copyfail
0
0
0
@mttaggart@infosec.exchange · 3d ago
Got a very silly #CopyFail container escape working. Basically, if the container can see a file shared by the host, regardless of permissions, CopyFail can write to it on the host. https://discourse.ifin.network/t/copy-fail-732-bytes-to-root-on-every-major-linux-distributions/342/44
59
5
67
@grono@mastodon.com.pl · 3d ago
Docker Engine is safe against CVE-2026-31431 now. Patch ASAP: https://github.com/moby/moby/releases/tag/docker-v29.4.2 #docker #containers #linux #copyfail
0
0
0
@adhisimon@mastodon.kodesumber.com · 3d ago
Before trying to mitigate, it turns out my #fedora 43 workstation (not upgraded to 44 yet) had already updated and not vulnerable to #copyfail
0
1
0
@adhisimon@mastodon.kodesumber.com · 3d ago
Fedora had released Fedora CoreOS 43.20260413.3.2 on "stable stream" few hours ago to patch against Copy Fail. Upgraded packages: kernel-6.19.11-200.fc43.x86_64 ⟶ 6.19.12-200.fc43.x86_64kernel-core-6.19.11-200.fc43.x86_64 ⟶ 6.19.12-200.fc43.x86_64kernel-modules-6.19.11-- 200.fc43.x86_64 ⟶ 6.19.12-200.fc43.x86_64kernel-modules-core-6.19.11-200.fc43.x86_64 ⟶ 6.19.12-200.fc43.x86_64 You can wait your zincati service schedule to upgrade automatically, or you can run sudo zincati-update-now to upgrade immediately. #copyfail #fedora #fcos #coreos
0
0
0
@veronica@mastodon.online · 3d ago
Copy Fail (CVE-2026-31431) has just been patched on Debian 13, with kernel version 6.12.85-1 from trixie (security). https://security-tracker.debian.org/tracker/CVE-2026-31431 #CopyFail #Debian #Linux #InfoSec #CVE
15
0
16
@tankgrrl@hachyderm.io · 3d ago
No warranty implied, use at your own risk. But this short C program can check if your Linux machine is still vulnerable to Copy Fail (there's also this page with python code from our friends in Estonia https://docs.hpc.ut.ee/public/cve-2026-31431/ ) Output includes "ARE available" or "NOT available" Again: compile and run at your own risk. Don't just trust me blindly. Read the code. #CopyFail #CVE-2026-31431 ============== #include #include #include #include #include #include int main(void) { int sock; struct sockaddr_alg sa; // Prepare sockaddr_alg for AEAD/GCM memset(&sa, 0, sizeof(sa)); sa.salg_family = AF_ALG; strcpy((char *)sa.salg_type, "aead"); strcpy((char *)sa.salg_name, "gcm(aes)"); // Try to create AF_ALG socket sock = socket(AF_ALG, SOCK_SEQPACKET, 0); if (sock == -1) { perror("socket(AF_ALG, aead)"); printf("algif_aead functions are NOT available (AF_ALG socket creation failed).\n"); return 1; } // Try to bind to AEAD/GCM if (bind(sock, (struct sockaddr *)&sa, sizeof(sa)) == -1) { perror("bind(AF_ALG, aead, gcm(aes))"); printf("algif_aead functions are NOT available (bind failed).\n"); close(sock); return 1; } printf("algif_aead functions ARE available (AF_ALG AEAD bind succeeded).\n"); close(sock); return 0; }
2
0
0
@rysiek@mstdn.social · 3d ago
A lot of people are apparently happily running a script clearly marked as a root exploit from some random website using curl | bash :blobsweat: Some do inspect the script, but then still run it using curl | bash anyway. :thaenkin: Incidentally, this very relevant blogpost about detecting curl | bash and serving different scripts based on that is almost exactly a decade old: https://web.archive.org/web/20230318063325/https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ #CopyFail #InfoSec
256
21
248
@matthew@social.retroedge.tech · 3d ago
Question on the #CopyFail Linux vulnerability: If "lsmod | grep algif_aead" returns nothing, is the vulnerability not exploitable? Most of my Linux machines are running older, non-patched kernels, but it doesn't seem like the affected kernel module is active... so does that mean a system that returns nothing for "lsmod | grep algif_aead" is not at risk for this exploit? #Linux
0
0
0
@harrysintonen@infosec.exchange · 4d ago

Mitigation to #CVE_2026_31431 / #copyfail :

  • If kernel config has CONFIG_CRYPTO_USER_API_AEAD=m:

echo “install algif_aead /bin/false” | sudo tee /etc/modprobe.d/disable-algif.conf; sudo rmmod algif_aead

  • If kernel config has CONFIG_CRYPTO_USER_API_AEAD=y:

Add “initcall_blacklist=algif_aead_init” to the kernel command line and reboot.

https://www.openwall.com/lists/oss-security/2026/04/30/2

14
0
21
Boosted by Greg Bell @ferrix@mastodon.online
@alexanderkjall@mastodon.social · 4d ago
Today I have spent way too much time handling the https://copy.fail situation #copyfail The persons who discovered it didn't notify the distribution security list, so no patched kernels was available for people to install when they released it. But they did have time to write an exploit, and thought it was a good idea to distribute that on day one, before vendors had time to provide patches. I'm not very impressed with xint.io, I guess it's the marketing department that runs the show.
222
33
208
@nacho@frankenwolke.com · 4d ago
Si sois sysadmins de Linux mejor no hagáis planes para el puente... https://copy.fail/ #copyfail #cve_2026_31431
24
3
33
@data0@indieweb.social · 4d ago

I couldn’t find a list of #Linux #kernel versions that include a patch for #copyfail, so I dug into the commit log and made one. Make sure you’re using at least the following version of your branch to mitigate against copyfail:

  • 7.0-rc7 (any stable 7.x is safe)
  • 6.19.12
  • 6.18.22
  • 6.12.85
  • 6.6.137
  • 6.1.170
  • 5.15.204
  • 5.10.254

See https://copy.fail for more info about the #exploit.

#privilegeescalation #vulnerability #cryptography #linuxadmin #sysadmin

24
2
41