Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled
21Vexday Risk Score
No sign of exploitation. No public exploitation artifact known so far.
ssvc Trackcvss 8epss 0.4%
exploitation probability
0.4%top 70% of all CVEs
observed exploitation
nono source reports it
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled
HCI_UART_SENDING bit in tx_state means write_work is pending and blocks
queueing it again. Currently this bit is not cleared when canceling the
work in hci_uart_close(), which blocks future writes when device is
reopened later if write_work was pending.
Fix by clearing HCI_UART_SENDING when canceling the work.
Also make clearing of tx_skb safe by using disable_work_sync +
enable_work instead of just cancel_work_sync. hci_uart_flush() purges
the proto tx queue so we can cancel the pending write_work there,
instead of doing it just in hci_uart_close(). Re-enable and possibly
requeue the work after queue flush.
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Affected products
Linux · Linux