CVE-2022-49200: Bluetooth: btmtksdio: Fix kernel oops in btmtksdio_interrupt

Severity: medium (CVSS 5.5 v3.1)
Exploited in the wild: not listed in CISA KEV
EPSS: 0.3% probability of exploitation in the next 30 days
Public exploit or detection template: none known
Published: 2025-02-26 · updated 2026-06-17
Weakness: CWE-908

Description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtksdio: Fix kernel oops in btmtksdio_interrupt Fix the following kernel oops in btmtksdio_interrrupt [ 14.339134] btmtksdio_interrupt+0x28/0x54 [ 14.339139] process_sdio_pending_irqs+0x68/0x1a0 [ 14.339144] sdio_irq_work+0x40/0x70 [ 14.339154] process_one_work+0x184/0x39c [ 14.339160] worker_thread+0x228/0x3e8 [ 14.339168] kthread+0x148/0x3ac [ 14.339176] ret_from_fork+0x10/0x30 That happened because hdev->power_on is already called before sdio_set_drvdata which btmtksdio_interrupt handler relies on is not properly set up. The details are shown as the below: hci_register_dev would run queue_work(hdev->req_workqueue, &hdev->power_on) as WQ_HIGHPRI workqueue_struct to complete the power-on sequeunce and thus hci_power_on may run before sdio_set_drvdata is done in btmtksdio_probe. The hci_dev_do_open in hci_power_on would initialize the device and enable the interrupt and thus it is possible that btmtksdio_interrupt is being called right before sdio_set_drvdata is filled out. When btmtksdio_interrupt is being called and sdio_set_drvdata is not filled , the kernel oops is going to happen because btmtksdio_interrupt access an uninitialized pointer.

Affected products

Linux kernel: from 5.2 before 5.4.189; from 5.5 before 5.10.110; from 5.11 before 5.15.33; from 5.16 before 5.16.19; from 5.17 before 5.17.2 — fixed in 5.10.110, 5.15.33, 5.16.19, 5.17.2, 5.4.189

How to fix

Upgrade to a fixed version: Linux kernel 5.10.110, 5.15.33, 5.16.19, 5.17.2. Check the vendor advisory for mitigations.

References

Get alerted when CVE-2022-49200 or the next vulnerability affects your stack