CVE-2026-64409

Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
25/07/2026
Last modified:
25/07/2026

Description

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()<br /> <br /> Every once in a while we see a hung btmtksdio_flush() task:<br /> <br /> INFO: task kworker/u17:0:189 blocked for more than 122 seconds.<br /> __cancel_work_timer+0x3f4/0x460<br /> cancel_work_sync+0x1c/0x2c<br /> btmtksdio_flush+0x2c/0x40<br /> hci_dev_open_sync+0x10c4/0x2190<br /> [..]<br /> <br /> It all boils down to incorrect time_is_before_jiffies() usage in<br /> btmtksdio_txrx_work(). The btmtksdio_txrx_work() loop is expected<br /> to be terminated if running for longer than 5*HZ. However the<br /> timeout check is twisted: time_is_before_jiffies(old_jiffies + 5*HZ)<br /> evaluates to true when old_jiffies + 5*HZ is in the past i.e. when a<br /> timeout has occurred. Using OR with time_is_before_jiffies(txrx_timeout)<br /> means that:<br /> - before the 5-second timeout: the condition is `int_status || false`,<br /> so it loops as long as there are pending interrupts.<br /> - after the 5-second timeout: the condition becomes `int_status || true`,<br /> which is always true.<br /> <br /> When the loop becomes infinite btmtksdio_txrx_work() loop never<br /> terminates and never releases the SDIO host.<br /> <br /> Fix loop termination condition to actually enforce a 5*HZ timeout.

Impact