zephyr: NULL Pointer Dereference
CVE-2026-79976 is a high-severity NULL pointer dereference vulnerability in zephyr from Zephyr Project, with a CVSS 3.1 base score of 7.1 out of 10. It can be exploited from the same local network by an unauthenticated attacker, without any action from a user. The record lists versions 4.3.2, 4.5.0 as the first without the flaw, so updating zephyr to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.29% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update zephyr to 4.3.2 or 4.5.0, whichever matches your release line, or a later version.
- Read the advisory on github.com for workarounds and exact fixed builds.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Zephyr Project | zephyr | 4.3.0 up to, but not including, 4.3.2; 4.4.0 up to, but not including, 4.5.0 | 4.3.2, 4.5.0 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- AdjacentThe attacker must be on the same local network segment.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Privileges required
- NoneNo account or login is needed.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- LowSome restricted data can be read.
- Integrity
- NoneNothing can be modified.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H. Scored by CNA (zephyrproject.org).
Official 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->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.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: NULL Pointer Dereference
The product dereferences a pointer that it expects to be valid but is NULL.
How developers prevent this class of flaw
- For any pointers that could have been modified or provided from a function that can return NULL, check the pointer for NULL before use. When working with a multithreaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the check, and unlock when it has finished.
- Select a programming language that is not susceptible to these issues.
- Check the results of all functions that return a value and verify that the value is non-null before acting upon it.
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: partial).
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
Other vulnerabilities in zephyr
- 7.8 High severity
- 7.8 High severity
- 9.1 Critical severity
- 8.3 High severity
- 7.5 High severity
- 7.8 High severity
Recent NULL Pointer Dereference vulnerabilities
- 7.5 High severity
- 7.5 High severity
- 7.5 High severity
- 7.5 High severity
- 7.5 High severity
- 7.5 High severity
Spotted an error? Tell us.