CVE-2026-23286 Overview
A null pointer dereference vulnerability has been identified in the Linux kernel's ATM LAN Emulation Client (LEC) module. The vulnerability exists in the lec_arp_clear_vccs() function, where improper handling of shared ATM Virtual Channel Connections (VCCs) across multiple ARP table entries can lead to a null pointer dereference when the underlying VCC is closed.
This issue was discovered through syzkaller, a kernel fuzzing tool, and can be reliably reproduced using the syzkaller reproducer. The vulnerability affects systems utilizing the ATM LANE (LAN Emulation) networking subsystem.
Critical Impact
Local attackers can trigger a kernel crash through null pointer dereference in the ATM LANE module, causing system denial of service.
Affected Products
- Linux kernel (versions with ATM LANE module enabled)
- Systems using ATM LAN Emulation networking
- Enterprise network infrastructure utilizing ATM switching
Discovery Timeline
- March 25, 2026 - CVE-2026-23286 published to NVD
- March 25, 2026 - Last updated in NVD database
Technical Details for CVE-2026-23286
Vulnerability Analysis
The vulnerability resides in the ATM LANE (LAN Emulation) module's ARP cache management code. In the ATM LANE implementation, the same atm_vcc structure can be shared by multiple lec_arp_table entries through either entry->vcc or entry->recv_vcc pointers. This sharing mechanism creates a race condition scenario during VCC cleanup operations.
When the underlying VCC is closed, lec_vcc_close() iterates over all ARP entries in various hash lists (including priv->lec_arp_empty_ones) and calls lec_arp_clear_vccs() for each matched entry. The problem manifests during this iteration process when multiple entries share the same VCC.
During the first iteration for a matched ARP entry, lec_arp_clear_vccs() frees the associated vpriv structure (accessed via vcc->user_back) and sets vcc->user_back to NULL. In subsequent iterations for other ARP entries sharing the same VCC, the function attempts to access the now-NULL vpriv pointer through LEC_VCC_PRIV(vcc) and dereferences it when accessing vpriv->old_pop, resulting in a null pointer dereference kernel crash.
Root Cause
The root cause is the absence of a null check for vpriv before dereferencing it in lec_arp_clear_vccs(). The function assumes vcc->user_back is always valid when called, but this assumption breaks when multiple ARP entries share the same VCC. The initial code path handling entry->vcc has been vulnerable since the module's original implementation, and the entry->recv_vcc path introduced in commit 8d9f73c0ad2f ("atm: fix a memory leak of vcc->user_back") inherited the same vulnerable pattern.
Attack Vector
An attacker with local access can trigger this vulnerability by manipulating ATM LANE connections in a manner that causes multiple ARP entries to share a VCC, then closing that connection. This causes the kernel to crash due to the null pointer dereference when iterating through the shared VCC entries.
The exploitation does not require elevated privileges but does require the ability to interact with the ATM LANE subsystem. The resulting denial of service affects system availability as the kernel will crash when the vulnerable code path is triggered.
Detection Methods for CVE-2026-23286
Indicators of Compromise
- Kernel panic or oops messages referencing lec_arp_clear_vccs function
- Crash dumps showing null pointer dereference in the ATM LANE module (net/atm/lec.c)
- System instability when closing ATM LANE connections
- Unexpected kernel crashes on systems with ATM networking enabled
Detection Strategies
- Monitor kernel logs for null pointer dereference errors in ATM subsystem functions
- Implement kernel crash dump analysis to identify patterns consistent with this vulnerability
- Use kernel address sanitizer (KASAN) to detect memory access violations in the ATM LANE module
- Deploy endpoint detection solutions capable of monitoring kernel-level anomalies
Monitoring Recommendations
- Enable kernel crash reporting and automatic crash dump collection on affected systems
- Configure log aggregation to alert on ATM LANE-related kernel messages
- Monitor system uptime metrics for unexpected reboots that may indicate exploitation attempts
- Implement SentinelOne Singularity Platform for real-time kernel threat detection and response
How to Mitigate CVE-2026-23286
Immediate Actions Required
- Apply the latest Linux kernel patches containing the fix for this vulnerability
- If ATM LANE functionality is not required, consider disabling or blacklisting the lec kernel module
- Restrict local access to systems where ATM LANE is in use
- Monitor affected systems for signs of exploitation attempts
Patch Information
The vulnerability has been addressed across multiple stable kernel branches. The fix adds a null check for vpriv before dereferencing it in lec_arp_clear_vccs(). If vpriv is NULL, indicating the VCC has already been cleared by a previous call, the cleanup is safely skipped and only the entry's vcc/recv_vcc pointers are cleared.
Apply one of the following commits based on your kernel version:
- Linux Kernel Commit 101bacb303e
- Linux Kernel Commit 2d9f57ea29a
- Linux Kernel Commit 5f1cfea7921
- Linux Kernel Commit 622062f2464
- Linux Kernel Commit 7ea92ab075d
- Linux Kernel Commit e9665986eb1
Workarounds
- Disable the ATM LANE module if not required: modprobe -r lec or blacklist in /etc/modprobe.d/
- Restrict physical and logical access to ATM networking infrastructure
- Implement network segmentation to limit exposure of systems using ATM LANE
- Deploy SentinelOne Singularity XDR for comprehensive kernel vulnerability monitoring and threat detection
# Disable ATM LANE module as a temporary workaround
echo "blacklist lec" >> /etc/modprobe.d/blacklist-atm-lec.conf
modprobe -r lec
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

