CVE-2026-23286

In the Linux kernel, the following vulnerability has been resolved:

atm: lec: fix null-ptr-deref in lecarpclear_vccs

syzkaller reported a null-ptr-deref in lecarpclear_vccs(). This issue can be easily reproduced using the syzkaller reproducer.

In the ATM LANE (LAN Emulation) module, the same atmvcc can be shared by multiple lecarptable entries (e.g., via entry->vcc or entry->recvvcc). When the underlying VCC is closed, lecvccclose() iterates over all ARP entries and calls lecarpclear_vccs() for each matched entry.

For example, when lecvccclose() iterates through the hlists in priv->lecarpempty_ones or other ARP tables:

1. In the first iteration, for the first matched ARP entry sharing the VCC, lecarpclearvccs() frees the associated vpriv (which is vcc->userback) and sets vcc->user_back to NULL.
2. In the second iteration, for the next matched ARP entry sharing the same VCC, lecarpclearvccs() is called again. It obtains a NULL vpriv from vcc->userback (via LECVCCPRIV(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 vccreleaseasync()) 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->recvvcc path was later added by commit 8d9f73c0ad2f ("atm: fix a memory leak of vcc->userback") with the same pattern, and both paths are fixed here.