CVE-2024-24858

What it actually does

Race condition in net/bluetooth {conn,adv}_{min,max}_interval_set() functions allows concurrent modification of L2CAP parameters, resulting in connection or broadcast state corruption and denial of service.

Why it matters to the business

Bluetooth-dependent services on affected Linux systems may become unavailable or unstable, interrupting device pairing, data transfer, or broadcast operations with no immediate workaround.

How an attack unfolds

An attacker with local or adjacent access triggers the race by issuing concurrent interval configuration requests while the Bluetooth stack processes connection or advertisement events, causing L2CAP to enter an invalid state that manifests as a denial of service.

How to fix it

Upgrade the Linux kernel to a patched release once available from the distribution vendor; rebuild and reboot into the fixed kernel image. Disable the Bluetooth subsystem if it is not required for operation.

How to confirm the fix worked

Confirm the running kernel version contains the upstream fix for the interval_set race condition; exercise concurrent Bluetooth configuration workloads and verify L2CAP remains stable without crashes or connection drops.

Typical attack path

1. Obtain local execution or adjacent Bluetooth proximity on a vulnerable kernel
2. Issue overlapping calls to conn_min/max_interval_set or adv_min/max_interval_set
3. Force the kernel to process the racing updates simultaneously
4. Observe L2CAP connection or broadcast failure leading to service disruption

How to detect it

Review kernel logs for L2CAP or Bluetooth interval-related warnings, crashes, or state-machine errors occurring under concurrent connection or advertisement activity.

What your security team should do

• Prioritize kernel updates for all systems exposing Bluetooth interfaces
• Apply compensating controls such as disabling Bluetooth via rfkill when feasible
• Include Bluetooth stack error patterns in kernel log monitoring