CVE-2026-19742: IPv6 stable and temporary interface identifiers derived from a non-cryptographic PRNG secret key
The IPv6 stack derived the long-lived secret key used to compute RFC 7217 stable interface identifiers (genstableiid() in subsys/net/ip/ipv6.c) and RFC 8981 temporary interface identifiers (gentemporaryiid() in subsys/net/ip/ipv6pe.c) with sysrandget(). That API is documented as not cryptographically secure, while both RFCs require this key to be an unpredictable random value of at least 128 bits — the unpredictability of every generated IID rests entirely on it.
Depending on the platform, sysrandget() resolves either to a hardware entropy device or, on boards whose entropy driver sets CONFIGENTROPYNEEDSPRNG, to the non-cryptographic xoshiro128++ generator in subsys/random/randomxoshiro128.c, which keeps a single global 128-bit state shared with every other sysrandget() consumer. Many of those consumers put their output directly on the wire (ephemeral source ports, DNS query IDs, CoAP message IDs and tokens, DHCPv6 transaction IDs, WebSocket masking keys), and the xoshiro state transition is invertible, so an observer of a device's traffic can recover the generator state and reconstruct the IID secret key. Additionally, with the entropy-device backend sysrandget() silently falls back to kcycleget32() samples when the entropy driver fails, and returns no error, so the key could be derived from the cycle counter without the caller noticing.
With the key known, stable IIDs become directly computable for any prefix (the remaining HMAC inputs — prefix, interface index, interface name, DAD counter — are guessable), and temporary IIDs become linkable after a cheap search over the mixed-in kuptimeget32() value. This defeats the properties both features exist to provide: an attacker can track a device across networks and prefixes, and can predict its address inside a /64 without scanning, removing the usual barrier to directly targeting the host. There is no memory-safety, integrity, or availability impact.
The fix generates the key with syscsrandget() and aborts IID generation with -EIO when no cryptographic randomness is available, instead of silently deriving addresses from a predictable key. Both CONFIGNETIPV6IIDSTABLE and CONFIGNETIPV6PE are experimental and disabled by default; builds using CONFIGTESTRANDOMGENERATOR remain predictable by design, as syscsrandget() is deliberately routed back to the test generator there.
Affected Software
Event History
Frequently Asked Questions
What would an attacker need to observe to exploit the predictable IID generation path?
On platforms where sys_rand_get() uses the xoshiro128++ generator, an attacker needs to observe traffic containing values produced by other sys_rand_get() consumers. Examples named in the advisory include ephemeral source ports, DNS query IDs, CoAP message IDs and tokens, DHCPv6 transaction IDs, and WebSocket masking keys; the invertible generator state can then be recovered to reconstruct the IID secret key.
How can I identify systems that should be prioritized for investigation?
Prioritize boards whose entropy driver sets CONFIG_ENTROPY_NEEDS_PRNG, because sys_rand_get() resolves to the non-cryptographic xoshiro128++ generator on those systems. Determine whether the device exposes traffic containing outputs from sys_rand_get() consumers, since those observable values can support recovery of the shared global generator state.