copyfail

Slackware Patches "Copy Fail" Kernel Bug — CVE-2026-31431

Slackware has issued a kernel security update for CVE-2026-31431, the Copy Fail vulnerability disclosed April 29, 2026. It's an out-of-bounds write in the AEAD userspace crypto interface (AF_ALG) that lets any local user get a root shell via a setuid binary — the same 732-byte Python PoC works on essentially every Linux distro shipped since 2017.

If you can't patch right away, Slackware ships the affected code as a module (CONFIG_CRYPTO_USER_API_AEAD=m), so you can blacklist or remove it as a stopgap:

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

For most systems this breaks nothing — AF_ALG is a userspace front-door to the kernel crypto API, and OpenSSL, SSH, dm-crypt, kTLS, and IPsec all bypass it.

Patch and reboot when you can. slackpkg update && slackpkg upgrade-all.

Sources:

• http://www.slackware.com/security/viewer.php?l=slackware-security&y=2026&m=slackware-security.1267034
• https://www.cve.org/CVERecord?id=CVE-2026-31431

#slackware #copyfail

EVERYONE GETS AN LPE

Windows:
#BlueHammer (#CVE_2026_33825)
#RedSun (#CVE_2026_41091)
#UnDefend (#CVE_2026_45498)
#WindowsInstaller (#CVE_2026_27910):

Linux:
#CopyFail (#CVE_2026_31431)
#SSHKeysignPwn (#CVE_2026_46333)

FreeBSD:
#FatGid (#CVE_2026_45250)
#ExecveBug (#CVE_2026_7270)

Releasing a universal #Linux #kernel #exploit with very little or even no previous time to distribute a patch through distributions is not cool. Doing it on the day before a weekend - on two weekends in a row - is just being an asshole. Looking at you, #CopyFail and #DirtyFrag.

You may think it helps your PR, that people will queue to use your cool new AI/agentic/whatever tool because you found the bug. You may think that releasing the full exploit because somebody else was even quicker with "leaking" your cool find makes it right. You're wrong. This is neither responsible nor coordinated disclosure. In security, we've tried to learn the hard lessons on keeping in-production, live systems on a global scale safer.

Yes, those bugs have existed for a long time in the kernel source. Yes, other bad actors may already have found them. But you're shining a light on it *and* giving every script kiddie in the world a working exploit to point their mass scans at. That's dangerous. There's a reason why the normal process is to reach out at least to the most widely installed distributions before releasing the bug details publicly. There's a reason why 90 days is a good default - it allows downstream percolation of patches. You can still get the credit. This way, you only create stress for admins.

[For a little relief, refer to https://www.tomshardware.com/tech-industry/cyber-security/dirty-frag-exploit-gets-root-on-most-linux-machines-since-2017-no-patches-available-no-warning-given-copy-fail-like-vulnerability-had-its-embargo-broken for a quick mitigation, because updating kernels and rebooting a fleet of hosts just takes time, weekend or not. #HugOps]