Linux Kernel CVE-2026-74428

Exploitation requires a process able to create and use an AF_RXRPC socket and to reach the recvmsg() OOB-message handling path in rxrpc_recvmsg(); this in turn requires the rxrpc kernel module to be present/loadable, which in practice means the host runs or supports AFS. Limiting factors: the vulnerable branch only executes when OOB messages are being processed, kernel version must fall in the ~6.16-through-pre-fix range, and local socket access is needed to drive the syscall - so despite the AV:N label this is not remote-unauthenticated against a default server, and hosts without rxrpc/AFS are not exposed.

The supplied CVSS of 9.8 (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H) is the automated, worst-case score the kernel CNA applies to almost all kernel CVEs and should not be taken at face value here. The real signals point much lower: EPSS is 0.15% (5th percentile), the vulnerability is NOT on CISA KEV, and no POC is referenced - so this is a high-nominal-CVSS-but-low-real-risk item for most environments. The concrete impact of a double unlock is typically a kernel crash/hang (availability) or, in a worse case, lock-state corruption leading to a use-after-free that could be escalated, rather than the clean C:H/I:H the vector claims. Reachability is also narrower than AV:N suggests: the flaw is in the recvmsg() syscall path, so a local process must hold an AF_RXRPC socket, and AF_RXRPC/AFS is deployed on a small minority of hosts. An organization running AFS on production Linux fleets should still patch on a normal cadence, but this does not warrant emergency out-of-band response for typical servers. There is a data conflict to verify with the vendor: the intelligence tags label this 'Information Disclosure', yet a double unlock is fundamentally a locking/availability defect - treat the info-disclosure characterization as unconfirmed.

A local, low-privileged user opens an AF_RXRPC socket and calls recvmsg() in a way that steers the kernel into the OOB-message branch of rxrpc_recvmsg(), causing the lock to be released twice; the resulting lock-state corruption panics the machine or opens a race that could be developed toward memory corruption. No public exploit is referenced, and building a reliable escalation from a double unlock would require non-trivial kernel exploitation work.