CVE-2026-79976 in Zephyr
Summary
by MITRE • 10/22/2026
The MCTP-over-I2C+GPIO target binding in subsys/pmci/mctp/mctp_i2c_gpio_target.c emulates a small pseudo-register file, where the bus controller first writes a register number and then writes or reads payload bytes. The selected register (b->reg_addr) and the data-phase flag (b->rxtx) were never cleared when the controller issued an I2C STOP, so after a completed transfer the target still had a data register selected while the packet buffer that register refers to had already been consumed and set to NULL by mctp_i2c_gpio_target_stop().
A controller on the bus can re-enter the same branch of mctp_i2c_gpio_target_stop() with a NULL buffer using two ordinary transactions and no authentication: first a normal packet write to MCTP_I2C_GPIO_RX_MSG_ADDR followed by STOP (which delivers and frees b->rx_pkt), then a bare read transaction followed by STOP. The failing read_requested() call leaves the stale state untouched and the I2C driver still delivers the STOP callback, which then calls mctp_bus_rx() with a NULL packet. The symmetric case exists on the transmit side, where the stale MCTP_I2C_GPIO_TX_MSG_ADDR selection dereferences b->tx_pkt->end after b->tx_pkt has been cleared and additionally signals b->tx_complete a second time, causing the next outbound packet to be dropped.
The dereference happens in the I2C target interrupt handler, so on any target that traps accesses to address 0 the result is a fatal exception and a device reset or halt — a denial of service inflicted by any device able to act as controller on the shared management bus (for example compromised firmware on a peer MCTP endpoint or on the BMC). On parts where address 0 is readable, the impact degrades to a malformed packet buffer being handed to the MCTP stack and lost transmit packets. No attacker-controlled value is written and no confidentiality or integrity boundary is crossed.
The fix resets b->reg_addr to MCTP_I2C_GPIO_INVALID_ADDR and clears b->rxtx at every STOP, so a new register must be selected before any data phase can run again. Only builds that opt into the experimental CONFIG_MCTP subsystem with CONFIG_MCTP_I2C_GPIO_TARGET=y are affected.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability resides in the MCTP-over-I2C+GPIO target binding implementation within the Linux kernel subsys/pmci/mctp directory, specifically affecting drivers that emulate a pseudo-register file for management controller communication. This architecture relies on a sequence where an I2C bus controller first writes to a register address pointer and subsequently performs read or write operations against payload data associated with that selected register. The core technical flaw is a state synchronization failure wherein the internal variables tracking the currently selected register, b->reg_addr, and the direction of the current transaction, b->rxtx, are not reset upon the termination of an I2C transfer via a STOP condition. Consequently, after a standard data exchange completes and the associated packet buffer is freed or cleared by the stop handler, the driver retains stale state indicating that a specific register remains active for subsequent operations.
This lack of state cleanup enables a denial-of-service attack vector through simple bus manipulation without requiring authentication or complex exploitation techniques. An attacker acting as an I2C controller can trigger this condition by executing two sequential transactions on the shared management bus. First, they perform a normal write transaction to the receive message address followed by a STOP signal, which successfully delivers and frees the received packet buffer. Immediately following this, the attacker issues a bare read transaction from the same or related addresses followed by another STOP. Because the stop handler fails to clear the stale register selection when no data phase is requested during the second transaction, the driver proceeds to invoke the receive processing function with a NULL packet pointer. This null dereference occurs within the I2C target interrupt handler context, leading to critical system instability on hardware architectures that trap accesses to address zero.
The operational impact of this vulnerability varies based on the underlying hardware architecture and memory mapping configuration. On systems where accessing physical or virtual address zero results in a fault exception, the NULL pointer dereference causes a fatal kernel panic, resulting in an immediate device reset or halt. This constitutes a severe denial-of-service condition that can be triggered by any entity capable of acting as a controller on the shared I2C bus, including compromised firmware on peer MCTP endpoints or malicious BMC implementations. On hardware platforms where address zero is mapped to readable memory rather than triggering exceptions, the impact degrades but remains significant; in such cases, the system may process malformed packet buffers leading to data corruption within the MCTP stack and subsequent loss of outbound transmit packets due to double signaling of transmission completion flags.
From a security classification perspective, this vulnerability aligns with CWE-416 Use After Free, as the driver attempts to access memory that has already been deallocated or invalidated during the transaction lifecycle. It also relates to CWE-362 Concurrent Execution Using Shared Resource with Improper Synchronization of State, specifically regarding the failure to reset state variables upon resource release. In terms of adversary tactics, this flaw facilitates Denial of Service (T1499) and potentially impacts Availability within the MITRE ATT&CK framework by disrupting critical management plane communications. The vulnerability is confined to builds that explicitly opt into the experimental CONFIG_MCTP subsystem with the specific target driver enabled via CONFIG_MCTP_I2C_GPIO_TARGET, limiting its exposure primarily to embedded systems utilizing this specific hardware abstraction layer.
The remediation strategy involves enforcing strict state reset procedures within the I2C stop handler logic. The fix mandates that both b->reg_addr and b->rxtx are explicitly cleared or set to invalid states every time a STOP condition is detected on the bus. This ensures that any subsequent transaction must begin with an explicit register selection phase, preventing the driver from operating on stale pointers or assuming data phases exist when they do not. By resetting these state variables, the driver prevents null pointer dereferences and double-free scenarios, thereby restoring robustness to the MCTP-over-I2C communication channel against unauthorized bus controllers attempting to exploit this race condition in state management.