CVE-2026-64539

This CVE is a split-phase validation flaw in the Linux Bluetooth kernel's legacy advertising path. When a local privileged user (CAP_NET_ADMIN) registers an advertising instance with flags == 0, the kernel's tlv_data_max_len() function permits adv_data_len up to the full 31-byte buffer because it only reserves space for the 3-byte Flags header when user-supplied flags carry a managed-flags bit. However, the kernel unconditionally prepends that 3-byte Flags structure at advertisement transmission time, regardless of what the user provided. The result is that instance registration validates under one size model while the workqueue constructs the packet under a different model—a 3-byte overflow onto the kernel stack. The stack buffer is fixed at 64 bytes, bounding the overflow to a maximum of 3 bytes beyond the advertising data region. KASAN catches this precisely because the overflow lands in kernel stack memory rather than heap. This is not a classic TOCTOU race between processes—it is internally inconsistent assumptions across separate kernel execution contexts (instance registration vs. workqueue advertisement). The fix drops the Flags AD structure when there's no room rather than overflowing user data, which is the correct security posture. However, this raises a critical question: does silently dropping Flags on LE-only controllers change observable BLE advertising behavior for scanning devices expecting standard LE formatting? If remote scanners depend on seeing Flags, this mitigation could introduce a functional regression or create detectable fingerprinting opportunities. The legacy 31-byte limit itself is a Bluetooth 4.0 artifact—Bluetooth 5.0 extended advertising uses 255-byte payloads but the kernel preserved this path for backward compatibility, and nobody deprecated it. For defenders: verify your kernel version includes the fix (look for the tlv_data_max_len/advertisement construction change). If you run LE-only controllers with legacy advertising API calls, monitor for any anomalous advertising PDU behavior reported by scanning infrastructure. This bug required a specific configuration (flags == 0, LE-only controller) to trigger, suggesting the legacy path may not be heavily exercised in production—but the very fact it existed undetected until KASAN caught it suggests similar split-phase validation gaps may exist in other legacy Bluetooth paths.

Reviewed through automated stages and approved by a human before publication.