Mitigating "Copy Fail" and "Dirty Frag" vulnerabilities on DietPi

[AdamF100001]

ADMIN EDIT

The two major recent Linux vulnerabilities are:

• CVE-2026-31431 aka "Copy Fail"
• CVE-2026-43284 and CVE-2026-43500 aka "Dirty Frag"

We pushed updates for all our kernel packages. For the SBCs with too old frozen Linux version, the affected kernel modules have been removed.

Debian and Raspberry Pi Ltd pushed kernel package updates containing the mitigation as well.

Hence, all that needs to be done now is:

sudo apt update
sudo apt full-upgrade # "full" needed for our linux-dtb + linux-image package merger on Armbian-based builds
sudo reboot

If, after the reboot, the Linux version is still below v7.0.6, v6.18.29, v6.12.87 (or v6.12.86 on x86_64, which has a backported patch), v6.6.138, v6.1.172, respectively, verify that the modules are not available:

modinfo algif_aead esp4 esp6 rxrpc

In case you use an unsupported SBC or custom kernel that is too old and still has one of the above modules available, prevent them from being loaded like that:

printf 'install algif_aead /bin/false\nblacklist algif_aead\n' | sudo tee /etc/modprobe.d/copyfail.conf
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' | sudo tee /etc/modprobe.d/dirtyfrag.conf
printf 'blacklist esp4\nblacklist esp6\nblacklist rxrpc\n' | sudo tee -a /etc/modprobe.d/dirtyfrag.conf
sudo modprobe -r algif_aead esp4 esp6 rxrpc
echo 3 | sudo tee /proc/sys/vm/drop_caches

---

Hi All,

Just a quick question when will Copy Fail CVE-2026-31431 be patched in DietPi?

Thanks

[Joulinar]

Unfortunately you missed to fill the trouble shooting template. So we don't know the device you are running on. On RPi we don't manage the kernel. This one to be done by RPi developer.

[MichaIng]

So the fix was merged into Linux 7.0 end of March already. Into Linux 6.19 and 6.18 (mostly relevant for our Linux builds) mid April, and into Linux 6.12 just yesterday (relevant for RPi and x86_64 (Trixie) Linux builds).

This matches the affected versions table as well: https://nvd.nist.gov/vuln/detail/CVE-2026-31431#vulnConfigurationsArea
We did our builds 2 days before the fix in April, aside of 64-bit Rockchip and 64-bit Allwinner where we pushed newer builds later, for some other fixes. So those two families have it patched already.

So I'll trigger our monthly builds now, a week earlier than usually, to have this fix included in Amlogic and 32-bit Rockchip + Allwinner, and our dedicated Quartz64 builds. Odroid C1, XU4, and Rockchip vendor Linux 6.1 won't have the fix, as they have pinned patch versions. The XU4 will likely get it soon, for RK3588 SBCs, one would need to switch to mainline Linux, which is strongly recommended anyway (and includes tons of more closed CVEs since 6.1.115), unless certain features are needed, e.g. missing WiFi driver for some of the Orange Pi 5 variants.

Let's see for the builds we do not manage:

• Debian pushed updates for all supported Debian version already 👍.
• RPi Ltd did not. I also do not see an open issue or forum topic where this would have been requested. However, they prepare for Linux 6.18 already. Not sure whether they will push a new 6.12 version or 6.18 earlier than planned for this. Kernel vulnerabilities are common, almost every point release closes some CVE(s). This one seems to be in the userspace crypto module, which is not loaded on any system I manage:

  lsmod | grep af_alg

  But it really is a module that can be loaded:

  modinfo af_alg

  Hence, I am not sure about the overall severity. It might be high, IF that feature is used, but it might be used only in 1% of cases or so.

[MichaIng]

These kernel builds will include another structural change I applied last week: linux-image-* and linux-dtb-* packages will be merged. The /boot/dtb dir and related postinst steps are now part of linux-image-*, and its /usr/lib/linux-image-* is a symlink to /boot/dtb-* to avoid a breaking change. This makes kernel up- and downgrades more robust, and fixes some situations of possible dtb and image mismatches, and the fact that dpkg-reconfigure did leave the system without device tree, and in case of a dedicated /boot partition even with the Linux image removed.

But, since the upgrade implies a conflict with and removal of linux-dtb-*, it needs to be confirmed on apt upgrade, or apt full-upgrade is needed. We'll enforce that during next DietPi update as well.

Not bad to have this merged a week earlier, so we receive reports more gradually before the DietPi release, if there are any issues.

[MichaIng]

All our kernel/U-Boot/firmware packages have been updated. To apply them:

apt update
apt full-upgrade

As mentioned above, the "full" upgrade is needed for APT to remove the now obsolete linux-dtb-* package.

[ascopes]

Just reading this. Am I missing any steps to get this available on DietPi for the Raspberry Pi 3B with DietPi v10.3?

$ uname -srv
Linux 6.12.75+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.75-1+rpt1 (2026-03-11)

$ sudo apt update
Hit:1 https://deb.debian.org/debian trixie InRelease
Get:2 https://deb.debian.org/debian trixie-updates InRelease [47.3 kB]
Hit:3 https://deb.debian.org/debian-security trixie-security InRelease         
Get:4 https://deb.debian.org/debian trixie-backports InRelease [54.0 kB]
Hit:5 https://archive.raspberrypi.com/debian trixie InRelease
Hit:6 https://dietpi.com/apt trixie InRelease
Hit:7 https://dietpi.com/apt all InRelease
Fetched 101 kB in 1s (118 kB/s)
All packages are up to date.

$ sudo apt full-upgrade
Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

$ curl -sL https://raw.githubusercontent.com/rootsecdev/cve_2026_31431/refs/heads/main/test_cve_2026_31431.py | python3
[*] CVE-2026-31431 detector  kernel=6.12.75+rpt-rpi-v8  arch=aarch64
[+] AF_ALG + 'authencesn(hmac(sha256),cbc(aes))' loadable - precondition met.
[!] VULNERABLE to CVE-2026-31431.
[!]   Marker b'PWND' (AAD seqno_lo) landed in the spliced page-cache page at offset 0.
[!]   Surrounding bytes: 50574e444641494c2d53454e  (b'PWNDFAIL-SEN')
[!] Apply the upstream fix or block algif_aead immediately.

[Joulinar]

For Raspberry Pi, kernel needs to be updated by RPI developer. We are not maintaining the RPi kernel. There is no relation to a DietPi version or DietPi code.

Check RPI forum for any updates https://forums.raspberrypi.com/viewtopic.php?t=397946&sid=250d6e42881589c231db2d7d0ea810f1

Looks they are going to fix it in 6.18 (currently in testing). Not sure if there will be an update for 6.12. This is all within responsibility of RPi developer

[MichaIng]

Great, so there is a topic at the RPi forum already. And what a heated diacussion, with a lot of misunderstanding about how RPi kernel development works 😄.

As said, this bug is in an API provided by a particular driver that I do not see loaded on any of the 3 production systems and about 20 test systems I checked while testing our own updated kernel builds. If you want to be sure it cannot be loaded until next RPi kernel upgrade:

echo 'install algif_aead /bin/false' | sudo tee /etc/modprobe.d/disable-algif.conf
sudo modprobe -r algif_aead

af_alg I mentioned above is the parent driver, but only algif_aead seems to contain the vulnerability. I didn't see any of both loaded anywhere. Would be intetesting to know whether some software breaks with this, or throws errors/warnings or so.

For Rockchip vendor Linux and Odroid C1, we might in case just patch this config into our images, or find the kernel build config key to exclude that module. We could also patch the fix into the kernel source, but there were quite some follow-up commits, which might or might not be needed to fully mitigate things, or restore the API's functionality/performance. So instead of hoping to patch it right, we probably better disable it alltogether.