{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-26801", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-26801" ], "published": "2024-04-04T08:23:56Z", "summary": "Bluetooth: Avoid potential use-after-free in hci_error_reset", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Avoid potential use-after-free in hci_error_reset\n\nWhile handling the HCI_EV_HARDWARE_ERROR event, if the underlying\nBT controller is not responding, the GPIO reset mechanism would\nfree the hci_dev and lead to a use-after-free in hci_error_reset.\n\nHere's the call trace observed on a ChromeOS device with Intel AX201:\n queue_work_on+0x3e/0x6c\n __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth ]\n ? init_wait_entry+0x31/0x31\n __hci_cmd_sync+0x16/0x20 [bluetooth ]\n hci_error_reset+0x4f/0xa4 [bluetooth ]\n process_one_work+0x1d8/0x33f\n worker_thread+0x21b/0x373\n kthread+0x13a/0x152\n ? pr_cont_work+0x54/0x54\n ? kthread_blkcg+0x31/0x31\n ret_from_fork+0x1f/0x30\n\nThis patch holds the reference count on the hci_dev while processing\na HCI_EV_HARDWARE_ERROR event to avoid potential crash.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.21-1+rpt1", "1:6.1.47-1+rpt2", "1:6.1.47-1+rpt4", "1:6.1.54-1+rpt2", "1:6.1.58-1+rpt2", "1:6.1.63-1+rpt1", "1:6.1.73-1+rpt1", "1:6.6.20-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi1-rpi-v6", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7l", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v8", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v6", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7l", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v8", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-2712", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v6", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v7", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v7l", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v8", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-2712", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v6", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v7", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v7l", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v8", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-2712", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v6", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v7", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v7l", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v8", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-2712", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v6", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v7", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v7l", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v8", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-2712", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v6", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7l", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v8", "binary_version": "1:6.6.20-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.1.21-1+rpt1": { "linux_commit": "0afb5e98488aed7017b9bf321b575d0177feb7ed", "upstream_version": "6.1.21", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.81" }, "1:6.1.47-1+rpt2": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.81" }, "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.81", "compiled_filter": false }, "1:6.1.54-1+rpt2": { "linux_commit": "2906f7abdc03d4a92b6b0e2e0c87ea2a9dffe8f7", "upstream_version": "6.1.54", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.81" }, "1:6.1.58-1+rpt2": { "linux_commit": "ccf1586ad0663fa91238ac56abf6340d6d740d18", "upstream_version": "6.1.58", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.81" }, "1:6.1.63-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.63", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": "6.1.81" }, "1:6.1.73-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.73", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": "6.1.81" }, "1:6.6.20-1+rpt1": { "linux_commit": "6f16847710cc0502450788b9f12f0a14d3429668", "upstream_version": "6.6.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.21" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-26801" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/e0b278650f07acf2e0932149183458468a731c03" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/98fb98fd37e42fd4ce13ff657ea64503e24b6090" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/6dd0a9dfa99f8990a08eb8fdd8e79bee31c7d8e2" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/da4569d450b193e39e87119fd316c0291b585d14" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/45085686b9559bfbe3a4f41d3d695a520668f5e1" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/2ab9a19d896f5a0dd386e1f001c5309bc35f433b" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/dd594cdc24f2e48dab441732e6dfcafd6b0711d1" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/2449007d3f73b2842c9734f45f0aadb522daf592" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:52:36Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 8.8, "cvss_v3_severity": "High", "scenario": "AV:A - The `HCI_EV_HARDWARE_ERROR` event that queues `hci_error_reset` is emitted by the Bluetooth controller, and an attacker within Bluetooth radio range can induce a controller firmware exception (the well-documented BrakTooth-class malformed-LMP faults) to generate it while simultaneously leaving the controller unresponsive, which is the exact precondition for the reset/unregister race. This is radio-proximity access, not routable network access.\nAC:L - Once the controller is wedged, the sequence is effectively deterministic: `btintel_hw_error()` blocks for two full `HCI_INIT_TIMEOUT` intervals while `hci_cmd_timeout()` counts to five and fires the GPIO reset, so the race window in which `hci_error_reset` runs against `hci_unregister_dev`/`hci_release_dev` is seconds wide and both sides are driven by the same attacker-induced controller failure. The bug was reproducible enough to be observed in the field on shipping ChromeOS/Intel AX201 hardware.\nPR:N - An over-the-air attacker needs no pairing, bonding, authentication, or any account on the target \u2014 malformed link-layer traffic that faults the controller firmware is processed before any credential check. No host-side privileges are involved at all since the triggering event arrives from the controller.\nUI:N - No victim action is required; the hardware error event, the command timeouts, the GPIO reset and the resulting USB disconnect/unregister all occur automatically inside the kernel once the controller faults.\nS:U - The use-after-free corrupts kernel heap memory within the same security authority as the vulnerable code; no VM, hypervisor, or IOMMU boundary is crossed.\nC:H - `hci_release_dev()` frees `hdev->workqueue` (and ultimately `kfree(hdev)`) while `hci_error_reset` is still executing, so `queue_work_on()` reads `wq->flags` and `wq->cpu_pwq` out of a freed slab object the attacker can groom by reclaiming it, yielding a kernel-memory read primitive and disclosure of adjacent heap contents and pointers.\nI:H - After the freed `workqueue_struct` is reclaimed with attacker-controlled data, `queue_work_on()` performs a list insertion into the pool worklist derived from that freed memory, giving a controlled write primitive suitable for corrupting adjacent kernel objects and hijacking control flow; the stale `hdev` is likewise written through by the continuing close/open sequence.\nA:H - The confirmed use-after-free reliably oopses or panics the kernel (the reported crash in `queue_work_on` from `hci_error_reset`), and the freed/destroyed workqueue also strands the subsequent `destroy_workqueue(hdev->req_workqueue)` drain, permanently wedging the Bluetooth stack." } } }