CVE-2026-10683 Overview
CVE-2026-10683 affects the Synopsys DesignWare I2C driver (drivers/i2c/i2c_dw.c) in the Zephyr real-time operating system (RTOS) when operating in target/slave mode. The driver fails to enable the START_DET interrupt in i2c_dw_slave_register(), leaving the state-recovery path as dead code. As a result, a lost STOP interrupt or a legal WRITE-repeated-START-WRITE sequence permanently leaves the driver in the CMD_SEND state. The target function then stops invoking write_requested() for all subsequent write transactions until a reset occurs. The flaw maps to [CWE-835] (loop with unreachable exit condition) and yields a recoverable denial of service on the local board-level I2C bus.
Critical Impact
An I2C master sharing the physical bus can deliberately desynchronize the target driver, breaking consumer framing state such as MCTP-over-I2C until the peripheral is reset.
Affected Products
- Zephyr RTOS drivers/i2c/i2c_dw.c (DesignWare I2C driver in target/slave mode)
- Downstream consumers using MCTP-over-I2C on Zephyr
- Embedded platforms integrating the Synopsys DesignWare I2C IP through Zephyr
Discovery Timeline
- 2026-07-27 - CVE-2026-10683 published to the National Vulnerability Database (NVD)
- 2026-07-27 - Last updated in NVD database
Technical Details for CVE-2026-10683
Vulnerability Analysis
The DesignWare I2C driver tracks target-mode transaction progress through the dw->state field. The rx_full interrupt handler gates the write_requested() callback on the condition dw->state != CMD_SEND. Only a STOP interrupt resets dw->state back to READY. A parallel recovery path exists inside i2c_dw_slave_read_clear_intr_bits() that would reset state on every bus (re)START, but the START_DET interrupt was never unmasked in i2c_dw_slave_register(). That recovery code therefore never runs, and the state machine has no way to leave CMD_SEND if the STOP event is missed.
Root Cause
The root cause is an incomplete interrupt-mask configuration. The write_intr_mask() call in i2c_dw_slave_register() omits DW_INTR_MASK_START_DET, so the hardware never signals repeated-START events to the handler that clears dw->state. This is a design/configuration flaw rather than a memory-safety issue.
Attack Vector
An attacker with access to the same physical I2C bus can issue a WRITE-repeated-START-WRITE sequence with the same direction, or induce a bus glitch that causes the STOP interrupt to be lost. Either path traps the target in CMD_SEND permanently. All subsequent write transactions fail to notify the upper layers, breaking framing state for consumers such as Management Component Transport Protocol (MCTP) over I2C. Impact is availability-only, recoverable by resetting the peripheral. No memory corruption occurs, because the in-tree consumer performs independent per-byte bounds checking.
// Patch: unmask START_DET so the state machine resets on every (re)START
dw->read_in_progress = false;
dw->slave_cfg = cfg;
ret = i2c_dw_set_slave_mode(dev, cfg->address);
- write_intr_mask(DW_INTR_MASK_RX_FULL | DW_INTR_MASK_RD_REQ | DW_INTR_MASK_TX_ABRT |
- DW_INTR_MASK_STOP_DET,
+ write_intr_mask(DW_INTR_MASK_RX_FULL | DW_INTR_MASK_RD_REQ |
+ DW_INTR_MASK_TX_ABRT | DW_INTR_MASK_STOP_DET |
+ DW_INTR_MASK_START_DET,
reg_base);
return ret;
Source: Zephyr commit 06e2053
Detection Methods for CVE-2026-10683
Indicators of Compromise
- I2C target device stops responding to write requests while still acknowledging address phase on the bus.
- Consumer protocols such as MCTP-over-I2C report persistent framing or sequence errors that only clear after a peripheral reset.
- Firmware logs show rx_full interrupts firing without corresponding write_requested() callback invocations.
Detection Strategies
- Instrument the I2C target driver to log transitions of dw->state and alert when the state remains in CMD_SEND across multiple transactions.
- Correlate STOP and START_DET interrupt counters against completed target transactions to detect lost bus events.
- Review board bring-up traces with a logic analyzer for WRITE-repeated-START-WRITE patterns that reproduce the hang.
Monitoring Recommendations
- Track upper-layer protocol error counters (for example, MCTP packet drops) as a proxy for target-mode desynchronization.
- Emit a watchdog event when the I2C target has not serviced a write callback within an expected interval.
- Aggregate device health telemetry centrally so repeated peripheral resets tied to bus hangs surface as an operational pattern.
How to Mitigate CVE-2026-10683
Immediate Actions Required
- Apply the upstream Zephyr fix that unmasks DW_INTR_MASK_START_DET in i2c_dw_slave_register().
- Rebuild and reflash affected firmware images that use the DesignWare I2C target driver.
- Audit board designs to confirm no untrusted device shares the I2C bus with sensitive target peripherals.
Patch Information
The fix is available in Zephyr commit 06e2053efe0e324d71cc29cdd95160fff643730a and documented in GHSA-fj9c-r5qw-3639. The patch adds DW_INTR_MASK_START_DET to the enabled interrupt mask so the existing recovery handler in i2c_dw_slave_read_clear_intr_bits() executes on every bus (re)START and resets dw->state.
Workarounds
- Implement a firmware watchdog that resets the I2C peripheral when target-mode writes stall.
- Restrict physical access to the I2C bus and validate all master devices connected to the same board segment.
- Where feasible, defer target-mode usage until the patched firmware is deployed.
# Fetch and apply the upstream patch in a Zephyr workspace
cd zephyr
git fetch origin
git cherry-pick 06e2053efe0e324d71cc29cdd95160fff643730a
west build -b <board> -p auto <app>
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
