Intel

CVE-2026-46275

Linux kernel (GCP) vulnerabilities

highEPSS 0.2%

Description

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

Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths

Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart.

The primary issue arises because the workqueues (init_ready and write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY flag is set during TTY close. If a hangup occurs before setup completes, hci_uart_tty_close() skips the teardown of these workqueues and proceeds to free the hu struct. When the scheduled work executes later, it blindly dereferences the freed hu struct.

Furthermore, several data races and UAFs were identified in the teardown sequence:

  1. Calling hci_uart_flush() from hci_uart_close() without effectively disabling write_work causes a race condition where both can concurrently double-free hu->tx_skb. This happens because protocol timers can concurrently invoke hci_uart_tx_wakeup() and requeue write_work.
  2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev.
  3. In the initialization error paths, failing to take the proto_lock write lock before clearing PROTO_READY leads to races with active readers. Additionally, hci_uart_tty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently.

Fix these synchronization and lifecycle issues by:

  1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, followed immediately by a cancel_work_sync(&hu->write_work). Clearing the flag locks out concurrent protocol timers from successfully invoking hci_uart_tx_wakeup(), effectively rendering the cancellation permanent and preventing the tx_skb double-free.
  2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip hu->proto->flush(). This is perfectly safe in the tty_close path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state.
  3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev) across all close and error paths to prevent vendor-level UAFs.
  4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive() inside the proto_lock read-side critical section to safely synchronize with device unregistration.
  5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely flush the workqueue before hci_uart_flush() is invoked via the HCI core.
  6. Utilizing cancel_work_sync() instead of disable_work_sync() across all paths to prevent permanently breaking user-space retry capabilities.
Source: UBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNDEBIAN_DSABSIBSI_CSAFNVDCVEORGMSRCCVELISTV5

Metrics

Severity
high
Priority score
231.31
KEV status
—
Exploit maturity
no public PoC known
XIEM Effective CVSS
7.8
Source: cna-v3
CVSS v3
7.8
CVSS v4
—
EPSS percentile
8.3 %
Low — this CVE sits in the lower 10% of all CVEs scored today.
EPSS score
0.2 %
Low — model estimates < 1% exploitation likelihood.
Published
2026-09-07 09:05 UTC
CWE
—

Reanalysis & status changes

Chronological NVD audit events for this CVE — reanalyses, CVSS updates, CPE diffs.

  1. CVE Translated2026-07-23 07:10 UTC· nvd@nist.gov
    • Translation: Title: Linux, Description: En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: Bluetooth: hci_uart: corrige UAFs y condiciones de carrera en las rutas de cierre e inicialización Se observaron vulnerabilidades que conducen a condiciones de Uso Después de Liberación (UAF) y Desreferencia de Puntero Nulo (NPD) en la gestión del ciclo de vida de hci_uart. El problema principal surge porque las colas de trabajo (workqueues) (init_ready y write_work) solo se vacían/cancelan si la bandera HCI_UART_PROTO_READY está establecida durante el cierre de TTY. Si ocurre un cuelgue antes de que se complete la configuración, hci_uart_tty_close() omite la desinstalación de estas colas de trabajo y procede a liberar la estructura 'hu'. Cuando el trabajo programado se ejecuta más tarde, desreferencia ciegamente la estructura 'hu' liberada. Además, se identificaron varias condiciones de carrera de datos y UAFs en la secuencia de desinstalación: 1. Llamar a hci_uart_flush() desde hci_uart_close() sin deshabilitar efectivamente write_work causa una condición de carrera donde ambos pueden liberar doblemente hu->tx_skb de forma concurrente. Esto sucede porque los temporizadores del protocolo pueden invocar concurrentemente hci_uart_tx_wakeup() y volver a encolar write_work. 2. Llamar a hci_free_dev(hdev) antes de hu->proto->close(hu) causa un UAF cuando las devoluciones de llamada de cierre del protocolo específico del proveedor desreferencian hu->hdev. 3. En las rutas de error de inicialización, no tomar el bloqueo de escritura proto_lock antes de borrar PROTO_READY conduce a condiciones de carrera con lectores activos. Además, hci_uart_tty_receive() accede a hu->hdev fuera del bloqueo de lectura, lo que lleva a UAFs si la ruta de error de inicialización libera hdev concurrentemente. Corregir estos problemas de sincronización y ciclo de vida mediante: 1. Reordenar hci_uart_tty_close() para borrar HCI_UART_PROTO_READY primero, seguido inmediatamente por un cancel_work_sync(&hu->write_work). Borrar la bandera bloquea a los temporizadores del protocolo concurrentes para que no invoquen con éxito hci_uart_tx_wakeup(), haciendo que la cancelación sea permanente y evitando la doble liberación de tx_skb. 2. Nota: Borrar PROTO_READY temprano hace que hci_uart_close() omita hu->proto->flush(). Esto es perfectamente seguro en la ruta tty_close porque hu->proto->close() se ejecuta poco después, lo que intrínsecamente purga todas las colas SKB del protocolo y desinstala el estado. 3. Reubicar hu->proto->close(hu) estrictamente antes de hci_free_dev(hdev) en todas las rutas de cierre y error para prevenir UAFs a nivel de proveedor. 4. Mover el incremento de hdev->stat.byte_rx en hci_uart_tty_receive() dentro de la sección crítica del lado de lectura de proto_lock para sincronizar de forma segura con la anulación del registro del dispositivo. 5. Añadir cancel_work_sync(&hu->write_work) a hci_uart_close() para vaciar de forma segura la cola de trabajo antes de que hci_uart_flush() sea invocado a través del núcleo HCI. 6. Utilizar cancel_work_sync() en lugar de disable_work_sync() en todas las rutas para evitar romper permanentemente las capacidades de reintento del espacio de usuario.
  2. New CVE Received2026-06-08 16:16 UTC· 416baaa9-dc9f-4396-8d5f-8c081fb06d67
    • Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart. The primary issue arises because the workqueues (init_ready and write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY flag is set during TTY close. If a hangup occurs before setup completes, hci_uart_tty_close() skips the teardown of these workqueues and proceeds to free the `hu` struct. When the scheduled work executes later, it blindly dereferences the freed `hu` struct. Furthermore, several data races and UAFs were identified in the teardown sequence: 1. Calling hci_uart_flush() from hci_uart_close() without effectively disabling write_work causes a race condition where both can concurrently double-free hu->tx_skb. This happens because protocol timers can concurrently invoke hci_uart_tx_wakeup() and requeue write_work. 2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev. 3. In the initialization error paths, failing to take the proto_lock write lock before clearing PROTO_READY leads to races with active readers. Additionally, hci_uart_tty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently. Fix these synchronization and lifecycle issues by: 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, followed immediately by a cancel_work_sync(&hu->write_work). Clearing the flag locks out concurrent protocol timers from successfully invoking hci_uart_tx_wakeup(), effectively rendering the cancellation permanent and preventing the tx_skb double-free. 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip hu->proto->flush(). This is perfectly safe in the tty_close path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state. 3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive() inside the proto_lock read-side critical section to safely synchronize with device unregistration. 5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely flush the workqueue before hci_uart_flush() is invoked via the HCI core. 6. Utilizing cancel_work_sync() instead of disable_work_sync() across all paths to prevent permanently breaking user-space retry capabilities.
    • Reference: https://git.kernel.org/stable/c/192cb0f1ca706d9a1bc36ae0ad5f666d1e4fd894
    • Reference: https://git.kernel.org/stable/c/7338031946bd06f6dff149e67b60c4cd083bfea8
    • Reference: https://git.kernel.org/stable/c/78aad93e938f013d9272fe0ee168f27883afa95c

Affected operating systems

  • linux

    redhat / enterprise_linux10.0

  • linux

    redhat / enterprise_linux7.0

  • linux

    redhat / enterprise_linux8.0

  • linux

    redhat / enterprise_linux9.0

  • linux

    ubuntu / linux-aws-6.8jammy

  • linux

    ubuntu / linux-azureresolute

  • linux

    ubuntu / linux-azuretrusty

  • linux

    ubuntu / linux-azurexenial

  • linux

    ubuntu / linux-azure-4.15bionic

  • linux

    ubuntu / linux-azure-5.4bionic

  • linux

    ubuntu / linux-azure-fdenoble

  • linux

    ubuntu / linux-azure-fderesolute

  • linux

    ubuntu / linux-azure-fde-6.8jammy

  • linux

    ubuntu / linux-azure-fipsbionic

  • linux

    ubuntu / linux-azure-fipsfocal

  • linux

    ubuntu / linux-azure-fipsnoble

  • linux

    ubuntu / linux-fipsjammy

  • linux

    ubuntu / linux-gcp-7.0noble

  • linux

    ubuntu / linux-gkejammy

  • linux

    ubuntu / linux-nvidia-tegranoble

  • linux

    ubuntu / linux-raspinoble

  • linux

    ubuntu / linux-raspi-realtimenoble

  • linux

    linux / linux_kernel2.6.12

  • linux

    linux / linux_kernel2.6.15

References & sources

Linked CVEs

Show 1392 more CVEs

Linked advisories

IDCVE-2026-46275
Linux kernel (GCP) vulnerabilities — CVE-2026-46275 | NEOSEC Intel