CVE-2026-97472: ipv6: addrconf: fix temp address generation after prefix deprecation
In the Linux kernel, the following vulnerability has been resolved:
ipv6: addrconf: fix temp address generation after prefix deprecation
When a router temporarily deprecates an IPv6 prefix (either by sending a Router Advertisement with Preferred Lifetime = 0 or by letting the lifetime expire) and later restores it, the kernel permanently loses its ability to generate temporary privacy addresses (RFC 8981) for that prefix.
This happens because the address worker attempts to generate a replacement temporary address when the current one nears expiration. As the base prefix is deprecated already, the generation fails after marking the temporary address as already having spawned a replacement (ifp->regencount++).
When the router eventually restores the prefix, the temporary address becomes active again. However, once it naturally expires, the address worker sees this temporary address already tried to generate one and skips the regeneration.
Fix the issue by resetting the regencount check of the latest temp address generated for the prefix updated by the incoming RA.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Linux systems using IPv6 temporary privacy addresses are affected when a router deprecates an IPv6 prefix and later restores it. The failure concerns temporary address regeneration for that restored prefix.
What network event is required to trigger the condition?
A router must temporarily deprecate a prefix, either by advertising a Preferred Lifetime of zero or allowing the preferred lifetime to expire, and then later restore that prefix. After the active temporary address subsequently expires, the kernel may fail to generate a replacement.
What is the operational impact if the issue occurs?
The host can permanently lose the ability to generate new RFC 8981 temporary privacy addresses for the affected prefix. This can leave the restored prefix without a newly regenerated temporary address after the existing one expires.
How can administrators identify a potentially affected prefix?
Look for prefixes that were temporarily deprecated by Router Advertisements or lifetime expiry and later restored. If temporary IPv6 addresses for such a prefix stop being regenerated after the existing temporary address expires, the system is exhibiting the described behavior.