So far all the information suggested to disable esp and rxrpc modules.

This bulletin suggest that more modules are necessary for complete mitigation

VPN usage increased, but how to they draw the conclusion that this is children. I think it's more likely that adults are using VPNs to not have to deal with the ID process. I would do that.

As VPNs usually cost some money, which is already a barrier for minors.

CAP_NET/SYS_ADMIN is required for this. So this would be "not as bad" as the others.

Also "The page pool is only created on a real ZCRX-capable NIC (mlx5 ConnectX-6+, Intel E800, NFP)"

It could work for container escape?

Containers, even with root user, are often stripped of these capabilities unless --privileged

It is a minimal improvement due to the introduction of user namespaces and the fallout from local team convenience for Docker and thus OCI.

It is very important that you realize that any capability is a slice of superuser privileges, and there are no implicit protections, only explicit additional constraints that restrict it in reference to root.

Look at the bounding set for a normal user on a fresh install of rhel/debian based systems:

     $ grep ^Cap /proc/$$/status
     CapInh: 0000000000000000
     CapPrm: 0000000000000000
     CapEff: 0000000000000000
     CapBnd: 000001ffffffffff

Note how trivial it is to gain all of those capabilities:

    $ podman unshare
    # grep ^Cap /proc/$$/status
    CapInh: 0000000000000000
    CapPrm: 000001ffffffffff
    CapEff: 000001ffffffffff
    CapBnd: 000001ffffffffff
    CapAmb: 0000000000000000
    # capsh --decode=000001ffffffffff
    0x000001ffffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore

The capabilities(7)[0] man page will help you with all of those.

But capabilities are just a thread local segmentation, which grants superuser or root rights in a vertical segmented fashion.

True, if a mechanism chooses to do additional tests based on credentials(7)[1], you can run with those elevated privileges in a lower bound, but that requires implicit coding.

Add in that LSMs are suffering from both resources and upstream teams that won't provide guidance or are challenging to work with, and there are literally a hundred commands to either abuse or just ld_preload to get unrestricted userns, allowing you to get around basic controls on clone()/unshare() that may be implemented.

      $ grep -ir "userns," /etc/apparmor.d/ | wc -l
      100

With apparmor every single browser (firefox,chrome,msedge,etc...) as well as busybox, slack, steam, visual studio, ... all have the unrestricted user namespaces and the ability to gain the FULL set of capabilities in the bounding set.

If you run `busybox` on a debian system, note how it has nsenter and unshare, so you can't mask those and yet busybox itself is unconstrained with elevated privlages.

The TL;DR point being, don't assume that any capability() is in itself a gate, as there are so many ways even for the user nobody to gain them.

[0] https://man7.org/linux/man-pages/man7/capabilities.7.html [1] https://man7.org/linux/man-pages/man7/credentials.7.html

It's scary to think that some day it will be more than a local attack vector. I don't want to imagine the fallout from a remote rce via tcp/ip.

These copyfail exploits allow an unprivileged (daemon/app) user (not in sudoers) to get root without interaction from the original system maintainer.

It's quite different from PATH-injecting an already privileged user.

Also, these memory corruptions can likely be used as container escape primitives too. Albeit not easily.

It's a serious break of a security boundary. Yes, container layer adds defense, and normal unix security isn't perfect, but it should not allow this.

Copy Fail can't affect files it can't access.

PoC attack on k8s [1] claims execution through sibling layers of kube-proxy, host filesystem access through /dev/ [2].

[1] https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...

[2] https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...

Maybe it would be reasonable for sysadmins to proactively whitelist used / block all exotic unused modules that are not needed in their system configuration.

This would reduce the amount of ring 0 code. But I've never seen such advice.

That is true, but if at least the widely used ones would get notified before that would be beneficial. If they have a responsible security contact point.

- Debian

- Ubuntu

- Arch

- Amazon/Azure

- Fedora/RHEL

Then those that aren't notified will complain. I think it's on the distros to follow kernel developments since they are consumers of the kernel, not the other way around. Kernel devs can't possibly know all of the stakeholders that they need to notify.

Major os vendors will publish pages with the fixed versions:

https://security-tracker.debian.org/tracker/CVE-2026-31431

https://ubuntu.com/security/CVE-2026-31431

Also, disabling algif_aead is suggested as mitigation

Where are you seeing the disabling algif_aead mitigation?

In TFA: https://copy.fail/#mitigation

> Before you can patch: disable the algif_aead module.

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

> rmmod algif_aead 2>/dev/null || true

Edit: and I can confirm that on my system with kernel 6.19.8 the above fixes the exploit.

Weirdly, the mitigation does not seem to work under WSL2 (at least in Ubuntu 24.04).

    Linux wsl2 6.6.87.2-microsoft-standard-WSL2 ...

`modprobe algif_aead` errors out, but if I run the POC, it succeeds.

Outside of WSL2, the mitigation does appear to work though.

It's possible that the WSL kernel has that code compiled-in rather than as a loadable module. If they ship the kernel config somewhere, you could verify with

  zgrep CRYPTO_USER_API_AEAD /proc/config.gz /boot/config-*

It should show =m if it's a loadable module, and =y if it's compiled in.

It's a loadable module:

    CONFIG_CRYPTO_USER_API_AEAD=m

Using bpftrace to watch calls to module_request, openat, etc., it looks like when the kernel calls modprobe, it doesn't even look at the disable-algif.conf file:

    [module_request] pid=3648 comm=python name=algif-aead
    [umh_setup] pid=3648 comm=python path=/sbin/modprobe argv0=/sbin/modprobe argv1=-q argv2=-- argv3=algif-aead argv4=
    [openat] pid=3688 file=/etc/ld.so.cache
    [openat] pid=3688 file=/lib/liblzma.so.5
    [openat] pid=3688 file=/lib/libz.so.1
    [openat] pid=3688 file=/lib/libgcc_s.so.1
    [openat] pid=3688 file=/lib/libc.so.6
    [openat] pid=3688 file=/etc/modprobe.d
    [openat] pid=3688 file=/lib/modprobe.d
    [openat] pid=3688 file=/lib/modprobe.d/dist-blacklist.conf
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.softdep
    [openat] pid=3688 file=/lib/modprobe.d/systemd.conf
    [openat] pid=3688 file=/etc/modprobe.d/usb.conf
    [openat] pid=3688 file=/proc/cmdline
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.dep.bin
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.alias.bin..
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.symbols.b..
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.builtin.a..
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.builtin.b..
    [openat] pid=3688 file=/sys/module/algif_aead/initstate
    [openat] pid=3688 file=/sys/module/af_alg/initstate
    [openat] pid=3688 file=/sys/module/algif_aead/initstate
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/kernel/crypto/alg..
    [finit_module] pid=3688 comm=modprobe fd=0 flags=0
    [module_load] pid=3688 comm=modprobe name=algif_aead

Restart WSL2, run the bpftrace, and try `sudo modprobe algif-aead`, and that shows it looking at (or I guess opening) other files in /etc/modprobe.d, including the new one.

The mystery is why.

In wsl, each distro you have runs in a container (with lot of permissions), you'd need to apply the modprobe change inside wsl "hypervisor" rootfs

The only way to solve this issue in WSL is to rebuild your kernel:

~ uname -r

6.18.20.3-microsoft-standard-WSL2+

This can likely be shipped as binary code without dependencies like python, as the bug is in the kernel.

C version here: https://gist.github.com/alufers/921cd6c4b606c5014d6cc61eefb0...

Young people setting up a MITM and getting deeper into tech rather than consuming short-form-content is something I'd appreciate as a nice bonus effect.

Of course the EU solution isn't perfect and there are bypasses (there will always be and have always been), but let's appreciate it that way rather than too many PII, if it must come. I'd prefer the Age/RTA header and parental responsibility too.