5 ms·

The Bleeping Computer link below mentions a potential remedy until a patch is ready. https://www.bleepingcomputer.com/news/security/new-linux-copy-fail-flaw-gi

• jayofdoom 5mo ago
  This workaround only applies to kernels with the impacted code compiled as a module. RHEL, Fedora, and Gentoo (we use a modified Fedora config) all are configured to build this in directly. Without a patch or config change (as Sam from Gentoo was alluding to), those distributions remain vulnerable.
  • jcul 5mo ago
    There was some discussion on the GitHub issues about workarounds to disable it, even though it is baked in. https://github.com/theori-io/copy-fail-CVE-2026-31431/issues/30 https://github.com/theori-io/copy-fail-CVE-2026-31431/issues... https://github.com/theori-io/copy-fail-CVE-2026-31431/issues/60 https://github.com/theori-io/copy-fail-CVE-2026-31431/issues...
  • pitrdevries 5mo ago
    This worked as a mitigation on distros with the module compiled into the kernel: https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464da https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464d... Basically: sudo grubby --update-kernel=ALL --args=initcall_blacklist=algif_aead_init sudo reboot
  • akdev1l 5mo ago
    F44 is safe as the kernel is greater than 6.18.22
  • ranger_danger 5mo ago
    For compiled-in kernels you can also work around it without rebooting via apparmor, seccomp or SELinux at the least, there may be eBPF or other methods too.
• holowoodman 5mo ago
  The potential remedy doesn't work on RedHat and derivatives because the affected code is not a module there but statically compiled in.