CVE-2024-36012 is a newly resolved vulnerability in the Linux kernel’s Bluetooth stack, specifically relating to Microsoft's Bluetooth extensions (msft feature). The vulnerability allowed for a *slab use-after-free* scenario, which could potentially be exploited to cause system instability or escalate privileges.

Let's break down the bug, see the vulnerable code path, and understand how it got patched. I'll also show how this could have been exploited, all in straightforward language.

What Happened?

When dealing with Bluetooth devices, Linux maintains a structure called msft_data tied to each device. The issue happened because msft_data could be *freed* (memory returned to the system) in one path (msft_unregister()), but another path (msft_do_close()) might still try to use it right after.

This created a classic *use-after-free* error—a type of bug where freed memory is accessed again, leading to kernel crashes and sometimes letting attackers run code of their choosing.

Here’s what was going on, step-by-step

// [use]
msft_do_close()
  msft = hdev->msft_data;
  if (!msft)                        // (1) msft exists here.
    return;
  mutex_lock(&msft->filter_lock);   // (4) msft might have been freed already!

// [free]
msft_unregister()
  msft = hdev->msft_data;
  hdev->msft_data = NULL;           // (2) Pointer removed from device.
  kfree(msft);                      // (3) msft memory freed.

If msft_unregister() ran at just the right moment, but before msft_do_close()'s mutex_lock call, then msft_do_close() would try to access already-freed memory (msft), triggering a kernel bug as seen in logs:

BUG: KASAN: slab-use-after-free in __mutex_lock_common
kernel/locking/mutex.c:587 [inline]

Who is at risk?

- Any Linux system exposing the Bluetooth stack where userspace or attackers can toggle Bluetooth connections and trigger close/unregister operations.

Exploitability?

- Practice has shown that attacking use-after-frees, especially in kernel, can be difficult but not impossible for determined attackers, particularly when heap re-use patterns are predictable.

In parallel, trigger device close events.

4. Aim to execute code at the time window so that stale memory (where msft_data was) gets reused, letting attacker-controlled data reside at the freed memory—possibly abusing the still-running mutex_lock() to corrupt kernel state.

Pseudocode Example

// Userland exploit sketch (incomplete)
// Simultaneously trigger these Bluetooth stack operations:
thread 1: 
    // Open Bluetooth device, then close (calls msft_do_close internally)

thread 2: 
    // Unregister Bluetooth device (calls msft_unregister)

In the right timing, msft_do_close uses a freed structure, possibly leading to kernel heap memory corruption.

The Upstream Fix

The core of the patch is simple: ensure msft_data memory is freed together with the rest of the device structure, not earlier. Tying its lifetime to the Bluetooth device ensures there's no window where msft_data is dangling but still accessible.

Fixed Code Highlight

// Do NOT free msft_data in msft_unregister() anymore
// Instead, free in hci_release_dev(), where the device gets destroyed

void hci_release_dev(struct hci_dev *hdev) {
    ...
    kfree(hdev->msft_data); // Now msft_data lives until the device is fully gone
    ...
}

See the official patch here.

References

- Upstream Commit in Linux
- Linux Bluetooth Mailing List: Bug Report
- CVE Entry (CVE-2024-36012)

Summary

- CVE-2024-36012 was a use-after-free bug in Linux’s Bluetooth msft extension, involving a timing window between freeing the msft_data and using it.

Patched by making sure msft_data's lifetime matches the device's, closing the hole.

If you maintain a Linux kernel, update to incorporate this patch as soon as possible!


*Always keep your Linux kernel up to date to stay safe from such bugs!*

Timeline

Published on: 05/23/2024 07:15:08 UTC
Last modified on: 01/06/2025 22:33:55 UTC