CVE-2026-19742
The IPv6 stack derived the long-lived secret key used to compute RFC 7217 stable interface identifiers (gen_stable_iid() in subsys/net/ip/ipv6.c) and RFC 8981 temporary interface identifiers (gen_temporary_iid() in subsys/net/ip/ipv6_pe.c) with sys_rand_get(). 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, sys_rand_get() resolves either to a hardware entropy device or, on boards whose entropy driver sets CONFIG_ENTROPY_NEEDS_PRNG, to the non-cryptographic xoshiro128++ generator in subsys/random/random_xoshiro128.c, which keeps a single global 128-bit state shared with every other sys_rand_get() 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 sys_rand_get() silently falls back to k_cycle_get_32() 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 k_uptime_get_32() 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 sys_csrand_get() and aborts IID generation with -EIO when no cryptographic randomness is available, instead of silently deriving addresses from a predictable key. Both CONFIG_NET_IPV6_IID_STABLE and CONFIG_NET_IPV6_PE are experimental and disabled by default; builds using CONFIG_TEST_RANDOM_GENERATOR remain predictable by design, as sys_csrand_get() is deliberately routed back to the test generator there.
Executive briefing
The source record describes: The IPv6 stack derived the long-lived secret key used to compute RFC 7217 stable interface identifiers (gen_stable_iid() in subsys/net/ip/ipv6.c) and RFC 8981 temporary interface identifiers (gen_temporary_iid() in subsys/net/ip/ipv6_pe.c) with sys_rand_get(). 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, sys_rand_get() resolves either to a hardware entropy device or, on boards whose entropy driver sets CONFIG_ENTROPY_NEEDS_PRNG, to the non-cryptographic xoshiro128++ generator in subsys/random/random_xoshiro128.c, which keeps a single global 128-bit state shared with every other sys_rand_get() 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 sys_rand_get() silently falls back to k_cycle_get_32() 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 k_uptime_get_32() 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 sys_csrand_get() and aborts IID generation with -EIO when no cryptographic randomness is available, instead of silently deriving addresses from a predictable key. Both CONFIG_NET_IPV6_IID_STABLE and CONFIG_NET_IPV6_PE are experimental and disabled by default; builds using CONFIG_TEST_RANDOM_GENERATOR remain predictable by design, as sys_csrand_get() is deliberately routed back to the test generator there. The practical risk depends on whether an affected product/version is present, reachable and configured in an exploitable way. Review the affected-product evidence and linked vendor advisories before assigning exposure status.
Evidence confidence: Limited Evidence-derived, not an exploitability verdict
Severity & attack characteristics
CVSS vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
Technical explanation & impact
The technical mechanism is not expanded beyond the source description unless a referenced advisory supplies additional evidence. Read the linked vendor/CERT advisories for root-cause detail.
Potential impact must be interpreted from the published CVSS impact metrics and the affected component. A CVSS impact score is not proof that a particular asset is exploitable.
Weakness classification
CWE-338Affected products and versions
NVD has not supplied machine-readable vulnerable CPE product/version entries for this CVE. This is an information gap, not proof that no products are affected. Check the vendor advisory references below.
Remediation & validation
- Identify exposure by comparing the affected product and version ranges with your asset inventory, SBOM and externally exposed services.
- Review the linked vendor security advisory or patch notes. Upgrade to a vendor-confirmed fixed release; do not infer a fixed version from the CVE description.
- Until patched, consider restricting network access or disabling the affected feature where operationally safe. These are temporary controls, not a substitute for a vendor fix.
- Validate the remediation with a version check and vulnerability rescan, then retain change evidence.
No fixed version is displayed unless it is explicitly established by a vendor advisory. Follow the vendor's release notes for exact product and branch applicability.
Vendor advisories, patches & exploit references
- https://github.com/zephyrproject-rtos/zephyr/commit/253315829d3cb5906c660d8418d8408d40bd266f VENDOR vulnerabilities@zephyrproject.org
- https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-xfm2-gr93-8mx9 VENDOR vulnerabilities@zephyrproject.org
Information gaps & confidence notes
These gaps indicate missing source data. CVE Watch does not fill them with guessed product, exploit or patch details.
- NVD does not currently provide machine-readable vulnerable CPE product/version entries for this record.
Last enrichment: 2026-11-05T06:00:45+00:00 · Source last modified: 2026-11-04T05:18:51.170