CVE-2026-17523: Linux Kernel Privilege Escalation Flaw

CVE-2026-17523 Overview

CVE-2026-17523 is a flaw in the Linux kernel's Controller Area Network Broadcast Manager (net/can/bcm.c). An unprivileged local user can trigger the defect to execute arbitrary code in kernel context. Successful exploitation results in local privilege escalation (LPE) to root, giving the attacker full control of the affected system. The weakness is classified as CWE-825: Expired Pointer Dereference. The issue affects Linux kernel builds that ship the CAN BCM subsystem, which is common on Linux distributions used across servers, workstations, and embedded automotive stacks.

Critical Impact
A local, low-privileged account can gain root on any Linux host where the CAN BCM socket family is reachable, defeating standard user-boundary controls.

Affected Products

Linux kernel builds containing the net/can/bcm.c Broadcast Manager implementation
Red Hat Enterprise Linux distributions tracking this CVE (see Red Hat CVE-2026-17523 Advisory)
Downstream distributions that have not yet backported the upstream fix (torvalds/linux commit bf74aa86e111)

Discovery Timeline

2026-07-27 - CVE-2026-17523 published to NVD
2026-07-29 - Last updated in NVD database

Technical Details for CVE-2026-17523

Vulnerability Analysis

The defect resides in the Linux CAN Broadcast Manager, which lets user-space processes schedule and receive CAN frames through PF_CAN/CAN_BCM sockets. The subsystem manages per-socket operation lists that reference kernel objects with independent lifetimes. Under the vulnerable code path, the BCM code continues to use a pointer after its target has been released, matching the CWE-825 expired pointer dereference pattern.

An unprivileged local user can open a BCM socket, issue crafted sendmsg() operations, and manipulate timers or per-op state to force the kernel to dereference stale memory. Because the freed slab region can be reclaimed with attacker-controlled data, the flaw is a lifecycle bug that upgrades into arbitrary kernel code execution. The result is a reliable path from CAP_NONE to uid=0 with kernel privileges.

Root Cause

The root cause is improper lifetime management of BCM operation structures in net/can/bcm.c. Object release and reference paths are not correctly synchronized, so an operation can be freed while another code path retains and later dereferences the pointer. The upstream fix in commit bf74aa86e111aa3b2fbb25db37e3a3fab71b5b68 corrects this ordering.

Attack Vector

Exploitation requires local access and the ability to create a CAN BCM socket via socket(PF_CAN, SOCK_DGRAM, CAN_BCM). No user interaction is needed. The attacker triggers the expired pointer condition through crafted BCM control messages, sprays the freed slab to control the dereferenced object, and pivots kernel execution to escalate privileges. See the Red Hat Bug Report #2507407 for triage details.

Detection Methods for CVE-2026-17523

Indicators of Compromise

Unexpected processes opening PF_CAN / CAN_BCM sockets on hosts that do not use CAN networking
Kernel oops, BUG:, KASAN use-after-free, or general protection fault entries referencing bcm_ symbols in dmesg or /var/log/messages
New SUID binaries, cron entries, or root-owned files created shortly after non-root process activity involving CAN sockets
Loading of the can or can_bcm kernel modules on systems where they are not part of the baseline

Detection Strategies

Alert on socket() syscalls with AF_CAN (address family 29) originating from unprivileged, non-automotive workloads
Monitor finit_module/init_module events that load can_bcm outside of approved change windows
Correlate kernel crash telemetry containing bcm_ stack frames with the invoking user session for post-exploitation review
Flag privilege transitions where a process that recently opened a CAN socket subsequently spawns a shell with uid=0

Monitoring Recommendations

Ship auditdSYSCALL and MODULE_LOAD records to a central SIEM and retain kernel ring buffer output for forensic review
Baseline which hosts legitimately require the CAN stack, and treat CAN activity on all other hosts as high-severity
Track running kernel versions against distribution advisories to identify hosts still exposed to CVE-2026-17523

How to Mitigate CVE-2026-17523

Immediate Actions Required

Apply the vendor-provided kernel update that includes upstream commit bf74aa86e111aa3b2fbb25db37e3a3fab71b5b68 and reboot affected hosts
On systems that do not use CAN, blacklist the can and can_bcm modules to remove the attack surface entirely
Restrict local shell access on multi-tenant systems until patched kernels are deployed
Review audit logs for prior use of AF_CAN sockets by non-privileged users

Patch Information

The upstream fix is available in the mainline Linux tree (torvalds/linux commit bf74aa86e111). Distribution-specific packages and errata are tracked in the Red Hat CVE-2026-17523 Advisory and in the Red Hat Bug Report #2507407. Apply the vendor kernel matching your distribution.

Workarounds

Prevent module autoload by adding install can /bin/true and install can_bcm /bin/true to /etc/modprobe.d/
Unload the module at runtime with modprobe -r can_bcm on hosts that do not need CAN networking
Constrain untrusted workloads with seccomp profiles that deny socket() calls using AF_CAN

bash

# Configuration example: disable CAN BCM on hosts that do not use it
echo 'install can /bin/true'      | sudo tee /etc/modprobe.d/disable-can.conf
echo 'install can_bcm /bin/true'  | sudo tee -a /etc/modprobe.d/disable-can.conf
sudo modprobe -r can_bcm can 2>/dev/null || true
lsmod | grep -E '^can(_bcm)?' && echo 'CAN still loaded' || echo 'CAN disabled'