CVE-2026-68394 is a use-after-free in the Bluetooth host's conn_update_sync() work callback. The bug: a queued work item held a borrowed pointer into hdev->le_conn_params, but a subsequent LOAD_CONN_PARAM MGMT command can trigger hci_conn_params_clear_disabled() and free that memory before the work executes. KASAN captures the classic triple — allocation by load_conn_param, deallocation by the clearing function, then dereference by the pending callback. This is a textbook race across async boundaries with no structural protection in the original design.
The fix switches the work item to hold a reference to the hci_conn structure instead of the borrowed hci_conn_params pointer. When conn_update_sync runs, it revalidates the connection is still present, looks up the current parameters entry, and cancels if the entry was removed. This is the correct remediation, but it required hand-rolled revalidation logic — the async work pattern gave no signal that this was necessary. Passing borrowed pointers into queued work is natural, silent, and completely wrong in this context.
For defenders: if you're working in hci_cmd_sync_work or related async paths, treat any queued work that captures pointers into hci_conn_params as a red flag. The canonical pattern is now: hold a reference, revalidate on execute, cancel if state removed. Audit existing async work items in the Bluetooth MGMT stack for this exact vulnerability. The practical severity is elevated because the MGMT interface is reachable via hci_sock_sendmsg — an unprivileged local user with Bluetooth access can trigger the reentrancy window and exploit the UAF. This isn't theoretical kernel archaeology; it's a direct local privilege escalation path.
The deeper concern: this remediation pattern (reference + revalidation + cancel) has appeared in enough subsystems that treating it as per-callback boilerplate is a losing strategy. Future developers will encounter the revalidation checks as opaque cruft and rationalize removing them. The gap isn't the fix — it's that the work queue infrastructure provides no mechanism to make pointer capture across async boundaries explicit or costly. Until it does, every new async path in the Bluetooth stack is a potential recurrence of this genotype.