REDHAT-BUG-2545923: Low severity BlueZ btmon vulnerability
An out-of-bounds read vulnerability exists in BlueZ btmon's returnlinkkeysevt() in monitor/packet.c. The function uses evt->numkeys from an HCI Return Link Keys event (0x15) as a loop bound without validating that (numkeys 22 + 1) <= size. Crafted btsnoop input (e.g. plen=3, numkeys=85) causes out-of-bounds reads and crashes btmon (stack buffer OOB read; reporter ASan trace). Affects btmon only, not bluetoothd.
Upstream: bluez <= 5.87 reported; upstream git master (checked 2026-10-05) still lacks bounds check in returnlinkkeysevt(). No upstream fix commit identified.
PSIRT ticket: PSIRTSUPT-24932 Reporter: zhailiangliang (Loongson Technology) Verification: docs/SDLC/VM/bluez/psirtsupt-24932/ (static Kaiden analysis)
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
The issue affects users who run btmon on crafted or untrusted btsnoop input. bluetoothd is not affected.
What does an attacker need to trigger the problem?
An attacker needs to provide a btsnoop capture containing a malformed HCI Return Link Keys event with a num_keys value that exceeds the available event data. Processing that capture with btmon can cause an out-of-bounds read and crash.
Is an upstream fix available?
No upstream fix commit has been identified. Upstream git master was checked on 2026-10-05 and still lacked the required bounds check in return_link_keys_evt().
What can be done if no patch is available?
Do not process untrusted btsnoop captures with btmon. Restrict btmon use to captures from trusted sources until a bounds-checking fix is available.
How can I check whether my source tree contains the fix?
Inspect monitor/packet.c in return_link_keys_evt() and verify that evt->num_keys is checked so that num_keys multiplied by 22, plus 1, does not exceed the available event size before it is used as a loop bound.