CVE-2026-31474

What it actually does

This is a local use-after-free vulnerability in the Linux kernel CAN ISO-TP networking implementation. A race condition can occur between isotp_sendmsg() and isotp_release(): if close() is interrupted by a signal while transmission state is ISOTP_SENDING, release processing may free the socket transmit buffer while sendmsg() is still using it to build the final CAN frame. An attacker with local access and the ability to create/use CAN ISO-TP sockets could potentially trigger memory corruption in kernel context, leading to kernel crash or, depending on heap state and exploit reliability, local privilege escalation.

Why it matters to the business

Successful exploitation could allow a local user or compromised low-privileged process to crash affected Linux systems or potentially gain elevated privileges. This is most relevant for systems with CAN or virtual CAN functionality enabled, including automotive, embedded, industrial, test, and development environments. The vulnerability is not listed in CISA KEV, has no known mature public exploit in the provided data, and has a low, flat EPSS score, so urgency is lower than internet-facing remote-code-execution issues; however, kernel privilege-escalation bugs should still be prioritized on multi-user systems, container hosts, CI runners, and devices where local code execution is plausible.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged or low-privileged user on an affected Linux system. They then create and use CAN ISO-TP sockets, potentially with a virtual CAN interface if available, and send ISO-TP messages large enough to cause the transmit buffer to be extended. The attacker races sendmsg() activity against socket close/release behavior and interrupts close() with a signal while the socket transmit state remains ISOTP_SENDING. In the vulnerable kernel path, isotp_release() can proceed to free the transmit buffer even though isotp_sendmsg() is still reading it in isotp_fill_dataframe(). This creates a use-after-free in kernel memory. A simple attempt may cause a kernel oops or panic; a more advanced exploit would attempt to shape kernel heap allocations so the freed buffer is replaced with attacker-controlled data, potentially enabling privilege escalation.

How to fix it

Update affected Linux kernels to a vendor-supported version that includes the CAN ISO-TP fix moving transmit-buffer freeing to socket destruction time rather than release-time. Because no exact fixed package versions were provided, use the distribution or device vendor advisory for the corresponding kernel package and confirm that the fix for the CAN ISO-TP isotp tx.buf use-after-free is included. Where immediate patching is not possible, reduce exposure by disabling or restricting CAN and CAN ISO-TP functionality where not needed, limiting access to CAN/vCAN interface creation, removing unnecessary can/isotp kernel modules if modularized and operationally safe, restricting unprivileged local shell/container access, and applying least-privilege controls such as seccomp, LSM profiles, container capability restrictions, and module-loading controls.

How to confirm the fix worked

Confirm the running kernel is updated to a vendor build containing the CAN ISO-TP fix for isotp_sendmsg()/isotp_release() transmit-buffer lifetime handling. Validate with package-manager inventory, vendor advisory mapping, kernel changelogs, or source/commit verification where applicable. Check whether CAN ISO-TP support is present by reviewing loaded modules and kernel configuration, such as lsmod output for CAN-related modules and kernel config entries for CAN_ISOTP. If mitigation rather than patching is used, verify that CAN ISO-TP modules are not loaded, cannot be loaded by unprivileged users, and that unneeded CAN/vCAN interfaces are absent. In test environments, regression testing should confirm that ISO-TP socket send/close operations no longer produce kernel warnings, KASAN reports, oopses, or panics.

Typical attack path

1. Gain local execution on an affected Linux host as a low-privileged user or compromised process.
2. Ensure CAN ISO-TP functionality is available, for example through a physical CAN interface or a virtual CAN setup if permitted.
3. Create a CAN ISO-TP socket and perform sendmsg() operations that require an extended transmit buffer.
4. Trigger a race between active transmission and socket close/release handling.
5. Interrupt close() with a signal while the ISO-TP transmit state is still ISOTP_SENDING.
6. Cause isotp_release() to free the transmit buffer while isotp_sendmsg() continues using it.
7. Use the resulting kernel use-after-free to crash the host or attempt controlled kernel memory corruption for privilege escalation.

How to detect it

There are no reliable network-only indicators for this local kernel vulnerability. To assess possible prior exploitation, review kernel logs, system journals, crash dumps, and EDR telemetry for kernel oopses, panics, KASAN reports, or stack traces involving CAN ISO-TP functions such as isotp_sendmsg(), isotp_release(), and isotp_fill_dataframe(). Examine audit logs and shell/process history for creation or manipulation of CAN/vCAN interfaces, loading of CAN-related modules, or suspicious local programs repeatedly opening, sending on, and closing ISO-TP sockets. On containerized systems, look for workloads granted CAP_NET_ADMIN or device access that also perform CAN/vCAN setup. Because exploitation may only leave evidence as instability or a crash, absence of logs does not prove absence of exploitation, especially if persistent kernel logs or crash dumps are not retained.

• isotp_sendmsg
• isotp_release
• isotp_fill_dataframe
• can: isotp
• CAN_ISOTP
• use-after-free in isotp_sendmsg
• BUG: KASAN: use-after-free
• kernel NULL pointer dereference
• general protection fault
• Kernel panic
• Oops
• vcan
• modprobe can-isotp
• modprobe vcan
• ip link add dev vcan0 type vcan
• ip link set up vcan0

What your security team should do

• Patch affected Linux kernels during the next appropriate maintenance window, prioritizing multi-user systems, container hosts, CI/build workers, embedded/automotive systems, and any host where untrusted local code can run.
• Inventory systems with CAN, vCAN, or ISO-TP support enabled and prioritize them over systems without CAN networking functionality.
• If patching is delayed, disable unused CAN ISO-TP functionality and restrict module loading, network administration capabilities, and access to CAN/vCAN interface creation.
• Monitor kernel logs for crashes, KASAN use-after-free reports, or suspicious CAN ISO-TP activity, especially on systems where local users or containers can interact with CAN sockets.
• Review container and sandbox policies to ensure untrusted workloads do not have CAP_NET_ADMIN, broad device access, or permissions that allow creation or manipulation of CAN/vCAN interfaces unless required.
• Track vendor kernel advisories because fixed package versions vary by distribution and appliance vendor.
• Treat unexplained kernel panics involving isotp_sendmsg, isotp_release, or isotp_fill_dataframe as potentially security-relevant and preserve crash dumps for analysis.