Zephyr RTOS CVE-2026-79976

The target must be a Zephyr build compiled with the experimental CONFIG_MCTP subsystem and CONFIG_MCTP_I2C_GPIO_TARGET=y, operating as an MCTP-over-I2C+GPIO target on a shared I2C management bus. The attacker must be able to act as a controller on that bus - realistically a compromised peer MCTP endpoint or a compromised BMC - and trigger the sequence 'packet write to MCTP_I2C_GPIO_RX_MSG_ADDR + STOP' then 'bare read + STOP' (or the symmetric TX-side case via MCTP_I2C_GPIO_TX_MSG_ADDR). The fatal denial-of-service (device reset/halt) only occurs on parts that trap accesses to address 0; on parts where address 0 is readable the impact degrades to a malformed packet buffer handed to the MCTP stack and dropped outbound packets. Limiting factors: non-default experimental configuration, adjacent (same physical bus) access, and a pre-existing controller foothold - there is no remote network reachability.

Signals are mixed and point to a real-but-bounded priority rather than an urgent one. The CVSS 3.1 vector (AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H, base 7.1 HIGH) is driven almost entirely by A:H (device reset/halt), since the vulnerability is a NULL pointer dereference (CWE-476) with no attacker-controlled write. The vector correctly uses AV:A - exploitation requires a position on the shared I2C management bus, not arbitrary network reach - and PR:N/AC:L reflect that two ordinary unauthenticated transactions suffice. No EPSS score, CISA KEV entry, or public POC was provided, so there is no evidence of active exploitation or weaponization. In SSVC terms: exploitation = none observed, automatable = effectively no (the attacker must already hold a controller role on the bus, e.g. via a compromised peer MCTP endpoint or BMC), technical impact = total for the affected device (DoS). The dominant mitigating factor is scope: only builds that opt into the experimental CONFIG_MCTP subsystem with CONFIG_MCTP_I2C_GPIO_TARGET=y are affected. CONFLICT TO NOTE: the input CVSS vector lists C:L, but the vendor description explicitly states 'no confidentiality or integrity boundary is crossed' - the C:L appears over-stated; the realistic worst case on address-0-readable parts is a malformed packet buffer and dropped TX packets, not a confidentiality leak. Net: a legitimate availability bug worth patching on affected BMC/management-bus deployments, but gated behind both an experimental non-default config and a pre-existing bus-adjacent foothold, so not a mass-exploitation threat.

Compromised firmware on a peer MCTP endpoint or on the BMC gains controller role on the shared I2C management bus and issues a normal packet write to MCTP_I2C_GPIO_RX_MSG_ADDR followed by STOP (delivering and freeing b->rx_pkt), then a bare read transaction followed by STOP; the stale reg_addr/rxtx state causes the target's I2C interrupt handler to call mctp_bus_rx() with a NULL packet. On parts that trap address-0 access this is a fatal exception and device reset/halt (DoS). No public exploit code was identified; the attack is adjacent (AV:A), low-complexity (AC:L), and requires no authentication (PR:N).