CVEvulnerability
CVE-2026-23286
5.5 MEDIUM
Official page ↗
- Status
- Analyzed
- Published
- 2026-03-25
- Last modified
- 2026-06-17
- Assigner
- 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- CVSS 3.1 ([email protected])
- 5.5 MEDIUM — CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
- Weaknesses
- CWE-476
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.
Affected configurations
• linux linux kernel (>= 2.6.12.1 < 5.10.253)
• linux linux kernel (>= 5.11 < 5.15.203)
• linux linux kernel (>= 5.16 < 6.1.167)
• linux linux kernel (>= 6.2 < 6.6.130)
• linux linux kernel (>= 6.7 < 6.12.77)
• linux linux kernel (>= 6.13 < 6.18.17)
• linux linux kernel (>= 6.19 < 6.19.7)
• linux linux kernel 2.6.12
• linux linux kernel 7.0
Related
Weakness · CWE (1)
- CWE-476 NULL Pointer Dereference weakness
References
- https://git.kernel.org/stable/c/101bacb303e89dc2e0640ae6a5e0fb97c4eb45bb Patch
- https://git.kernel.org/stable/c/2d9f57ea29a1f1772373b98a509b44d49fda609e Patch
- https://git.kernel.org/stable/c/30c9744a989feb22cfbb84170eb0e038a7a2c1da Patch
- https://git.kernel.org/stable/c/5f1cfea7921f5c126a441d973690eeba52677b64 Patch
- https://git.kernel.org/stable/c/622062f24644b4536d3f437e0cf7a8c4bb421665 Patch
- https://git.kernel.org/stable/c/7ea92ab075d809ec8a96669a5ecf00f752057875 Patch
- https://git.kernel.org/stable/c/8aff65a82b6389ec674d46e5b3d3ae6f07db5e3e Patch
- https://git.kernel.org/stable/c/e9665986eb127290ceb535bd5d04d7a84265d94f Patch