CVE CyberSecurity Database News

CVE-2024-27398 - Use-After-Free Vulnerability in Linux Kernel Bluetooth (sco_sock_timeout) – Explained and Exploited

Poster -

In early 2024, a serious use-after-free bug was found and fixed in the Linux kernel’s Bluetooth stack, specifically in the SCO (Synchronous Connection Oriented link) socket code. This post will break down CVE-2024-27398 in plain language, show the root cause with code examples, and discuss how it could be exploited.
TL;DR: This bug let attackers potentially gain control by exploiting a race between cleanup and timeout code in Bluetooth audio connections. Let's dive deep: what happened, why it matters, and what you should do.

1. Summary of CVE-2024-27398

- Vulnerability: Use-after-free in Bluetooth (net/bluetooth/sco.c)

Introduced: Affects several Linux kernel versions before the fix merged.

- Fixed in: See upstream patch: commit 9d45bae

2. Technical Root Cause

The bug occurs when a Bluetooth SCO connection is torn down and the associated sock object is freed (by one kernel thread), while a delayed timer is still scheduled to use it (from a worker thread). The time window between freeing the object and the timer’s callback leads to a use-after-free.

Here's a summarized view

Cleanup Thread (releasing socket)        Timeout Worker Thread
sco_sock_release
  sco_sock_close
    __sco_sock_close
      sco_sock_set_timer                  (scheduled timer triggers here)
        schedule_delayed_work ---->
  sco_sock_kill
    sock_put(sk) // FREE sk              sco_sock_timeout
                                         sock_hold(sk) // USE sk

The dangerous pattern is

// net/bluetooth/sco.c
static void sco_sock_timeout(struct work_struct *work)
{
    struct sock *sk = container_of(work, struct sock, sk_timer.work);

    sock_hold(sk);        // Increases refcount, but sk could be freed!
    // Accesses freed memory
    ...
}

If sk was released and freed just before the timer triggers, this function operates on bad memory. This is classic use-after-free.

> The KASAN report triggered by PoC is shown below

> [ 95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+x5e/x1c…

How can this be *exploited*?

The attacker needs a way to cause the race intentionally. In practice, they need local access and a way to create and quickly tear down Bluetooth SCO sockets. This is possible with a simple program using the AF_BLUETOOTH socket API, for example via Python or C.

3. The timer will race with socket free in some cases.

4. If the freed memory is reallocated and controlled (e.g., via heap spraying), code could execute with kernel privileges.

Here is a very simplified exploit skeleton in C

#include <sys/socket.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/sco.h>
#include <unistd.h>
#include <stdio.h>

int main() {
    int sock = socket(AF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO);
    if (sock < ) {
        perror("socket");
        return 1;
    }

    // Set up Bluetooth address struct as needed here...
    struct sockaddr_sco addr = {};
    addr.sco_family = AF_BLUETOOTH;

    // Make a connection (could be to a real device or a dummy BT address)
    connect(sock, (struct sockaddr *)&addr, sizeof(addr));

    // Rapidly close to trigger race
    close(sock);

    // Quickly allocate something else to spray the heap here...
    // (Omitted)
    return ;
}

Note: To fully exploit, attacker would need to control timing and memory layout, often using heap spraying techniques to occupy recently freed memory.

4. References

- Patch fixing the bug (kernel.org)
- CVE-2024-27398 at NVD
- BluZ Linux Bluetooth subsystem

How to check

uname -r
# If your kernel is older than v6.7.1 or lacks the above patch, you are at risk.

6. How is this Fixed?

The patch adds proper checks and cancels the timer when releasing the socket, ensuring that timeout callbacks don't access freed sockets. The general defense: never trust delayed work not to race with object freeing.

Example Fix (from the patch)

+ cancel_delayed_work_sync(&sk->sk_timer);
+ // Ensures timer finishes before free

8. Why does this Matter?

Bluetooth bugs in the kernel are valuable attack vectors for local privilege escalation (gaining root). Because the attack only needs local access, any app or script on your system could attempt exploitation unless patched.

9. Bottom Line

CVE-2024-27398 is a dangerous use-after-free bug in Linux Bluetooth. It’s not currently being exploited in the wild (as of June 2024), but is easily weaponizable. Update ASAP.


> Stay safe: Update, restrict untrusted code, and keep Bluetooth disabled unless you need it.

- Linux Bluetooth bug history (Google Project Zero)
- Kernel UAF Guide

*Author: [Your Name] - Security Researcher*
*Date: [2024-06-01]*


*This guide is exclusive, simplified, and written for practical awareness. Share with sysadmins, security ops, or Linux users at risk!*

Timeline

Published on: 05/14/2024 15:12:28 UTC
Last modified on: 05/04/2025 12:55:31 UTC