CVE-2026-23286
Analyzed
Analyzed - Analysis Complete
Null Pointer Dereference in Linux ATM LANE Module Causes Crash
Publication date: 2026-03-25
Last updated on: 2026-05-29
Assigner: kernel.org
Description
Description
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.
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | 2.6.12 |
| linux | linux_kernel | 2.6.12 |
| linux | linux_kernel | 2.6.12 |
| linux | linux_kernel | 2.6.12 |
| linux | linux_kernel | 2.6.12 |
| linux | linux_kernel | From 6.19 (inc) to 6.19.7 (exc) |
| linux | linux_kernel | 7.0 |
| linux | linux_kernel | 7.0 |
| linux | linux_kernel | From 6.13 (inc) to 6.18.17 (exc) |
| linux | linux_kernel | From 6.2 (inc) to 6.6.130 (exc) |
| linux | linux_kernel | From 6.7 (inc) to 6.12.77 (exc) |
| linux | linux_kernel | From 5.11 (inc) to 5.15.203 (exc) |
| linux | linux_kernel | From 5.16 (inc) to 6.1.167 (exc) |
| linux | linux_kernel | From 2.6.12.1 (inc) to 5.10.253 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-476 | The product dereferences a pointer that it expects to be valid but is NULL. |