CVE-2026-19735

Source
https://cve.org/CVERecord?id=CVE-2026-19735
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-19735.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2026-19735
Aliases
  • GHSA-37mc-2q9v-fp64
Published
2026-10-11T17:14:56Z
Modified
2026-10-12T02:41:03Z
Severity
  • 4.8 (Medium) CVSS_V3 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N CVSS Calculator
Summary
Predictable TCP initial sequence numbers when the RFC 6528 secret key generation fails silently in the Zephyr TCP stack
Details

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.

Database specific
{
    "cna_assigner": "zephyr",
    "cwe_ids": [
        "CWE-330"
    ],
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/19xxx/CVE-2026-19735.json"
}
References

Affected packages

Git / github.com/zephyrproject-rtos/zephyr

Affected ranges

Type
GIT
Repo
https://github.com/zephyrproject-rtos/zephyr
Events
Database specific
Show details
{
    "extracted_events": [
        {
            "introduced": "3.7.0"
        },
        {
            "last_affected": "4.4.2"
        }
    ],
    "source": "AFFECTED_FIELD"
}

Affected versions

v3.*
v3.7.0
v4.*
v4.0.0
v4.0.0-rc1
v4.0.0-rc2
v4.0.0-rc3
v4.1.0
v4.1.0-rc1
v4.1.0-rc2
v4.1.0-rc3
v4.2.0
v4.2.0-rc1
v4.2.0-rc2
v4.2.0-rc3
v4.3.0
v4.3.0-rc1
v4.3.0-rc2
v4.3.0-rc3
v4.4.0
v4.4.0-rc1
v4.4.0-rc2
v4.4.0-rc3
v4.4.1
v4.4.1-rc1
v4.4.2
v4.4.2-rc1

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-19735.json"