Live › vulnerability › CVE-2026-79976
Go to dashboardThe MCTP-over-I2C+GPIO target driver keeps a selected register and data-phase flag after an I2C STOP, so a second bus transaction can reach a path that uses a NULL packet buffer. A device acting as bus controller can crash the target with a fatal exception, a denial of service, and on parts where address 0 is readable the transmit path can drop packets.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Only builds that opt into the experimental MCTP subsystem with the I2C+GPIO target binding enabled are exposed. The exposure is through the shared management bus, where any device able to act as I2C controller, such as compromised firmware on a peer MCTP endpoint or a BMC, can trigger it. Systems without that configuration can skip it.
No product ranges from the sources yet.
CONFIG_MCTP and CONFIG_MCTP_I2C_GPIO_TARGET=y in its configurationsubsys/pmci/mctp/mctp_i2c_gpio_target.cb->reg_addr to MCTP_I2C_GPIO_INVALID_ADDR and clears b->rxtx at every STOPCONFIG_MCTP_I2C_GPIO_TARGET if the MCTP I2C+GPIO target is not needed (unknown whether this is the only mitigation)Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-79976")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.