CVE-2026-64539 in Linux
Summary
by MITRE • 07/28/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/28/2026
This vulnerability represents a stack buffer overflow in the Linux kernel's Bluetooth implementation specifically within the eir_create_adv_data() function located in net/bluetooth/eir.c. The issue manifests as a write operation that exceeds the bounds of a fixed-size buffer, creating a potential security risk through unauthorized memory access patterns. The flaw occurs during the construction of Bluetooth advertising data where the kernel attempts to prepend a 3-byte Flags AD structure to the user-provided advertising data without proper bounds checking. This condition is particularly dangerous because it involves kernel space memory corruption that could potentially be exploited by malicious actors.
The technical root cause stems from improper buffer management logic within the Bluetooth advertising data creation process. When the function processes advertising instances, it calculates available space based on the assumption that the Flags AD structure might not be needed, but then later prepends this 3-byte structure without verifying that sufficient space remains for both the flags and user-provided data. The tlv_data_max_len() function only accounts for these 3 bytes when specific managed-flags bits are set by userspace, creating a scenario where an instance with flags == 0 can be accepted even when adv_data_len approaches the maximum buffer size of 31 bytes for the legacy path. This mismatch between expected and actual buffer usage creates a situation where the memcpy operation attempts to write more data than allocated space.
The operational impact of this vulnerability is significant as it allows a local user with CAP_NET_ADMIN capabilities and access to an LE-only controller to trigger a kernel memory corruption event. The stack-out-of-bounds write occurs during normal Bluetooth advertising operations, specifically when hci_update_adv_data_sync() processes advertising data through the hci_cmd_sync_work workqueue execution path. This creates potential for system instability, denial of service conditions, or more severe exploitation scenarios depending on the attacker's capabilities and access level. The vulnerability is particularly concerning because it operates within kernel space where memory corruption can lead to privilege escalation or complete system compromise.
The vulnerability aligns with CWE-121 Stack-based Buffer Overflow, which specifically addresses situations where data written to a stack buffer exceeds its allocated boundaries. From an ATT&CK perspective, this maps to privilege escalation techniques through kernel vulnerabilities and potentially command execution in the kernel context. The exploit requires local access with specific capabilities but represents a serious threat since it operates at the kernel level where the attacker can gain extensive system control. Mitigation strategies should focus on implementing proper bounds checking before buffer operations, ensuring that the Flags AD structure is only prepended when sufficient space exists for both the flags and user data, and potentially applying defensive programming practices such as using safe copy functions with size validation to prevent similar issues in other kernel subsystems.
The fix involves modifying the eir_create_adv_data() function to check whether sufficient space remains for both the 3-byte Flags AD structure and the user-provided advertising data before attempting to prepend the flags. When there is insufficient space for both components, the kernel should drop the automatically added flags rather than allowing the user-provided data to be truncated or corrupted. This approach follows secure coding principles by ensuring that buffer operations maintain proper bounds checking and by implementing defensive measures that preserve user data integrity while preventing kernel memory corruption. The solution must be carefully implemented to avoid breaking existing functionality while providing the necessary protection against the out-of-bounds write condition that was previously exploitable through the legacy advertising path in LE-only controllers.