TC17 vulnerable to copy.fail (CVE-2026-31431)

[adb014]

For information the kernel config of TC17 includes

CONFIG_CRYPTO_USER_API_AEAD=y

and so the kernel of of TC17 is vulnerable to copy.fail and blacklisting the modprobe of algif_aeqd as suggested in some remediation guides is not possible. The easiest fix for this would be to recompile the kernel with

CONFIG_CRYPTO_USER_API_AEAD=n

though a better fix would be to update the kernel to 6.18.22 or later, or backporting the kernel patch for 6.18.22 (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8)

[Juanito]

Does this boot code disable the module?

Code: [Select]

initcall_blacklist=algif_aead_init

[adb014]

According to https://blog.cloudlinux.com/cve-2026-31431-copy-fail-mitigation-and-patches yes this will block the attack

[mjmouse]

Code: [Select]

initcall_blacklist=algif_aead_init


Unfortunately that doesn't, at least with TinyCore 16.

Scripts at https://github.com/rootsecdev/cve_2026_31431 (modifying /etc/passwd to have an id of 0000 in the line, and then having su misled into authenticating root) still work.

Code: [Select]

[    0.013375] Kernel command line: BOOT_IMAGE=/tce/boot/vmlinuz64 quiet syslog safe showapps vga=normal [...] initcall_blacklist=algif_aead_init initrd=/tce/boot/corepure64.gz
[    0.013678] initcall_blacklist requires CONFIG_KALLSYMS
[    0.013723] Unknown kernel command line parameters "syslog safe showapps BOOT_IMAGE=/tce/boot/vmlinuz64 vga=normal [...] initcall_blacklist=algif_aead_init", will be passed to user space.

(snipped out tce/etc parameters)

[adb014]

Looking that the kernel config of TC17

Code: [Select]

$ grep CONFIG_KALL config-6.18.2-tinycore64
# CONFIG_KALLSYMS is not set

Given the error message of mjmouse, TC17 will have the same problem

[vext01]

This is a bit worrying, and kind of deterring me from using tc for my project.

Did anyone find an easy workaround?

backporting the kernel patch for 6.18.22

Sounds like the proper fix?

[Juanito]

We're working on updating to 6.18.28

[vext01]

Fantastic. Thank you!

[vext01]

Is it likely that picore will get an update too?

[vext01]

Just looking at the picore 16 kernel configs. They have:

Code: [Select]

CONFIG_CRYPTO_USER_API_AEAD=m

So, as long as you don't load that module, I *think* picore isn't affected and the blacklist approach can be used to stop it being loaded.


I checked every picore kernel config I could find:

• http://tinycorelinux.net/16.x/armhf/release/src/kernel/6.12.25-piCore-v7_.config.xz
• http://tinycorelinux.net/16.x/armhf/release/src/kernel/6.12.25-piCore-v7l_.config.xz
• http://tinycorelinux.net/16.x/armhf/release/src/kernel/6.12.25-piCore_.config.xz
• http://tinycorelinux.net/16.x/aarch64/release/src/kernel/6.12.25-piCore-v8-16k_.config.xz
• http://tinycorelinux.net/16.x/aarch64/release/src/kernel/6.12.25-piCore-v8_.config.xz

With `initcall_blacklist=algif_aead_init` on the kernel command line, I am unable to load the module, which is good:

Code: [Select]

$ sudo modprobe algif_aead
modprobe: can't load module algif_aead (kernel/crypto/algif_aead.ko.gz): Operation not permitted

If I remove that bootcode, however, the module *does* load.

So, I think picore 16 is safe, as long as you blacklist the module. Correct me if I'm wrong though.

[Paul_123]

The module is not even packaged in piCore   Unless you go to the complete module pack and download and manually create a method to install it.

All this is really pointless for tc anyway, since the default user is TC and it automatically logs in, and by default is setup for password less sudo.   IF you change the default behavior of tc, then just delete the module from your system.

[vext01]

The module is not even packaged in piCore

The module does appear to be present on picore:

Code: [Select]

$ find / -name algif_aead.ko.gz 2> /dev/null
/lib/modules/6.12.25-piCore/kernel/crypto/algif_aead.ko.gz

This was picore 16 on 32-bit pi. I didn't install it manually, so I assume it's part of the root filesystem.

All this is really pointless for tc anyway, since the default user is TC and it automatically logs in, and by default is setup for password less sudo.

Point taken, but I still think it's worth protecting against. For example, I've made a separate user account for another purpose, and I'd like that to be locked down as much as possible, and thus I've not given it sudo access.

Cheers