CVE-2026-74540 is a use-after-free in the Bluetooth L2CAP layer's LE connect response handler. The vulnerability stems from l2cap_le_connect_rsp() calling __l2cap_get_chan_by_ident() to locate a channel, then locking and operating on it — without first taking a reference. A concurrent l2cap_chan_del() triggered by a remote disconnect can free the channel between the lookup and the lock, yielding a UAF with a narrow but exploitable race window.
What makes this worth deeper attention is the pattern inconsistency. The BR/EDR counterpart l2cap_connect_rsp() and the sibling l2cap_le_command_rej() both use l2cap_chan_hold_unless_zero() before touching the channel — the exact pattern now applied as the fix. This wasn't a case of unknown idiom; the correct answer was visible in the same file. The most likely explanations are a copy-paste omission during initial implementation or an incomplete refactor when the LE variant was introduced.
The API design is the underlying enabler. __l2cap_get_chan_by_ident() performs the lookup without establishing ownership, placing the burden on each caller to independently know to call l2cap_chan_hold_unless_zero(). This splits cognitive responsibility across multiple entry points — a maintenance tax that scales poorly. The fact that two handlers got it right and one didn't suggests a structural gap in review: when correct and incorrect code look identical except for one line, standard diff review won't catch it.
Given the low EPSS score, this may not be actively weaponized yet, but treat that as provisional. The LE response handler path should be audited holistically — if l2cap_le_connect_rsp was wrong, other LE handlers may have similar gaps. The fix is correct, but the pattern will recur unless the codebase either makes the safe API the default or instruments static analysis to flag lookup-without-hold patterns. Check your kernel logs for l2cap-related UAF crashes in Bluetooth traffic; if present, prioritize this patch and review adjacent handlers.