Cloudanix VulnDB

CVE-2026-98294

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux Bluetooth handling for certain wireless chips can crash the whole computer when the driver is removed after a hardware problem.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in the hci_qca Bluetooth UART driver caused by writing to a serdev port after hci_uart_close() has cleared HCI_UART_PROTO_READY and closed the tty, resulting in NULL pointer dereference during qca_power_shutdown when the driver is unbound after a prior controller failure.

Why it matters to the business

Kernel crashes or instability on systems using affected Qualcomm Bluetooth controllers such as WCN399x family chips, potentially causing denial of service, loss of wireless connectivity, and requiring system reboots in environments that rely on Bluetooth hardware.

How an attack unfolds

An attacker with local access triggers a controller failure followed by deliberate driver unbind or removal; the resulting call path in qca_serdev_remove executes qca_power_shutdown on a closed port, dereferencing a dangling tty structure and producing a use-after-free condition.

How to fix it

Apply the upstream fix that adds an HCI_UART_PROTO_READY check before any write in qca_power_shutdown/qca_power_off and update to a kernel containing the patch; leave regulator disable unconditional.

How to confirm the fix worked

Confirm the presence of the HCI_UART_PROTO_READY guard in hci_uart_close and qca_power_shutdown paths; attempt driver unbind after simulated controller failure and verify absence of NULL dereference or use-after-free reports in the kernel log.

Typical attack path

  1. Cause or wait for hci_dev_open_sync failure after successful qca_setup on a WCN3988/WCN399x controller
  2. Trigger driver unbind via sysfs or module removal while vregs_on remains true
  3. qca_serdev_remove passes the power state check and unconditionally calls qca_power_shutdown
  4. serdev write occurs on the already-closed port, dereferencing the freed tty structure

How to detect it

Search kernel logs for NULL pointer dereference traces containing tty_set_termios, ttyport_set_baudrate, serdev_device_set_baudrate, qca_power_shutdown and qca_serdev_remove; correlate with unbind_store or device_driver_detach events on hci_uart devices.

What your security team should do

  • Prioritize kernel updates on all systems exposing the hci_qca driver
  • Monitor for local unbind or module removal attempts on Bluetooth devices
  • Restrict unprivileged access to driver bind/unbind interfaces where feasible

The record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Do not write to the serial port after it is closed hci_uart_close() closes the serdev port if HCI_QUIRK_NON_PERSISTENT_SETUP is set (for example, for the WCN399x family). A failed hci_dev_open_sync() following a successful qca_setup() calls hdev->close() but not hdev->shutdown(), so the port is closed while power->vregs_on is left true. qca_serdev_remove() then passes its power->vregs_on test and calls qca_power_off(), which writes to the closed port unconditionally. Seen on a WCN3988 by unbinding the driver after a controller failure. The trace below is from a 7.0.0 based kernel, where qca_power_off() was still named qca_power_shutdown(): Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 Call trace: tty_set_termios+0x50/0x238 (P) ttyport_set_baudrate+0x84/0xc0 serdev_device_set_baudrate+0x24/0x40 qca_power_shutdown+0x158/0x1fc [hci_uart] qca_serdev_remove+0x54/0x68 [hci_uart] serdev_drv_remove+0x1c/0x2c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xc0 Check HCI_UART_PROTO_READY, which hci_uart_close() clears in the same place it closes the port, before writing to it. The regulator disable is left unconditional so the controller is still powered down. The dangling serport->tty that turns this into a use-after-free is addressed in a separate patch.

Affected packages

Ecosystem Package Introduced Fixed