CVE-2024-50125

What it actually does

Use-after-free in Linux kernel Bluetooth SCO socket handling: conn->sk can be unlinked or freed while a timeout waits on sco_conn_lock, allowing access to an invalid socket object.

Why it matters to the business

Systems using Bluetooth SCO profiles risk kernel crashes, denial of service, or potential local privilege escalation; low EPSS and no KEV listing reduce immediate widespread risk but kernel-level flaws affect many Linux distributions.

How an attack unfolds

An attacker with local access creates and manipulates SCO sockets to trigger a timeout race condition where the socket object is freed before the lock-protected check completes, leading to dereference of freed memory.

How to fix it

Apply the upstream fix from commit 74a466a15731a754bcd8b5a83c126b5122e15a45 or upgrade to a kernel containing this patch; verify the fix is present in your distribution's kernel package.

How to confirm the fix worked

Confirm the presence of commit 74a466a15731a754bcd8b5a83c126b5122e15a45 in the kernel source or check that the running kernel version includes the SCO UAF timeout fix; test Bluetooth SCO functionality post-upgrade.

Typical attack path

1. Obtain local access on a Linux system with Bluetooth SCO support enabled
2. Create SCO sockets and induce timeout conditions while triggering concurrent socket cleanup
3. Race the sco_conn_lock to access the now-freed conn->sk pointer
4. Leverage the resulting use-after-free for memory corruption or denial of service

How to detect it

Review kernel logs for Bluetooth SCO timeout and socket-related crashes or warnings around sco_sock_timeout; examine audit logs for unusual local Bluetooth socket activity by unprivileged users.

What your security team should do

• Prioritize kernel updates on systems exposing Bluetooth SCO interfaces
• Monitor for new Linux kernel releases containing the referenced commit
• Limit local user access on multi-user systems until patched
• Review Bluetooth configuration and disable SCO if not required