CVE-2026-79976
HIGH 7.1The 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.
Severe if exploited (CVSS 7.1), but no known exploitation and low modeled probability. Patch on a normal cadence.
Exploitation likelihood
0.3%chance of exploitation in 30 days · 17th percentile
Impact if exploited
7.1CVSS 3.1 · HIGH
- ConfidentialityLow
- IntegrityNone
- AvailabilityHigh
What an attacker needs
- ⚠Access: Must sit on the same / adjacent network
- ✓Privileges: No account or privileges required
- ✓User interaction: No user interaction needed
- ✓Complexity: No special conditions — reliably repeatable
✓ lowers the bar for an attacker · ⚠ raises it
Proof of concept
No public PoC is currently catalogued.
Search for new PoCs
Search GitHub now — results may be empty or unverified.
Tracked sources are checked daily for recent CVEs, including PoCs published after the original disclosure. A later release appears after a tracked source lists it and a refresh succeeds.
Data snapshot:
Weakness (CWE)
- CWE-476: memory-safety
CVSS vector
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H
References and research data (JSON)
All CVSS metrics
- HIGH 7.1 v3.1 · CNA Primary
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H - HIGH 7.1 v3.1 · NVD Secondary
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H
References
Patches & mitigations
- https://github.com/zephyrproject-rtos/zephyr/commit/60f7fee438504de29f2473d7a8d0535235b983ef CVE record · zephyr · Updated 2026-10-21T18:19:34.519Z
NVD · CVE-2026-79976 · Updated 2026-10-23T22:17:01.197
Advisories
- https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-107487 EUVD · EUVD-2026-107487
Technical & other
- https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-76fx-m4mf-24gqCVE record · zephyr · Updated 2026-10-21T18:19:34.519Z
NVD · CVE-2026-79976 · Updated 2026-10-23T22:17:01.197