CVE-2026-74398

This CVE patches a race condition in the IPv6 address configuration code where `addrconf_dad_timer` drops `ifp->lock` to regenerate a STABLE_PRIVACY address, then re-acquires the lock—but between lock reacquisition and a subsequent `net_info_ratelimited()` call, a concurrent `ipv6_del_addr()` can delete the address object, leaving a dangling pointer that triggers a kernel general protection fault when the timer function attempts to log the DAD failure. The fix is three lines: after reacquiring the lock, verify the address still exists in the interface's address list before proceeding with the state transition. If the state changed, bail out immediately. This is not a structural redesign of the addrconf locking model—the kernel must drop locks around operations that might sleep, and the STABLE_PRIVACY address regeneration is one such operation. The lock-drop/reacquire pattern itself is sound; this instance simply failed to re-validate state across the full re-acquisition boundary. The EPSS score of 0.00521 reflects the narrow exploitation window and specific triggering conditions, not the severity of impact—a successful exploit produces a deterministic kernel panic from list corruption, not contained error handling. However, the DAD path executes on every IPv6 address across every interface, so the blast radius is universal for IPv6-enabled hosts. Audit other lock-drop/reacquire sequences in the addrconf subsystem, particularly where state transitions follow reacquisition, and verify explicit state validation occurs before each transition—not just in one code branch. The pattern of temporary lock release followed by incomplete re-validation has appeared in similar kernel CVEs; systematic code review should flag these sequences as suspect without requiring a CVE to trigger the audit.

Reviewed through automated stages and approved by a human before publication.