The core issue in CVE-2026-74539 is straightforward: iso_sock_getname() reads iso_pi(sk)->conn without holding lock_sock, violating the subsystem's own locking contract. What makes this analytically significant is not the bug itself—it is a single missing lock—but the location where it occurs and what that reveals about the Bluetooth ISO subsystem's maturity.
This function is invoked via getsockname(), a synchronous syscall that any unprivileged userspace process can trigger on any Bluetooth socket they can access. That is a critical distinction. A race condition buried in asynchronous connection teardown logic requires specific timing between complex state machines and has a constrained blast radius. A race at a syscall boundary that any user can trigger has a blast radius bounded only by how many Bluetooth sockets are in active use. The window is predictable and potentially controllable through busy-wait loops, which moves this from 'requires scheduling luck' to 'achievable with reasonable probability.'
The deeper concern is what this missing lock reveals about the ISO subsystem as a whole. ISO is a newer subsystem added primarily for LE Audio support, and it has seen aggressive integration into the kernel. The fact that a required lock is missing at a fundamental syscall boundary suggests either the locking contract was not clearly communicated during implementation, or the review process failed to catch a violation of a contract that should have been well-understood. Either scenario is concerning.
You should audit the entire iso_ function family for similar patterns—functions that access iso_pi(sk)->conn without holding locksock. The recent CVE will almost certainly prompt a broader audit that finds siblings. Based on historical patterns in similar new subsystems, expect 2-4 more CVEs in this family within the next kernel release cycle. Prioritize reviewing iso functions that are reachable from userspace syscall paths (getname, setsockopt, ioctl) rather than purely internal async paths, because those have the same blast radius exposure.
The EPSS score being low reflects current weaponization status, not theoretical severity. The code is already in production stable kernels on devices that may not receive immediate updates. The disclosure of this specific pattern—lock_sock missing at a userspace-reachable boundary—is itself a signal to adversarial searchers. The vulnerability debt compounds during the window between CVE publication and backport, especially since the disclosure operationalizes the search space for finding adjacent bugs.