Mitigating Copy Fail CVE-2026-31431

User Support General
1

Is anyone aware of gotchas when mitigating Copy Fail CVE-2026-31431 [lwn.net, arstechnica.com, theregister.com] with

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

as detailed on the researchers’ site, or

# grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"

which Red Hat recommends here?

1 Like
2

No. None of those mitigations should be applied to Qubes OS from dom0. The issue is that Qubes runs multiple virtual machines, so blacklisting algif_aead in dom0 has no effect on kernels inside other VMs.

Fix this by updating the kernel where it runs:

  • If you use the stock Qubes kernels (the default), update Qubes OS from dom0 — that updates the kernels used by the vm and dom0.
    • Note: QubesOS ships 6.18.19 currently (as of 2026-05-01), which is affected by this issue. So unless QubesOS patched them, your system is still in danger while it is fully updated.
  • If you manually enabled a custom kernel inside a VM, update that VM’s (or it’s template’s) kernel package directly.
3 Likes
3

And your templates already allow passwordless root…

4 Likes
4

This vulnerability grants administrator privileges. On Qubes, thanks to the password-less ‘sudo’ command, these privileges are already readily available; therefore, the presence of this vulnerability is not particularly harmful.
Furthermore, this vulnerability poses more problems on shared servers than on single-user computers, which corresponds to the current use case for Qubes.

EDIT: xpost @parulin

2 Likes
5

No — it’s harmful.

A container escaping to replace critical host files is theoretically possible, so container-based applications (Flatpak, Firejail, Podman, etc.) are at risk. Modern web browsers that rely on namespace isolation (container-like sandboxes) could also be affected.

Even inside VMs, security matters. We don’t run every process in its own VM, so a VM’s internal protections must be robust. Privilege escalation on a machine configured for passwordless access is still privilege escalation: Qubes OS grants passwordless sudo to users in the qubes group (the VM’s user account), so this CVE would directly break that policy. Dismissing the issue as “not particularly harmful” is therefore misinformed.

3 Likes
6

Right, this is another case of “it depends on your threat model”. The fix isn’t specific to Qubes OS, though?

1 Like
7

FWIW, kernel-latest-qubes-vm-6.19.14 in the dom0 current-testing repo is new enough to include the fix.

2 Likes
8

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

1 Like
9

Of note: vulnerability is resolved in kernel version 6.19.12 and newer, which should be present in current Fedora 43/44 updates. I’ve done no work to validate this, but its what’s being reported.

10

Yes but unless the VMs were configured to use a kernel provided by the VM, VMs default to using the kernel provided by the dom0 kernel(-latest)-qubes-vm package.

1 Like
11

The patched kernels are all in testing ATM. Besides, SElinux is in place in dom0, AFAIK. Didn’t test it so far (re: preventing socket creation), though, since my QubesOS machines are all single user.

1 Like
12

Good point. However in my configuration I have the kernel-latest package installed in dom0. Unman commented on this: Is there a new kernel safe from copy.fail - #2 by unman

13
14

This is a little off topic but probably not worth creating a new thread for.

Apparently Copy-Fail was discovered by an AI named Xint Code that is designed to scan for security flaws. Someone turned Xint on the linux kernel and it found Copy-Fail in about an hour. Is anyone aware of any plans to use Xint to security test Xen?

1 Like