FKIE_CVE-2026-23286
Vulnerability from fkie_nvd - Published: 2026-03-25 11:16 - Updated: 2026-03-25 15:41
Severity ?
Summary
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.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\natm: lec: fix null-ptr-deref in lec_arp_clear_vccs\n\nsyzkaller reported a null-ptr-deref in lec_arp_clear_vccs().\nThis issue can be easily reproduced using the syzkaller reproducer.\n\nIn the ATM LANE (LAN Emulation) module, the same atm_vcc can be shared by\nmultiple lec_arp_table entries (e.g., via entry-\u003evcc or entry-\u003erecv_vcc).\nWhen the underlying VCC is closed, lec_vcc_close() iterates over all\nARP entries and calls lec_arp_clear_vccs() for each matched entry.\n\nFor example, when lec_vcc_close() iterates through the hlists in\npriv-\u003elec_arp_empty_ones or other ARP tables:\n\n1. In the first iteration, for the first matched ARP entry sharing the VCC,\nlec_arp_clear_vccs() frees the associated vpriv (which is vcc-\u003euser_back)\nand sets vcc-\u003euser_back to NULL.\n2. In the second iteration, for the next matched ARP entry sharing the same\nVCC, lec_arp_clear_vccs() is called again. It obtains a NULL vpriv from\nvcc-\u003euser_back (via LEC_VCC_PRIV(vcc)) and then attempts to dereference it\nvia `vcc-\u003epop = vpriv-\u003eold_pop`, leading to a null-ptr-deref crash.\n\nFix this by adding a null check for vpriv before dereferencing\nit. If vpriv is already NULL, it means the VCC has been cleared\nby a previous call, so we can safely skip the cleanup and just\nclear the entry\u0027s vcc/recv_vcc pointers.\n\nThe entire cleanup block (including vcc_release_async()) is placed inside\nthe vpriv guard because a NULL vpriv indicates the VCC has already been\nfully released by a prior iteration \u2014 repeating the teardown would\nredundantly set flags and trigger callbacks on an already-closing socket.\n\nThe Fixes tag points to the initial commit because the entry-\u003evcc path has\nbeen vulnerable since the original code. The entry-\u003erecv_vcc path was later\nadded by commit 8d9f73c0ad2f (\"atm: fix a memory leak of vcc-\u003euser_back\")\nwith the same pattern, and both paths are fixed here."
}
],
"id": "CVE-2026-23286",
"lastModified": "2026-03-25T15:41:33.977",
"metrics": {},
"published": "2026-03-25T11:16:23.393",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/101bacb303e89dc2e0640ae6a5e0fb97c4eb45bb"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2d9f57ea29a1f1772373b98a509b44d49fda609e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/5f1cfea7921f5c126a441d973690eeba52677b64"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/622062f24644b4536d3f437e0cf7a8c4bb421665"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/7ea92ab075d809ec8a96669a5ecf00f752057875"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e9665986eb127290ceb535bd5d04d7a84265d94f"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…