CVE-2026-23286 in Linux
Summary
by MITRE • 03/25/2026
In the Linux kernel, the following vulnerability has been resolved:
atm: lec: fix null-ptr-deref in lec_arp_clear_vccs
syzkaller reported a null-ptr-deref in lec_arp_clear_vccs(). This issue can be easily reproduced using the syzkaller reproducer.
In the ATM LANE (LAN Emulation) module, the same atm_vcc can be shared by multiple lec_arp_table entries (e.g., via entry->vcc or entry->recv_vcc). When the underlying VCC is closed, lec_vcc_close() iterates over all ARP entries and calls lec_arp_clear_vccs() for each matched entry.
For example, when lec_vcc_close() iterates through the hlists in priv->lec_arp_empty_ones or other ARP tables:
1. In the first iteration, for the first matched ARP entry sharing the VCC, lec_arp_clear_vccs() frees the associated vpriv (which is vcc->user_back) and sets vcc->user_back to NULL. 2. In the second iteration, for the next matched ARP entry sharing the same VCC, lec_arp_clear_vccs() is called again. It obtains a NULL vpriv from vcc->user_back (via LEC_VCC_PRIV(vcc)) and then attempts to dereference it via `vcc->pop = vpriv->old_pop`, leading to a null-ptr-deref crash.
Fix this by adding a null check for vpriv before dereferencing it. If vpriv is already NULL, it means the VCC has been cleared by a previous call, so we can safely skip the cleanup and just clear the entry's vcc/recv_vcc pointers.
The entire cleanup block (including vcc_release_async()) is placed inside the vpriv guard because a NULL vpriv indicates the VCC has already been fully released by a prior iteration — repeating the teardown would redundantly set flags and trigger callbacks on an already-closing socket.
The Fixes tag points to the initial commit because the entry->vcc path has been vulnerable since the original code. The entry->recv_vcc path was later added by commit 8d9f73c0ad2f ("atm: fix a memory leak of vcc->user_back") with the same pattern, and both paths are fixed here.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 06/01/2026
The vulnerability described in CVE-2026-23286 resides within the Linux kernel's ATM LANE (LAN Emulation) module, specifically affecting the lec_arp_clear_vccs function. This issue manifests as a null pointer dereference that occurs during the cleanup process of ATM Virtual Channel Connections (VCCs) when multiple ARP table entries share the same VCC reference. The vulnerability was identified through systematic testing using the syzkaller fuzzer, which demonstrated that the flaw can be reliably reproduced with a specific test case. The root cause involves the improper handling of shared VCC references where the same atm_vcc structure can be associated with multiple lec_arp_table entries through either the entry->vcc or entry->recv_vcc fields. When lec_vcc_close() processes multiple entries that reference the same VCC, it iterates through the ARP tables and calls lec_arp_clear_vccs() for each matching entry, creating a scenario where the same VCC gets processed multiple times during cleanup operations.
The technical flaw stems from the sequence of operations within the lec_arp_clear_vccs function where the first iteration successfully frees the vpriv structure and sets vcc->user_back to NULL, but subsequent iterations attempt to access the already-null vpriv pointer through the LEC_VCC_PRIV(vcc) macro. This leads to a null pointer dereference when the code tries to access vpriv->old_pop, causing a kernel crash. The vulnerability represents a classic race condition and improper resource management issue where the cleanup logic does not account for the possibility that the VCC may have already been partially or fully released during a previous iteration. The issue affects the ATM Layer 2 protocol implementation in Linux kernels, which is used for connecting local area networks to ATM networks and is particularly relevant in enterprise networking environments that utilize ATM infrastructure. The flaw was present in the original implementation and was later exacerbated by a memory leak fix commit that introduced similar patterns in the entry->recv_vcc path, making both code paths vulnerable to the same null pointer dereference scenario.
The operational impact of this vulnerability is significant as it can lead to kernel crashes and system instability when processing ATM network traffic involving LANE services. An attacker who can trigger the specific conditions that lead to this vulnerability could potentially cause a denial of service attack against systems running affected Linux kernels, particularly those that handle ATM network connections. The vulnerability affects systems where the ATM subsystem is enabled and actively used for network communications, making it relevant to enterprise network infrastructure, telecommunications equipment, and legacy network environments that still rely on ATM technology. The fix implemented addresses this by adding a null check before dereferencing the vpriv pointer, ensuring that if the VCC has already been cleared by a previous iteration, the cleanup process skips redundant operations rather than attempting to access freed memory. This approach prevents the double cleanup scenario and maintains the integrity of the VCC management system while preserving the proper release of resources. The mitigation strategy involves checking for NULL vpriv pointers before attempting to access their members, which aligns with standard secure coding practices and prevents the type of memory safety issues that could lead to system crashes or potential privilege escalation scenarios.
The vulnerability maps directly to CWE-476, which describes null pointer dereference conditions, and represents a specific instance of improper resource management in kernel space. From an ATT&CK perspective, this vulnerability could be leveraged as part of a broader attack chain involving privilege escalation or denial of service, particularly in environments where ATM networks are actively used. The fix demonstrates proper defensive programming by implementing early termination conditions and resource state checks, which are fundamental principles for preventing memory safety issues in kernel code. The solution maintains the existing functionality while ensuring that the cleanup process is robust against multiple iterations over shared VCC references, thereby preventing the system from crashing when handling concurrent or sequential ARP table cleanup operations. This fix is particularly important in maintaining the stability of network services that depend on ATM connectivity and demonstrates the importance of thorough testing and code review in kernel space programming where memory safety issues can have severe system-wide consequences.