{"id":"CVE-2026-79976","aliases":["EUVD-2026-107487","GHSA-76fx-m4mf-24gq"],"status":"published","title":"NULL pointer dereference in the MCTP I2C+GPIO target binding triggerable by a peer I2C controller","description":"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-\u003ereg_addr) and the data-phase flag (b-\u003erxtx) 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().\n\nA 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-\u003erx_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-\u003etx_pkt-\u003eend after b-\u003etx_pkt has been cleared and additionally signals b-\u003etx_complete a second time, causing the next outbound packet to be dropped.\n\nThe 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.\n\nThe fix resets b-\u003ereg_addr to MCTP_I2C_GPIO_INVALID_ADDR and clears b-\u003erxtx 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.","severity":{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.0029,"percentile":0.21724,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":false},"cwes":["CWE-476"],"published":"2026-10-21T18:19:34Z","modified":"2026-11-05T03:31:29Z","products":[{"vendor":"zephyrproject","product":"zephyr"},{"vendor":"zephyrproject-rtos","product":"zephyr"}],"references":[{"url":"https://github.com/zephyrproject-rtos/zephyr/commit/60f7fee438504de29f2473d7a8d0535235b983ef","tags":["patch","fix"]},{"url":"https://github.com/zephyrproject-rtos/zephyr/commit/a097178023785f3bc0a925ac489e490521ca84ea","tags":["patch","fix"]},{"url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-76fx-m4mf-24gq","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/79xxx/CVE-2026-79976.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-79976","tags":["advisory"]},{"url":"https://github.com/zephyrproject-rtos/zephyr","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-79976","title":"NULL pointer dereference in the MCTP I2C+GPIO target binding triggerable by a peer I2C controller","description":"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-\u003ereg_addr) and the data-phase flag (b-\u003erxtx) 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().\n\nA 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-\u003erx_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-\u003etx_pkt-\u003eend after b-\u003etx_pkt has been cleared and additionally signals b-\u003etx_complete a second time, causing the next outbound packet to be dropped.\n\nThe 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.\n\nThe fix resets b-\u003ereg_addr to MCTP_I2C_GPIO_INVALID_ADDR and clears b-\u003erxtx 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.","status":"published","published":"2026-10-21T18:19:34.519Z","modified":"2026-11-04T05:01:22.44Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H","level":"high","assessor":"cna"}],"cwes":["CWE-476"],"updated_at":"2026-11-04T06:53:01.479776Z"}],"euvd":[{"id":"EUVD-2026-107487","description":"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-\u003ereg_addr) and the data-phase flag (b-\u003erxtx) 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().\n\nA 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-\u003erx_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-\u003etx_pkt-\u003eend after b-\u003etx_pkt has been cleared and additionally signals b-\u003etx_complete a second time, causing the next outbound packet to be dropped.\n\nThe 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.\n\nThe fix resets b-\u003ereg_addr to MCTP_I2C_GPIO_INVALID_ADDR and clears b-\u003erxtx 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.","status":"published","published":"2026-10-21T18:19:34Z","modified":"2026-11-04T05:01:22Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H","level":"high"}],"updated_at":"2026-11-04T07:00:56.104537Z"}],"nvd":[{"id":"CVE-2026-79976","description":"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-\u003ereg_addr) and the data-phase flag (b-\u003erxtx) 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().\n\nA 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-\u003erx_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-\u003etx_pkt-\u003eend after b-\u003etx_pkt has been cleared and additionally signals b-\u003etx_complete a second time, causing the next outbound packet to be dropped.\n\nThe 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.\n\nThe fix resets b-\u003ereg_addr to MCTP_I2C_GPIO_INVALID_ADDR and clears b-\u003erxtx 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.","status":"published","published":"2026-10-21T19:17:04.06Z","modified":"2026-11-04T05:19:02.493Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-476"],"updated_at":"2026-11-04T06:53:27.303246Z"}],"osv":[{"id":"CVE-2026-79976","title":"NULL pointer dereference in the MCTP I2C+GPIO target binding triggerable by a peer I2C controller","description":"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-\u003ereg_addr) and the data-phase flag (b-\u003erxtx) 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().\n\nA 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-\u003erx_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-\u003etx_pkt-\u003eend after b-\u003etx_pkt has been cleared and additionally signals b-\u003etx_complete a second time, causing the next outbound packet to be dropped.\n\nThe 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.\n\nThe fix resets b-\u003ereg_addr to MCTP_I2C_GPIO_INVALID_ADDR and clears b-\u003erxtx 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.","status":"published","published":"2026-10-21T18:19:34.519Z","modified":"2026-11-05T13:08:39.810760581Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H","level":"high"}],"cwes":["CWE-476"],"updated_at":"2026-11-05T13:30:00.949926Z"}]}}