CVE-2022-0204

What it actually does

Heap buffer overflow in the Bluetooth stack allows an attacker on the local network to supply malformed data that corrupts memory and terminates the bluez daemon.

Why it matters to the business

Bluetooth-dependent services such as wireless peripherals, audio devices, and device pairing become unavailable until the affected process is restarted, creating operational downtime and support overhead.

How an attack unfolds

An attacker with local-network adjacency crafts and transmits specially formatted Bluetooth packets or profile data to a vulnerable bluez instance; the malformed input triggers an out-of-bounds write on the heap, crashing the daemon and producing denial of service. Public exploit code is available, though no named threat actors or ransomware campaigns have been observed leveraging the flaw.

How to fix it

Upgrade bluez to a build containing commit 591c546c536b42bef696d027f64aa22434f8c3f0 or later (corresponding to version 5.63 or newer). Rebuild packages from source if using a GIT checkout, then restart the bluetoothd service and verify the updated binary.

How to confirm the fix worked

Confirm the running bluez binary reports version 5.63 or newer, or that the source tree contains commit 591c546c536b42bef696d027f64aa22434f8c3f0. Monitor process stability under simulated malformed input and review build logs for the patched code path.

Typical attack path

1. Obtain local network adjacency to the target Bluetooth host
2. Identify an active bluez instance via Bluetooth service discovery
3. Transmit a sequence of specially crafted packets or SDP/ATT payloads
4. Trigger the heap overflow and observe daemon termination

How to detect it

Review system and daemon logs for repeated bluez crashes or segmentation faults coinciding with Bluetooth activity; inspect core dumps or stack traces referencing heap operations in the Bluetooth stack; correlate network captures containing unusual SDP, ATT, or L2CAP frames with process restarts.

What your security team should do

• Prioritize patching or rebuilding bluez within the next maintenance window given the public exploit availability
• Restrict Bluetooth interfaces to trusted networks or disable unnecessary profiles until the update is applied
• Add bluez version checks to configuration-management and vulnerability-scanning pipelines