CVE-2026-43050

What it actually does

CVE-2026-43050 is a Linux kernel use-after-free race in the ATM LAN Emulation Client (LEC) networking code. The vulnerable code clears the LEC daemon socket pointer during lec_atm_close() without synchronizing concurrent readers in send_to_lecd(), lec_handle_bridge(), and lec_atm_send(). A concurrent execution path can continue using a socket after it has been freed through RCU teardown, leading to invalid access in sock_def_readable() when the kernel touches the socket wait queue. Because this occurs in kernel context, successful exploitation can potentially cause kernel memory corruption, local privilege escalation, information disclosure, or system crash. The issue is local, requires low privileges, no user interaction, and has high attack complexity because exploitation depends on winning a race in a less commonly deployed ATM/LEC kernel subsystem.

Why it matters to the business

Systems running affected Linux kernels may be exposed to local kernel compromise or denial of service if the ATM LEC functionality is available. In practical terms, the most likely operational impact is instability or crashes on systems where this networking feature is enabled or reachable by local users; in a successful advanced exploit, an attacker with local access could gain elevated privileges and take full control of the host. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no known mature public exploit, and has a very low and flat EPSS score of 0.00119, so broad exploitation is not currently indicated. However, kernel vulnerabilities with privilege-escalation potential should still be prioritized on multi-user Linux systems, shared compute platforms, appliances, and environments where untrusted users or workloads can execute code.

How an attack unfolds

An attacker first needs local code execution on a Linux system running an affected kernel with the ATM LEC code present and usable. The attacker then interacts with ATM/LEC networking paths to create, attach, use, and close a LEC daemon socket while also causing concurrent packet-handling or transmit paths to reference the same private lecd socket pointer. The vulnerable race occurs when lec_atm_close() sets priv->lecd to NULL and proceeds with socket teardown while another thread has already obtained or is about to use the stale pointer in send_to_lecd(), lec_handle_bridge(), or lec_atm_send(). If timed correctly, the stale socket is accessed after free, and the kernel reaches sock_def_readable() with corrupted or freed socket state. A simple exploitation attempt may crash the kernel and create an oops or panic. A more capable attacker may attempt heap shaping and race stabilization to convert the use-after-free into controlled kernel memory corruption, potentially gaining elevated privileges. No public exploit maturity or active threat actor exploitation is currently indicated by the provided intelligence.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the ATM LEC RCU synchronization issue. The corrected implementation makes priv->lecd an RCU-protected pointer, uses rcu_assign_pointer(), rcu_access_pointer(), rcu_dereference(), rcu_read_lock(), rcu_read_unlock(), and synchronize_rcu() to ensure readers complete before teardown continues. Because no exact fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution vendor or the upstream stable kernel branch containing the patch for this CVE. Where immediate patching is not possible, reduce exposure by disabling or removing unneeded ATM/LEC functionality, preventing untrusted local users or workloads from loading networking modules, restricting module loading through kernel lockdown or module signing, limiting CAP_NET_ADMIN and other network administration capabilities, and prioritizing host isolation for systems that allow local shell, container, or shared workload access.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor release that includes the fix for CVE-2026-43050 or verify the source contains the RCU-protected priv->lecd changes in the ATM LEC code. On source-based or custom kernels, inspect net/atm/lec.c and related headers for use of rcu_assign_pointer(), rcu_access_pointer(), rcu_dereference(), rcu_read_lock(), rcu_read_unlock(), and synchronize_rcu() around priv->lecd access and teardown. Validate exposure by checking whether ATM/LEC support is built into the kernel or available as a loadable module, and whether the lec module or ATM interfaces are in use. After remediation, reboot into the patched kernel, confirm the active kernel version with uname or vendor inventory tooling, and ensure older vulnerable kernels are not still selected by the bootloader. Also review kernel logs after update for absence of recurring oops traces involving lec_atm_close(), send_to_lecd(), lec_handle_bridge(), lec_atm_send(), or sock_def_readable().

Typical attack path

1. Obtain local low-privileged execution on a Linux host running an affected kernel.
2. Determine whether ATM/LEC kernel functionality is present, loadable, configured, or accessible.
3. Create or interact with ATM LEC socket/device state to establish a lecd pointer.
4. Trigger concurrent close and send/receive/bridge-handling paths so lec_atm_close() races with send_to_lecd(), lec_handle_bridge(), or lec_atm_send().
5. Win the race so a freed socket is reused by sock_def_readable() or related socket wake-up logic.
6. Cause a kernel crash for denial of service, or attempt heap grooming and control-flow manipulation for local privilege escalation.

How to detect it

Look for evidence of attempted or successful exploitation in kernel telemetry rather than application logs. Useful sources include dmesg, journald kernel entries, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, audit logs for suspicious local execution, module-loading logs, and endpoint telemetry showing unusual local programs interacting with ATM networking. The strongest signs are kernel oops, panic, general protection fault, KASAN, UBSAN, or page fault reports with stack traces containing sock_def_readable(), lec_atm_close(), send_to_lecd(), lec_handle_bridge(), lec_atm_send(), lec_push(), lec_start_xmit(), or net/atm/lec.c. Also review recent local user sessions, container activity, privilege-boundary events, and module loads around the time of any crash. Because no public exploit, malware family, network signature, or threat actor activity is indicated, absence of these crash artifacts does not prove safety, and presence of these function names may also reflect fuzzing or non-malicious kernel bugs; correlate with local execution and repeated race-triggering behavior.

• sock_def_readable
• lec_atm_close
• send_to_lecd
• lec_handle_bridge
• lec_atm_send
• lec_push
• lec_start_xmit
• net/atm/lec.c
• BUG: KASAN: use-after-free
• use-after-free in sock_def_readable
• general protection fault
• kernel BUG
• Oops:
• Call Trace:
• module lec
• atm: lec

What your security team should do

• Prioritize patching shared Linux systems, virtualization hosts, container hosts, CI runners, research systems, and any host where untrusted local users or workloads can execute code.
• Inventory kernels and identify systems with ATM or LEC support enabled, loaded, or required for operations.
• Apply vendor-provided fixed kernel packages and reboot into the patched kernel; verify the running kernel rather than only confirming package installation.
• If patching is delayed, disable or blacklist unneeded ATM/LEC modules and restrict kernel module loading and CAP_NET_ADMIN-like privileges.
• Monitor kernel logs for crashes or oops traces involving ATM LEC functions and sock_def_readable(), especially on systems with local users or network-administration workloads.
• Treat unexplained kernel crashes in the ATM/LEC path as potentially security relevant and preserve crash dumps, kernel logs, and recent local user activity for investigation.
• Because EPSS is very low, KEV is false, and exploit maturity is listed as none, deprioritize internet-wide emergency response in favor of targeted kernel patch management and local privilege-escalation risk reduction.