CVE-2026-68387: Linux Kernel Race Condition Vulnerability

CVE-2026-68387 Overview

CVE-2026-68387 is a race condition vulnerability in the Linux kernel's Controller Area Network (CAN) raw socket implementation. The flaw stems from missing locking around a bitfield used to store raw_sock flags. After commit 890e5198a6e5 consolidated separate integer flag values into a single bitfield, flag changes in raw_setsockopt() became read-modify-write operations. Concurrent socket option changes can corrupt the bitfield, producing inconsistent socket state. The fix introduces a raw_setsockopt_locked() wrapper that serializes access, mirroring the pattern used in net/can/isotp.c.

Critical Impact
A local attacker with access to CAN raw sockets can trigger concurrent setsockopt() calls to corrupt kernel socket state, potentially leading to memory corruption, privilege escalation, or denial of service.

Affected Products

Linux kernel versions containing commit 890e5198a6e5 ("can: raw: use bitfields to store flags in struct raw_sock") prior to the fix
Linux distributions shipping vulnerable stable kernel branches
Systems exposing the CAN PF_CAN/SOCK_RAW interface to unprivileged or containerized workloads

Discovery Timeline

2026-08-10 - CVE-2026-68387 published to NVD
2026-08-13 - Last updated in NVD database

Technical Details for CVE-2026-68387

Vulnerability Analysis

The vulnerability resides in the CAN raw protocol handler at net/can/raw.c. The raw_sock structure previously stored feature flags such as loopback, recv_own_msgs, fd_frames, xl_frames, and join_filters as individual integer fields. Each field could be updated atomically with a single store. The refactor into a packed bitfield forced the compiler to emit read-modify-write sequences whenever a single flag changed.

Without a lock protecting these operations, two threads invoking setsockopt() on the same socket can interleave their reads and writes. One thread's flag update overwrites the other's, leaving the bitfield in a state neither caller requested. Downstream logic that trusts these flags to gate frame reception, filter installation, or CAN FD handling then operates on corrupted state.

Root Cause

The root cause is the absence of serialization around a non-atomic read-modify-write on the raw_sock flags bitfield. Bitfield writes are not atomic on any mainstream architecture, so concurrent updates without a mutex or spinlock produce lost updates and torn state. This is a classic race condition [CWE-362] introduced by an optimization change that did not account for concurrent socket option paths.

Attack Vector

Exploitation requires local access and the ability to open a CAN raw socket, which is available to processes with CAP_NET_RAW or in namespaces that permit CAN socket creation. An attacker spawns multiple threads sharing a single CAN raw socket file descriptor and issues concurrent setsockopt() calls targeting the flag fields. Repeated racing corrupts the bitfield and can produce inconsistent kernel state that downstream code paths dereference or act upon. The published CVSS vector indicates local attack complexity is low and no user interaction is required.

The upstream fix wraps raw_setsockopt() with a locked variant, raw_setsockopt_locked(), so all flag mutations execute under socket lock. See the kernel commits at git.kernel.org 00ba4bf, git.kernel.org 1e5185c, and git.kernel.org 57791aa for the applied patches.

Detection Methods for CVE-2026-68387

Indicators of Compromise

Unexpected kernel warnings, KASAN reports, or oopses referencing raw_setsockopt, raw_sock, or net/can/raw.c
Processes without a legitimate CAN workload creating PF_CAN/SOCK_RAW sockets and issuing high-frequency setsockopt() calls
Multi-threaded workloads sharing a single CAN socket file descriptor across threads and invoking SOL_CAN_RAW options concurrently

Detection Strategies

Audit running kernel version against the patched stable release identifiers and flag hosts running vulnerable builds
Monitor syscall telemetry for concurrent setsockopt() calls on the same CAN socket from different threads of the same process
Enable lockdep and KASAN in test kernels to surface concurrent access patterns during pre-production validation

Monitoring Recommendations

Alert on unprivileged containers or workloads acquiring CAP_NET_RAW and opening AF_CAN sockets outside of expected CAN control applications
Track kernel crash telemetry and correlate stack traces containing raw_setsockopt or raw_rcv symbols
Log module load events for can_raw on systems that do not require CAN functionality

How to Mitigate CVE-2026-68387

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the vendor advisories and reboot affected hosts
Restrict CAP_NET_RAW and CAN socket creation to workloads that require it, using seccomp or namespace policy
Blacklist the can_raw kernel module on systems that do not use CAN networking

Patch Information

The fix is available in the mainline and stable Linux kernel trees via commits 00ba4bf8798242253fefc1fa6a78db1d445fd024, 1e5185c090589f4146d728ab36417d8a5419f127, and 57791aab1129c9405f84bb0882de58967d8b44cd. The patch adds a raw_setsockopt_locked() wrapper that holds the socket lock during flag mutations, eliminating the read-modify-write race. Consume the fix through your distribution's kernel package update channel.

Workarounds

Unload or blocklist the can_raw module where CAN is unused: add blacklist can_raw to /etc/modprobe.d/ configuration
Deny CAP_NET_RAW in container runtimes and seccomp profiles for workloads that do not require raw socket access
Avoid sharing a single CAN raw socket file descriptor across threads that concurrently call setsockopt() until patches are deployed

bash

# Configuration example: blocklist the can_raw module and drop CAP_NET_RAW
echo 'blacklist can_raw' | sudo tee /etc/modprobe.d/disable-can-raw.conf
sudo rmmod can_raw 2>/dev/null || true

# Example: strip CAP_NET_RAW from a container at runtime
docker run --cap-drop=NET_RAW --security-opt no-new-privileges <image>