CVE-2026-64409

Low

No strong exploitation signal.

CVSS base

5.5 MEDIUM

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

EPSS — probability of exploitation (30 days)

0.1%

2.4th percentile

CISA KEV

Not listed

Weakness / dates

CWE-835

Published 2026-07-25 · modified 2026-09-04

CVSS breakdown

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Attack Vector	L	Local
Attack Complexity	L	Low
Privileges Required	L	Low
User Interaction	N	None
Scope	U	Unchanged
Confidentiality	N	None
Integrity	N	None
Availability	H	High

Timeline

2026-07-25 — Published (NVD)
2026-09-04 — Last modified (NVD)

Description

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

Affected

linux

References

Official: NVD · CVE.org