CVE-2026-31532

What it actually does

This is a local Linux kernel use-after-free in the CAN RAW socket implementation. When a RAW CAN socket is released, receive filters are unregistered, but their deletion is deferred through RCU. The vulnerable code frees the per-CPU `ro->uniq` storage too early, leaving a race window where `raw_rcv()` can still access freed memory while processing a CAN frame. A local user able to create and manipulate CAN RAW sockets may be able to trigger kernel memory corruption, which can lead to kernel crash, information disclosure, or privilege escalation depending on allocator behavior, kernel hardening, and exploit reliability.

Why it matters to the business

Successful exploitation could allow a local attacker or compromised low-privileged account to gain elevated privileges or crash affected Linux systems. The highest operational concern is for Linux systems using CAN functionality, such as automotive, embedded, robotics, industrial, test-bench, and gateway environments, where kernel crashes can interrupt physical operations or device communications. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a very low EPSS score with no observed 30-day increase, so broad internet-scale exploitation is unlikely; however, kernel privilege-escalation bugs should still be remediated because they are valuable for post-compromise escalation.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged or low-privileged user on a Linux system where CAN RAW socket support is available. They create CAN RAW sockets, register receive filters, arrange for CAN frame delivery, and then rapidly close or release sockets while receive processing is still occurring. Because filter teardown is deferred through RCU, `raw_rcv()` may continue running after `raw_release()` has freed the associated per-CPU `uniq` storage. By repeatedly winning this race and shaping kernel heap/per-CPU memory reuse, an attacker may convert the use-after-free into memory corruption. In the simplest case this produces a kernel oops or panic; with a reliable exploit and favorable kernel configuration, it may be used to alter kernel memory and gain root-level privileges.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution, appliance, or device vendor that includes the upstream fix for the CAN RAW socket `ro->uniq` lifetime issue. No exact fixed package versions were provided in the input, so remediation should be tracked through vendor advisories and kernel changelogs for the affected product line. Where immediate patching is not possible, reduce exposure by disabling CAN RAW support if it is not required, preventing the `can_raw` module from loading, compiling kernels without unused CAN RAW support, limiting local shell access to trusted users, and applying defense-in-depth controls such as SELinux/AppArmor confinement, container isolation, kernel lockdown, module loading restrictions, and rapid reboot/rollback procedures for unstable systems. Systems that require CAN functionality should prioritize vendor kernel updates over feature disablement.

How to confirm the fix worked

Confirm the running kernel version is a vendor build that contains the fix, not only that an updated package is installed but also that the host has rebooted into the fixed kernel. Validate through distribution advisories, package changelogs, kernel source, or vendor release notes that the CAN RAW fix is present. If source validation is possible, confirm that `free_percpu(ro->uniq)` is no longer performed directly from `raw_release()` before RCU callbacks can drain and that cleanup occurs through the socket destructor path. For mitigations, confirm `can_raw` is not loaded with `lsmod`, is blocked by module policy if unused, and that CAN RAW socket creation is not available where it should be disabled. Review kernel logs after testing for absence of new `raw_rcv`, `can_rx_unregister`, KASAN, oops, or panic messages.

Typical attack path

1. Gain local code execution on an affected Linux host, container, embedded device, or appliance.
2. Verify that CAN and CAN RAW socket support is present or loadable, such as via the `can_raw` kernel module or built-in kernel support.
3. Create `PF_CAN` / `SOCK_RAW` / `CAN_RAW` sockets and configure receive filters.
4. Generate or trigger CAN frame reception while concurrently closing/releasing RAW CAN sockets.
5. Race the RCU-deferred receive-filter cleanup so that `raw_rcv()` accesses freed `ro->uniq` per-CPU memory.
6. Repeat the race to cause a kernel crash or attempt controlled kernel memory corruption.
7. If exploitation is reliable, escalate privileges, disable defenses, or maintain persistence using the newly obtained privileges.

How to detect it

There are no public, unique exploitation indicators for this issue, and successful kernel privilege escalation may leave few direct artifacts. Focus detection on crash evidence, kernel memory-safety alerts, and suspicious local activity around CAN RAW sockets. Review `dmesg`, journald, syslog, kernel crash dumps, pstore, netconsole output, and EDR telemetry for oops, panic, KASAN, KFENCE, or general-protection-fault messages referencing `raw_rcv`, `raw_release`, `can_rx_unregister`, or CAN RAW paths. On systems with auditd, eBPF, or syscall tracing, look for unusual bursts of `socket(AF_CAN, SOCK_RAW, CAN_RAW)`, `bind`, `setsockopt`, `close`, and CAN frame activity by non-standard users or processes. After any suspicious crash, perform post-incident checks for privilege-escalation outcomes such as new root-equivalent users, unexpected setuid/setcap files, unauthorized kernel modules, altered sudoers files, disabled security agents, and unusual persistence mechanisms. If threat hunting at scale, correlate kernel crashes involving CAN code with recent local logins, container escapes, suspicious compilers or exploit toolchains, and process execution in writable directories such as `/tmp`, `/var/tmp`, or `/dev/shm`.

• KASAN: use-after-free
• BUG: KASAN: use-after-free in raw_rcv
• raw_rcv
• raw_release
• can_rx_unregister
• can_rcv_filter
• can: raw
• PF_CAN
• CAN_RAW
• SOCK_RAW
• general protection fault
• kernel BUG at net/can/raw.c
• Oops:
• Kernel panic
• can_raw

What your security team should do

• Inventory Linux systems, embedded devices, appliances, and workloads that enable CAN or load the `can_raw` module.
• Prioritize patching systems that expose local user access, run untrusted workloads, support containers with broad kernel access, or operate in automotive, industrial, robotics, or test environments that rely on CAN.
• Apply vendor kernel updates containing the fix and reboot into the fixed kernel; verify the active kernel version after reboot.
• Disable or blacklist CAN RAW support on systems that do not require CAN functionality.
• Restrict local interactive access and reduce the ability of untrusted users or containers to create raw CAN sockets where feasible.
• Monitor kernel logs for oops, panic, KASAN, or stack traces involving CAN RAW receive paths.
• Hunt for signs of local privilege escalation following unexplained kernel crashes, including newly created privileged accounts, unexpected setuid binaries, suspicious kernel modules, and tampered security controls.
• Because EPSS is low and there is no KEV listing or known ransomware use, handle as a normal-to-high priority kernel hardening update unless CAN-enabled systems are business-critical or exposed to untrusted local users.