In June 2024, the Linux kernel team fixed a concerning deadlock vulnerability in the Bluetooth RFCOMM protocol implementation. This bug, now tracked as CVE-2024-50044, could potentially lock up parts of the system interacting with Bluetooth serial devices, especially if an attacker deliberately exploited it or a rare error state occurred.

Below, we'll walk through what happened, how the code was fixed, and what you should know to secure your system. We'll keep things clear and avoid technical jargon as much as possible.

What Went Wrong?

RFCOMM is part of the Bluetooth stack in Linux, used basically as a virtual serial port service over Bluetooth. It's widely used for tethering, debugging, and connecting various Bluetooth devices.

The problem was in the Linux kernel's RFCOMM implementation, specifically in the way socket locks were handled. rfcomm_sk_state_change is a function in the kernel that gets called when the state of a Bluetooth RFCOMM socket changes (for example, when a connection is established, lost, or closed).

Unfortunately, rfcomm_sk_state_change calls lock_sock(), a function that tries to lock the socket. But in some cases (like when called from rfcomm_sock_ioctl), the socket might already be locked when entering this function, resulting in a circular lock (deadlock) situation.

Example Deadlock Warning

Here's what a warning from a test kernel system might look like (your trace may differ if you try to reproduce):

WARNING: possible circular locking dependency detected
6.8.-syzkaller-08951-gfe46a7dd189e # Not tainted
syz-executor386/5093 is trying to acquire lock:
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{:}, at: lock_sock include/net/sock.h:1671 [inline]
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{:}, at: rfcomm_sk_state_change+x5b/x310 net/bluetooth/rfcomm/sock.c:73

but task is already holding lock:
ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+x226/x6a net/bluetooth/rfcomm/core.c:491

In more human terms: the kernel is calling a function that needs to take a lock, but that lock is already held earlier in the code path. The result is either a deadlock (system freeze) or a kernel warning, depending on timing.

Here's a simplified version of the offending pattern

// File: net/bluetooth/rfcomm/sock.c

void rfcomm_sk_state_change(struct sock *sk)
{
    // Potentially tries to grab a lock that's already held:
    lock_sock(sk);
    // ... do things ...
    release_sock(sk);
}

Some callers, like rfcomm_sock_ioctl(), already lock the socket before calling this function, leading to a double lock attempt.

Fix: Don't Lock Twice

The fix simply removes the lock/unlock from the state change function, requiring callers to ensure the socket is safely locked when needed.

Fixed Code Snippet

void rfcomm_sk_state_change(struct sock *sk)
{
    // No more lock_sock() here!
    // ... do safe things assuming the socket is already locked ...
}

You can check the official git commit that resolved this:
Bluetooth: RFCOMM: fix possible deadlock in rfcomm_sk_state_change

How Could This Be Exploited?

Although this bug is unlikely to be used for direct privilege escalation, it can be abused for Denial-of-Service (DoS) attacks against the Bluetooth subsystem. For example, a local attacker could:

- Use a specially crafted program (using RFComm sockets) to trigger two operations that lock the socket and call rfcomm_sk_state_change in the wrong order, causing the kernel to deadlock.
- In cloud, embedded, or server environments where Bluetooth is exposed, this could be used to freeze system components, requiring a reboot.

Here's a minimal pseudo-code exploit scenario

// Pseudocode for demonstration; do not use for malicious purposes!
int sock = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);
// Perform ioctl that leads to double locking
ioctl(sock, SOME_IOCTL_COMMAND, ...); // Causes nested rfcomm_sk_state_change

A PoC similar to this could be constructed using fuzzers like syzkaller, which discovered this bug.

Update your kernel! Make sure you are running a kernel that includes the fix for CVE-2024-50044.

- Check your vendor's security advisories or the official Linux kernel changelog:
- Upstream commit

References

- Linux kernel commit: Fix possible deadlock in rfcomm_sk_state_change
- syzkaller project (kernel fuzzer)
- Linux Bluetooth Subsystem

Conclusion

CVE-2024-50044 shows how even subtle locking mistakes in kernel code can lead to stability or security issues. While this bug is not as severe as a direct compromise or privilege escalation, it's a reminder that kernel fuzzing and careful code review are essential in keeping Linux safe.

Stay secure: Keep your system patched, restrict Bluetooth access, and always keep an eye on new kernel advisories.

Timeline

Published on: 10/21/2024 20:15:17 UTC
Last modified on: 11/19/2024 01:15:07 UTC