Description

The RFC 6528 initial-sequence-number implementation in subsys/net/ip/tcp.c derived every TCP ISN from SHA-256(unique_key || four-tuple) plus a uptime-derived offset, where unique_key is a 128-bit secret filled once by sys_csrand_get(). The return value of that call was discarded and the once guard was latched to true even when the call failed. Because sys_csrand_get() leaves the destination buffer untouched on failure (it deliberately propagates the entropy-driver error rather than filling the buffer), a single failed call left unique_key as its all-zero BSS content for the remainder of the boot, with no retry, no log message and no fallback. A failure of the cryptographic random source is required to reach the weak state — for example -ENODEV/-EIO from the entropy driver in subsys/random/random_entropy_device.c (the in-tree comment notes that the hardware RNG "might still be gathering entropy during early boot situations"), or psa_generate_random() failing in subsys/random/random_psa.c when PSA crypto is not initialised or is backed by a Bluetooth-HCI entropy device that is not yet up. The first TCP connection is what triggers key generation, so a remote peer that reaches a listening port immediately after boot, or that can provoke a reboot, has indirect influence over whether generation coincides with that window. tcp_init_isn() is called for every passive open in tcp_conn_new() and every active open in net_tcp_connect(), so the poisoned key governs all TCP connections for that boot. With an all-zero key the ISN becomes a public function of the connection four-tuple plus a device-wide time offset. An off-path attacker can compute the hash term offline for any four-tuple and recover the shared time offset from a single observed ISN, after which the ISN the device will pick for other four-tuples is predictable. That defeats exactly the protection RFC 6528 provides: blind TCP connection spoofing against peers that trust the source address, and blind data injection into or reset of connections whose four-tuple can be guessed. Devices whose entropy source never errors were never in the weak state. The fix moves key generation into a single guarded helper that latches only on success, logs the error otherwise, and makes tcp_init_isn() fall back to sys_rand32_get() — the behaviour already used when CONFIG_NET_TCP_ISN_RFC6528 is disabled — instead of hashing with a known-constant key.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.8",
  "pubDate": "2026-10-11T18:16:58.683Z",
  "pubdate": "2026-10-11T18:16:58.683Z",
  "executiveSummary": "This vulnerability involves the improper handling of cryptographic random number generator (RNG) failures within the TCP Initial Sequence Number (ISN) generation logic, specifically affecting RFC 6528 implementations in the network stack.\nThe vulnerability allows an off-path attacker to predict TCP ISNs, facilitating blind connection spoofing, unauthorized data injection, or connection hijacking.\nAffected systems fail to re-attempt entropy acquisition if the initial call to sys_csrand_get() returns an error, resulting in a static, predictable all-zero key being used for ISN generation for the remainder of the boot session.\nThe primary risk is the total loss of TCP sequence number randomness, which is a fundamental security control against off-path attacks.\nExploitation requires the device's entropy source to fail during the critical early boot period, often caused by hardware RNG initialization delays or driver errors. Once the key is poisoned, the vulnerability is reachable without authentication or elevated privileges, provided the attacker can interact with the device's TCP stack.",
  "technicalDetails": "The root cause is a logic error in subsys/net/ip/tcp.c where the implementation of RFC 6528 initializes a 128-bit 'unique_key' using sys_csrand_get(). The design erroneously treats the function as successful even when it returns an error, latching the 'once' guard to true despite the buffer containing uninitialized BSS memory (all-zeros).\nIn the event of an entropy driver error (e.g., -ENODEV or -EIO from subsys/random/random_entropy_device.c or failure in subsys/random/random_psa.c), the system fails to retry or fallback. Because the 'unique_key' is set once during the first TCP connection, this poisoned state persists until the next reboot.\nThe ISN generation algorithm uses SHA-256(unique_key || four-tuple) plus a time-derived offset. With a known constant key of zero, the ISN becomes a deterministic function of the connection four-tuple and the device uptime. An off-path attacker can observe a single ISN to derive the current time offset via algebraic reversal of the hash function. Once the offset is recovered, the attacker can predict subsequent ISNs for any arbitrary four-tuple.\nAttack flow involves: 1) Triggering a condition where the entropy source is unavailable (e.g., immediate post-boot connection attempts). 2) Observing a valid TCP connection to the device to recover the current temporal offset. 3) Utilizing the now-predictable ISN generation algorithm to forge segments that appear to originate from a trusted source, effectively bypassing TCP sequence number protections.\nThis vulnerability compromises the integrity of existing TCP connections and allows for blind injection of malicious payloads or forced resets, as the attacker no longer requires in-path observation of traffic to guess valid sequence numbers. The issue is persistent across all connections for the duration of the system uptime, affecting both active and passive TCP opens initiated via tcp_conn_new() or net_tcp_connect()."
}