CVE-2026-68397 is a use-after-free in the AF_IUCV driver where the kernel frees a socket while it's still in use. The bug lives in afiucv_hs_rcv(), which looks up a socket under the iucv_sk_list.lock spinlock, then drops that lock before calling sk->sk_data_ready() through afiucv_hs_callback_syn(). Between the unlock and the function pointer dereference, any concurrent socket close can call iucv_sock_kill() and free the socket—leaving a dangling pointer that gets invoked moments later. The race window is deterministic and bounded by the unlock-to-callback interval.
This isn't a one-off error. It reflects a systemic failure in how AF_IUCV manages socket lifecycle. The driver uses synchronous teardown—iucv_sock_kill() frees immediately—rather than the RCU-based deferred free pattern that protects most other network sockets. This choice was appropriate when AF_IUCV was written, but the code never adopted the compensating discipline of sock_hold()/sock_put() to hold a reference across the unlocked window. Other network drivers solved this years ago; AF_IUCV never got the memo.
For defenders: check that any patches to this driver apply sock_hold() after lookup and sock_put() after the callback completes. More importantly, examine other AF_IUCV code paths for the same pattern—lookup under lock, drop lock, dereference—and audit analogous drivers that use synchronous teardown models. The same vulnerability class likely exists elsewhere in less-frequently-audited network drivers, particularly those interfacing with hardware or protocols that haven't seen recent mainstream development. Prioritize auditing drivers with narrow deployment footprints: low user counts correlate with reduced review pressure and higher entropy accumulation over time.
The CVSS 8.8 reflects severity but obscures exploitability complexity and narrow deployment scope. The real concern isn't exploitation of this specific bug—it's that the pattern it represents is probably hiding in other drivers.