CVE-2026-64539

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: eir: Fix stack OOB write when prepending the Flags AD

eir_create_adv_data() builds the advertising data into a fixed-size

buffer ("size", 31 for the legacy path). It may prepend a 3-byte "Flags"

AD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies

the per-instance data without checking that it still fits:

memcpy(ptr, adv->adv_data, adv->adv_data_len);

tlv_data_max_len() only reserves those 3 bytes when the user-supplied

flags carry a managed-flags bit, so an instance added with flags == 0 is

accepted with adv_data_len up to the full buffer. At advertise time the

flags are still prepended, and the memcpy() writes 3 + adv_data_len

bytes into the size-byte buffer:

BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)

Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65

Workqueue: hci0 hci_cmd_sync_work

__asan_memcpy (mm/kasan/shadow.c:106)

eir_create_adv_data (net/bluetooth/eir.c:301)

hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)

hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)

hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)

This frame has 1 object:

[32, 64) 'cp'

The "Flags" structure is added by the kernel, not requested by

userspace, so only prepend it when it fits together with the instance

advertising data; when there is no room for both, drop the flags rather

than the user-provided data.

Reachable by a local user with CAP_NET_ADMIN owning an LE-only

controller on the legacy advertising path.