CVE-2026-43050

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.
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.12:-:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.12:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.12:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.12:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.12:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*

History

11 Nov 2026, 23:10

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: atm: lec: corregir uso después de liberación en sock_def_readable() Existe una condición de carrera entre lec_atm_close() estableciendo priv -> lecd a NULL y el acceso concurrente a priv -> lecd en send_to_lecd(), lec_handle_bridge() y lec_atm_send(). Cuando el socket es liberado a través de RCU mientras otro hilo todavía lo está usando, ocurre un uso después de liberación en sock_def_readable() al acceder a la cola de espera del socket. La causa raíz es que lec_atm_close() borra priv -> lecd sin ninguna sincronización, mientras que las funciones que lo llaman desreferencian priv -> lecd sin ninguna protección contra la desestructuración concurrente. Corregir esto convirtiendo priv -> lecd en un puntero protegido por RCU: - Marcar priv -> lecd como __rcu en lec.h - Usar rcu_assign_pointer() en lec_atm_close() y lecd_attach() para una asignación segura de puntero - Usar rcu_access_pointer() para comprobaciones de NULL que no desreferencian el puntero en lec_start_xmit(), lec_push(), send_to_lecd() y lecd_attach() - Usar rcu_read_lock/rcu_dereference/rcu_read_unlock en send_to_lecd(), lec_handle_bridge() y lec_atm_send() para acceder a lecd de forma segura - Usar rcu_assign_pointer() seguido de synchronize_rcu() en lec_atm_close() para asegurar que todos los lectores hayan completado antes de continuar. Esto es seguro ya que lec_atm_close() es llamado desde vcc_release() que mantiene lock_sock(), un bloqueo de suspensión. - Eliminar el vaciado manual de sk_receive_queue de lec_atm_close() ya que vcc_destroy_socket() ya lo vacía después de que lec_atm_close() retorna. v2: Cambiar del enfoque de spinlock + sock_hold/put a RCU para corregir adecuadamente la condición de carrera. El enfoque de spinlock de la v1 tenía dos problemas señalados por Eric Dumazet: 1. Se seguía accediendo a priv -> lecd directamente después de liberar el bloqueo en lugar de usar una copia local. 2. El spinlock no evitaba que los paquetes se encolaran después de que lec_atm_close() vaciara sk_receive_queue, ya que las rutas de temporizador y workqueue eluden netif_stop_queue(). Nota: Se intentó la prueba de parche de Syzbot, pero la VM de prueba terminó inesperadamente con ’Connection to localhost closed by remote host’, probablemente debido a un problema de emulación AHCI de QEMU no relacionado con esta corrección. La prueba de compilación con ’make W=1 net/atm/lec.o’ pasa limpiamente.

Information

Published : 2026-05-01 15:16

Updated : 2026-11-11 23:10


NVD link : CVE-2026-43050

Mitre link : CVE-2026-43050

CVE.ORG link : CVE-2026-43050


JSON object : View

Products Affected

linux

  • linux_kernel
CWE
CWE-416

Use After Free