Skip to content
Fencer Vulns
high 7.0

CVE-2026-43050 json

atm: lec: fix use-after-free in sock_def_readable()

published 2026-05-01 6 mo ago modified 2026-11-06 2 d ago also EUVD-2026-26649

cvss
7.0
version 3.1, NVD
cisa kev
Not listed
not in CISA's catalog
epss
0.1%
EPSS 0.1% chance of exploitation in 30 days, percentile 1%
public exploits
0
none known

Summary

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

atm: lec: fix use-after-free in sock_def_readable()

A race condition exists between lec_atm_close() setting priv->lecd to NULL and concurrent access to priv->lecd in send_to_lecd(), lec_handle_bridge(), and lec_atm_send(). When the socket is freed via RCU while another thread is still using it, a use-after-free occurs in sock_def_readable() when accessing the socket's wait queue.

The root cause is that lec_atm_close() clears priv->lecd without any synchronization, while callers dereference priv->lecd without any protection against concurrent teardown.

Fix this by converting priv->lecd to an RCU-protected pointer: - Mark priv->lecd as __rcu in lec.h - Use rcu_assign_pointer() in lec_atm_close() and lecd_attach() for safe pointer assignment - Use rcu_access_pointer() for NULL checks that do not dereference the pointer in lec_start_xmit(), lec_push(), send_to_lecd() and lecd_attach() - Use rcu_read_lock/rcu_dereference/rcu_read_unlock in send_to_lecd(), lec_handle_bridge() and lec_atm_send() to safely access lecd - Use rcu_assign_pointer() followed by synchronize_rcu() in lec_atm_close() to ensure all readers have completed before proceeding. This is safe since lec_atm_close() is called from vcc_release() which holds lock_sock(), a sleeping lock. - Remove the manual sk_receive_queue drain from lec_atm_close() since vcc_destroy_socket() already drains it after lec_atm_close() returns.

v2: Switch from spinlock + sock_hold/put approach to RCU to properly fix the race. The v1 spinlock approach had two issues pointed out by Eric Dumazet: 1. priv->lecd was still accessed directly after releasing the lock instead of using a local copy. 2. The spinlock did not prevent packets being queued after lec_atm_close() drains sk_receive_queue since timer and workqueue paths bypass netif_stop_queue().

Note: Syzbot patch testing was attempted but the test VM terminated unexpectedly with "Connection to localhost closed by remote host", likely due to a QEMU AHCI emulation issue unrelated to this fix. Compile testing with "make W=1 net/atm/lec.o" passes cleanly.

Patch / fix

  • Linux Linux 5.10.253, 5.15.203, 6.1.168, 6.6.134, 6.12.81, 6.18.22, 6.19.12, 7.0
  • linux Debian 12 6.1.170-1
  • linux Debian 13 6.12.85-1
  • linux Debian 14 6.19.12-1

debian advisories DEBIAN-CVE-2026-43050

  • linux Ubuntu 22.04 LTS 5.15.0-186.196
  • linux Ubuntu 24.04 LTS 6.8.0-136.136
  • linux-aws Ubuntu 22.04 LTS 5.15.0-1112.119
  • linux-aws Ubuntu 24.04 LTS 6.8.0-1061.64
  • linux-gcp Ubuntu 22.04 LTS 5.15.0-1112.122
  • linux-gcp Ubuntu 24.04 LTS 6.8.0-1064.72
  • linux-gke Ubuntu 22.04 LTS 5.15.0-1108.114
  • linux-gke Ubuntu 24.04 LTS 6.8.0-1059.67

ubuntu advisories UBUNTU-CVE-2026-43050

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

  • kernel-default SLES for SAP 15 SP6, SLES 15 SP6-LTSS, SLE Live Patching 15 SP6 +1 more 6.4.0-150600.23.112.1
  • kernel-64kb SLE Module for Basesystem 15 SP7 6.4.0-150700.53.55.1
  • kernel-syms SLE Module for Development Tools 15 SP7 6.4.0-150700.53.55.1
  • kernel-azure SLE Module for Public Cloud 15 SP7 6.4.0-150700.53.55.1
  • kernel-source SLE Module for Development Tools 15 SP7, SLE Module for Basesystem 15 SP7 6.4.0-150700.53.55.1
  • kernel-default SLE Workstation Extension 15 SP7, SLE Module for Legacy 15 SP7, SLE Module for Basesystem 15 SP7 +2 more 6.4.0-150700.53.55.1
  • kernel-zfcpdump SLE Module for Basesystem 15 SP7 6.4.0-150700.53.55.1
  • kernel-obs-build SLE Module for Development Tools 15 SP7 6.4.0-150700.53.55.1

suse advisories SUSE-SU-2026:2195-1SUSE-SU-2026:2238-1SUSE-SU-2026:21834-1

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2026-43050 updated cvss 5.5

kernel: atm: lec: fix use-after-free in sock_def_readable()

  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more
    affected: workaround, no fix planned “To mitigate this issue, prevent the lec module from being loaded. See https://access.redhat.com/solutions/41278 for instructions.”
  • Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more
    affected: workaround, no fix available “To mitigate this issue, prevent the lec module from being loaded. See https://access.redhat.com/solutions/41278 for instructions.”
  • Red Hat Enterprise Linux 10 kernel
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
2 d ago

Exploit prediction

0.12% chance of exploitation in the next 30 days, higher than 1% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
NVD 3.1 7.0 CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Affected products

  • Linux Linux

Classification

Weakness
Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.