CVE-2023-52518

What it actually does

Unfreed kmalloc allocations for codec capability structures stored in the hci_dev local_codecs list during hci_read_local_codecs_sync and related HCI initialization paths.

Why it matters to the business

Repeated Bluetooth controller initialization on Linux systems gradually consumes kernel memory, eventually causing resource exhaustion, performance degradation, or denial of service on long-running devices.

How an attack unfolds

The leak occurs passively during normal kernel Bluetooth stack bring-up when the controller advertises supported codecs; no attacker-controlled input or remote trigger is required.

How to fix it

Apply the upstream fix present in commit 626535077ba9dc110787540d1fe24881094c15a1; rebuild and deploy updated kernels containing this commit to all affected systems.

How to confirm the fix worked

Confirm the commit is present in the running kernel tree; reproduce HCI initialization while monitoring /sys/kernel/debug/kmemleak or slab traces for absence of the previously leaked hci_codec objects.

Typical attack path

1. Power on or reset a Bluetooth controller that reports codec capabilities
2. Kernel calls hci_read_supported_codecs and hci_codec_list_add which allocate but never free entries
3. Memory accumulates across multiple HCI power cycles until exhaustion

How to detect it

Review kernel slab allocator traces and kmemleak reports for unreferenced objects allocated from __kmalloc via hci_codec_list_add during hci_power_on or hci_dev_open_sync sequences.

What your security team should do

• Prioritize patching kernel packages containing commit 626535077ba9dc110787540d1fe24881094c15a1 on all Bluetooth-enabled hosts
• Temporarily disable Bluetooth HCI if the functionality is not required until patches can be applied
• Add kernel memory leak monitoring to existing observability pipelines for early detection of similar issues