A security vulnerability (CVE-2026-43284) found in the Linux kernel may allow a local unprivileged user to escalate privileges to root. To exploit this vulnerability, an attacker only needs:

• the ability to create user namespaces
• permission to execute at least one setuid binary (for example, sudo, passwd, or fusermount)

Any standard Linux user account with shell access typically meets these requirements.

The vulnerability allows the page cache of a loaded binary to be arbitrarily modified, potentially affecting more than just privilege escalation. For example, an attacker could use this vector from inside a compromised container to corrupt the page cache for a file that is on a layer that is shared between containers, affecting all containers using that layer. Similarly, corruption of bind-mounted host files would also affect the host system.

All versions of the Linux kernel since 4.11.0, released in 2017, are affected.

The vulnerability has patches available in upstream Linux kernel releases for all currently-supported branches, including 5.15 (patched in 5.15.206), 6.1 (patched in 6.1.172), and 6.6 (patched in 6.6.138).

Are you affected?

You are likely affected if all of the following are true:

• Your device runs:
  • Torizon OS 6.x or 7.x released before May 2026 (6.0.0 - 6.8.7, 7.0.0 - 7.6.0), or
  • a custom Linux distribution using Linux kernel 4.11 or newer that has not been patched.
• Your system includes at least one unprivileged user account
• That user can execute a setuid binary (for example, sudo, passwd, or fusermount)
• Your kernel enables CONFIG_USER_NS and at least one of CONFIG_INET_ESP or CONFIG_INET6_ESP

For Torizon OS users, these kernel options are enabled by default.

For custom Yocto or BSP-based systems, verify whether CONFIG_USER_NS, CONFIG_INET_ESP, and CONFIG_INET6_ESP are enabled in your kernel configuration.

What should I do?

Toradex is working on patch releases for both BSP 6 and BSP 7, as well as the corresponding Torizon OS releases. This includes the Torizon OS 6.8.8 maintenance release and Torizon OS 7.6.1. We are currently completing the release process, and these updates will be available shortly. To receive a notification as soon as the releases are published Subscribe to Security Updates.

Although this vulnerability is serious, in the context of most embedded devices, it is only one link in an exploit chain. If your device has well-protected defenses against allowing users to execute arbitrary code, this vulnerability cannot be operationalized. Therefore, it may not merit an emergency out-of-band patch.

Torizon OS users
If you are using an affected version of Torizon OS, we recommend upgrading to the latest patched release as soon as it becomes available. If you have a threat model and use case that indicates this vulnerability affects your device immediately, we recommend disabling the vulnerable ESP modules.

Create the file /etc/modprobe.d/dirtyfrag.conf with the following contents:

install esp4 /bin/false
install esp6 /bin/false

Then reboot the device to apply the mitigation.

Toradex BSP/Custom Yocto Linux Distribution users
The Toradex BSP layer does not automatically enable the ESP4/ESP6 modules (CONFIG_INET_ESP/CONFIG_INET6_ESP are not set). We recommend auditing your image and kernel config to determine if you have a vulnerable version, and patching/upgrading as soon as the updated BSP releases are available.

If you have a threat model and use case that indicates this vulnerability affects your device immediately, we recommend issuing the following update:

• If CONFIG_INET_ESP/CONFIG_INET6_ESP=y (built into the kernel), add initcall_blacklist=esp4_init,esp6_init to the kernel command line.
• If CONFIG_INET_ESP/CONFIG_INET6_ESP=m (compiled as a module), blacklist the esp4 and esp6 kernel modules.

Q&A

• I don't have any unprivileged Linux user accounts on my device. Am I still affected?
  If you are certain that you do not have any unprivileged Linux user accounts, i.e., the only user on the device is root, you are not affected. However, note that most Linux distributions include the Name Service Switch, and allow users to be defined in places other than /etc/passwd, for example via nss-systemd. Check your /etc/nsswitch.conf file for all potential places where users may be defined, and/or run compgen -u to see the current list of defined users on your system.
• I don't allow shell access at all on my device. Am I still affected?
  Possibly. The only preconditions for executing this attack are that the unprivileged user must be able to create user namespaces, and read and execute any suid binary. Systems where the vulnerable ESP modules are not present are not affected by this vector. If you are following defense-in-depth best practices, like running applications and services with the least privilege they require, this page cache vulnerability strips away a very important layer of defense: any compromise of software running in an unprivileged user account that allows an attacker to execute arbitrary code will now also allow privilege escalation to root. Therefore, even if your non-root user accounts have login shells disabled, it is strongly recommended to update.
• The only unprivileged Linux user accounts on my device are inside application containers. Am I affected?
  Possibly. The page cache is shared across the host. Even a container can be affected by this vulnerability and result in a container escape primitive, not just LPE.