CVE-2022-49200

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