CVE-2024-58238

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btnxpuart: Resolve TX timeout error in power save stress test<br /> <br /> This fixes the tx timeout issue seen while running a stress test on<br /> btnxpuart for couple of hours, such that the interval between two HCI<br /> commands coincide with the power save timeout value of 2 seconds.<br /> <br /> Test procedure using bash script:<br /> <br /> hciconfig hci0 up<br /> //Enable Power Save feature<br /> hcitool -i hci0 cmd 3f 23 02 00 00<br /> while (true)<br /> do<br /> hciconfig hci0 leadv<br /> sleep 2<br /> hciconfig hci0 noleadv<br /> sleep 2<br /> done<br /> <br /> Error log, after adding few more debug prints:<br /> Bluetooth: btnxpuart_queue_skb(): 01 0A 20 01 00<br /> Bluetooth: hci0: Set UART break: on, status=0<br /> Bluetooth: hci0: btnxpuart_tx_wakeup() tx_work scheduled<br /> Bluetooth: hci0: btnxpuart_tx_work() dequeue: 01 0A 20 01 00<br /> Can&amp;#39;t set advertise mode on hci0: Connection timed out (110)<br /> Bluetooth: hci0: command 0x200a tx timeout<br /> <br /> When the power save mechanism turns on UART break, and btnxpuart_tx_work()<br /> is scheduled simultaneously, psdata-&gt;ps_state is read as PS_STATE_AWAKE,<br /> which prevents the psdata-&gt;work from being scheduled, which is responsible<br /> to turn OFF UART break.<br /> <br /> This issue is fixed by adding a ps_lock mutex around UART break on/off as<br /> well as around ps_state read/write.<br /> btnxpuart_tx_wakeup() will now read updated ps_state value. If ps_state is<br /> PS_STATE_SLEEP, it will first schedule psdata-&gt;work, and then it will<br /> reschedule itself once UART break has been turned off and ps_state is<br /> PS_STATE_AWAKE.<br /> <br /> Tested above script for 50,000 iterations and TX timeout error was not<br /> observed anymore.