CVE-2026-68189

This is a lock-context-during-refactoring vulnerability, and it's more structural than it first appears. The hci_sync conversion moved EIR (Extended Inquiry Response) generation out of the hdev->lock context where it was previously protected — not because anyone removed a lock, but because the async model split what was formerly one atomic operation into separate phases: snapshot the UUID list, then send the HCI command. The UUID list invariants were protected by the synchronous execution model, not by explicit lock discipline documented for that data structure. The refactoring preserved the req_lock for command ordering but silently abandoned the incidental serialization protecting the UUID list. The fix — holding hdev->lock during eir_create() — restores explicit protection, but the real lesson is what you should audit in your own code. The hci_sync conversion touched every code path that previously ran synchronously during HCI command completion. Any of those paths that access data structures also touched by userspace-accessible operations (management socket paths, device ioctls) could have the same split-lock vulnerability. The UUID list is the one KASAN found; structurally identical gaps in other data paths may still be latent. For defenders: check your hci_sync-converted code for any data structure accessed both from within hci_sync command completion callbacks AND from userspace-facing paths. The pattern is a two-phase operation where snapshot generation moved to a different lock scope than the original synchronous execution. Audit whether those data structures have explicit locking that covers both access patterns, or whether they relied on the old execution model's implicit atomicity. The downstream risk is real — corrupted EIR payloads propagate into controller classification, pairing policy, and scan filtering, affecting connection security decisions beyond the kernel. For the broader hci_sync effort: assume this isn't unique. Code that accumulated multiple access patterns over time develops implicit coupling that no single developer owns. The UUID list case is evidence of a pattern, not proof it's isolated.

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