---
id: "CVE-2026-79976"
kind: "vulnerability"
aliases: ["CVE-2026-79976"]
title: "Zephyr: stale I2C register state causes NULL dereference in MCTP target"
severity: "high"
cvss: 7.1
epss: 0.00207
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["bmc", "embedded", "i2c", "mctp", "runtime", "zephyr"]
not_affected_if: ["default-config", "mctp-disabled"]
published_at: "2026-10-21T19:17:04+00:00"
first_seen_at: "2026-10-23T21:57:29+00:00"
updated_at: "2026-10-25T03:31:46+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79976", "first_seen_at": "2026-10-23T21:57:29+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-79976", "first_seen_at": "2026-10-24T13:15:54+00:00"}]
---

# Zephyr: stale I2C register state causes NULL dereference in MCTP target

The 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, check and fix written by a model from the sources; labelled as such._

## How to check

- Check whether the build enables `CONFIG_MCTP` and `CONFIG_MCTP_I2C_GPIO_TARGET=y` in its configuration
- Confirm the firmware source includes `subsys/pmci/mctp/mctp_i2c_gpio_target.c`
- Check the Zephyr version in use against the fixed release (unknown from sources)

## Fix

- Apply the upstream fix that resets `b->reg_addr` to `MCTP_I2C_GPIO_INVALID_ADDR` and clears `b->rxtx` at every STOP
- Disable `CONFIG_MCTP_I2C_GPIO_TARGET` if the MCTP I2C+GPIO target is not needed (unknown whether this is the only mitigation)
- Fixed version: unknown from sources

## Timeline

- 2026-10-23T21:57:29+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-79976
- 2026-10-24T13:15:54+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-79976

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_