Zephyr RTOS CVE-2026-18417

Exploitation requires the device to run Zephyr v4.3.0 (the full crash path) with an application that holds a listening TCP socket open across repeated network-interface link-down events; the accept callback is not disarmed on v4.3.0, so a second interface-down forwards a previously stored errno as a bogus context pointer. The trigger is a network-interface state change (link down), NOT attacker-supplied packet data, so the attacker must be positioned to force the link down repeatedly - realistically an adjacent attacker disrupting a wireless link (matching CVSS AV:A) or one with local/physical access - and no authentication or user interaction is needed. Limiting factors: v4.3.1 and v4.4.x carry the accept_cb-clearing fix, reducing this to a narrow handshake-vs-interface-down race plus a getsockopt(SO_ERROR) kernel-pointer read-back; a device with no persistent listening TCP socket, or one that is not subject to repeated link-down events, is not practically exploitable.

This is a genuine but conditional issue with a modest real-world priority. The CVSS 3.1 vector (AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, score 6.5) correctly captures the profile: an adjacent, unauthenticated attacker who can force a network interface down can crash the device (availability-only impact, no confidentiality or integrity). The Zephyr GHSA-p8r8-8mw8-3wf9 advisory and the fix commit (ef370a57) confirm the mechanism and that the observed outcome is a kernel fatal error - a denial of service - not attacker-directed memory corruption, because both the faulting address and stored data are fixed small constants derived from the errno value. There is no EPSS score, no CISA KEV listing, and no public exploit code, so exploitation status is: no public exploit identified at time of analysis. The AV:A (adjacent) vector is well-matched to the described attacker (an adjacent party disrupting a wireless link, or someone with local/physical access) and should NOT be read as remote-Internet exploitability. One nuance worth flagging: the full trigger on the crash path is specific to v4.3.0 (accept callback not disarmed); v4.3.1 and v4.4.x reduce this to a narrow race plus a getsockopt(SO_ERROR) kernel-pointer read-back, so the real risk is version-dependent. Overall this is a real-but-narrow availability defect in embedded/IoT deployments rather than a high-urgency, widely-weaponizable flaw.

An embedded/IoT device runs Zephyr v4.3.0 with an application that keeps a listening TCP socket open (e.g. a management or telemetry service) over a wireless link. An adjacent attacker repeatedly forces the interface down (e.g. by disrupting the wireless link); the first interface-down event poisons net_context.user_data with an errno value, and a second one causes zsock_accepted_cb() to dereference that small integer as a context pointer, producing a wild-pointer write and a kernel fatal error that crashes or resets the device. No public exploit code exists, and the trigger is a network-interface state change rather than crafted packets, so success depends on the attacker's ability to repeatedly toggle the link.