Zephyr Project up to 4.4.2 MCTP-over-I2C+GPIO target binding mctp_i2c_gpio_target.c mctp_i2c_gpio_target_stop reg_addr/rxtx null pointer dereference
| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 6.7 | $0-$5k | 4.06- |
Summary
A vulnerability, which was classified as critical, has been found in Zephyr Project Zephyr up to 4.4.2. This affects the function mctp_i2c_gpio_target_stop of the file subsys/pmci/mctp/mctp_i2c_gpio_target.c of the component MCTP-over-I2C+GPIO target binding. Performing a manipulation of the argument reg_addr/rxtx results in null pointer dereference.
This vulnerability is identified as CVE-2026-79976. There is not any exploit available.
Details
A vulnerability classified as critical has been found in Zephyr Project Zephyr up to 4.4.2. This affects the function mctp_i2c_gpio_target_stop of the file subsys/pmci/mctp/mctp_i2c_gpio_target.c of the component MCTP-over-I2C+GPIO target binding. The manipulation of the argument reg_addr/rxtx with an unknown input leads to a null pointer dereference vulnerability. CWE is classifying the issue as CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit. This is going to have an impact on confidentiality, integrity, and availability. The summary by CVE is:
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.
It is possible to read the advisory at github.com. This vulnerability is uniquely identified as CVE-2026-79976 since 08/25/2026. The exploitability is told to be easy. No form of authentication is needed for exploitation. Technical details of the vulnerability are known, but there is no available exploit.
There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Product
Type
Vendor
Name
Version
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔒VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 6.7VulDB Meta Temp Score: 6.7
VulDB Base Score: 6.3
VulDB Temp Score: 6.3
VulDB Vector: 🔒
VulDB Reliability: 🔍
CNA Base Score: 7.1
CNA Vector (zephyr): 🔒
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍
Exploiting
Class: Null pointer dereferenceCWE: CWE-476 / CWE-404
CAPEC: 🔒
ATT&CK: 🔒
Physical: No
Local: No
Remote: Partially
Availability: 🔒
Status: Not defined
Price Prediction: 🔍
Current Price Estimation: 🔒
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: no mitigation knownStatus: 🔍
0-Day Time: 🔒
Timeline
08/25/2026 CVE reserved10/21/2026 Advisory disclosed
10/21/2026 VulDB entry created
10/21/2026 VulDB entry last update
Sources
Advisory: github.comStatus: Confirmed
CVE: CVE-2026-79976 (🔒)
GCVE (CVE): GCVE-0-2026-79976
GCVE (VulDB): GCVE-100-424971
Entry
Created: 10/21/2026 21:02Changes: 10/21/2026 21:02 (66)
Complete: 🔍
Cache ID: 216::103
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
No comments yet. Languages: en.
Please log in to comment.