ghsa-r4f5-ch72-xjwq
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btnxpuart: Resolve TX timeout error in power save stress test
This fixes the tx timeout issue seen while running a stress test on btnxpuart for couple of hours, such that the interval between two HCI commands coincide with the power save timeout value of 2 seconds.
Test procedure using bash script: hciconfig hci0 up //Enable Power Save feature hcitool -i hci0 cmd 3f 23 02 00 00 while (true) do hciconfig hci0 leadv sleep 2 hciconfig hci0 noleadv sleep 2 done
Error log, after adding few more debug prints: Bluetooth: btnxpuart_queue_skb(): 01 0A 20 01 00 Bluetooth: hci0: Set UART break: on, status=0 Bluetooth: hci0: btnxpuart_tx_wakeup() tx_work scheduled Bluetooth: hci0: btnxpuart_tx_work() dequeue: 01 0A 20 01 00 Can't set advertise mode on hci0: Connection timed out (110) Bluetooth: hci0: command 0x200a tx timeout
When the power save mechanism turns on UART break, and btnxpuart_tx_work() is scheduled simultaneously, psdata->ps_state is read as PS_STATE_AWAKE, which prevents the psdata->work from being scheduled, which is responsible to turn OFF UART break.
This issue is fixed by adding a ps_lock mutex around UART break on/off as well as around ps_state read/write. btnxpuart_tx_wakeup() will now read updated ps_state value. If ps_state is PS_STATE_SLEEP, it will first schedule psdata->work, and then it will reschedule itself once UART break has been turned off and ps_state is PS_STATE_AWAKE.
Tested above script for 50,000 iterations and TX timeout error was not observed anymore.
{
"affected": [],
"aliases": [
"CVE-2024-58238"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-09T15:15:27Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btnxpuart: Resolve TX timeout error in power save stress test\n\nThis fixes the tx timeout issue seen while running a stress test on\nbtnxpuart for couple of hours, such that the interval between two HCI\ncommands coincide with the power save timeout value of 2 seconds.\n\nTest procedure using bash script:\n\u003cload btnxpuart.ko\u003e\nhciconfig hci0 up\n//Enable Power Save feature\nhcitool -i hci0 cmd 3f 23 02 00 00\nwhile (true)\ndo\n hciconfig hci0 leadv\n sleep 2\n hciconfig hci0 noleadv\n sleep 2\ndone\n\nError log, after adding few more debug prints:\nBluetooth: btnxpuart_queue_skb(): 01 0A 20 01 00\nBluetooth: hci0: Set UART break: on, status=0\nBluetooth: hci0: btnxpuart_tx_wakeup() tx_work scheduled\nBluetooth: hci0: btnxpuart_tx_work() dequeue: 01 0A 20 01 00\nCan\u0027t set advertise mode on hci0: Connection timed out (110)\nBluetooth: hci0: command 0x200a tx timeout\n\nWhen the power save mechanism turns on UART break, and btnxpuart_tx_work()\nis scheduled simultaneously, psdata-\u003eps_state is read as PS_STATE_AWAKE,\nwhich prevents the psdata-\u003ework from being scheduled, which is responsible\nto turn OFF UART break.\n\nThis issue is fixed by adding a ps_lock mutex around UART break on/off as\nwell as around ps_state read/write.\nbtnxpuart_tx_wakeup() will now read updated ps_state value. If ps_state is\nPS_STATE_SLEEP, it will first schedule psdata-\u003ework, and then it will\nreschedule itself once UART break has been turned off and ps_state is\nPS_STATE_AWAKE.\n\nTested above script for 50,000 iterations and TX timeout error was not\nobserved anymore.",
"id": "GHSA-r4f5-ch72-xjwq",
"modified": "2025-08-09T15:30:21Z",
"published": "2025-08-09T15:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58238"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d5df94ce0e213d5b549633f528f96114c736190"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e4db90e4eb8d5487098712ffb1048f3fa6d25e98"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.