CVE-2026-15923 in Zephyr
Summary
by MITRE • 09/14/2026
The Zephyr SDIO subsystem function sdio_io_rw_extended_helper() in subsys/sd/sdio.c finishes transfers with a byte-I/O loop that uses size = MIN(remaining, func->cis.max_blk_size) as the per-iteration step. The value func->cis.max_blk_size is decoded directly from the SDIO card's CIS FUNCE tuple in sdio_decode_cis() and is not validated. When a card reports a maximum block size of zero, size is always 0, remaining never decreases, and the loop spins forever.
The loop is reached from the public SDIO client API used by drivers, including sdio_read_fifo(), sdio_write_fifo(), and the incrementing register read/write helpers, each of which enters the loop while holding the per-card mutex func->card->lock. A card advertising max_blk_size == 0 therefore hangs the calling thread permanently on its first non-block-aligned transfer and never releases the mutex, denying service to the SDIO peripheral (and any subsystem such as Wi-Fi that depends on it) until the device is reset.
The malicious value must come from the SDIO card itself, so the defect is exploitable where a removable SDIO/combo card slot lets an attacker insert a crafted or malfunctioning card (a physical attack vector); on boards with a soldered SDIO peripheral it is not attacker-influenceable. There is no memory-safety, confidentiality, or integrity impact — only a permanent availability loss. The fix returns -EIO when func->cis.max_blk_size is zero, before the loop is entered.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/14/2026
The Zephyr SDIO subsystem contains a critical logic flaw within the sdio_io_rw_extended_helper function located in subsys/sd/sdio.c that leads to an infinite execution loop under specific hardware conditions. This vulnerability arises from insufficient validation of data received directly from external hardware components, specifically the Configuration Information System (CIS) tuples associated with SDIO cards. During the initialization phase, the sdio_decode_cis() function parses these tuples and populates the func->cis.max_blk_size field without performing any sanity checks on the retrieved values. Consequently, if an attached SDIO card reports a maximum block size of zero due to being maliciously crafted or malfunctioning, this invalid value is propagated into the transfer logic without triggering an error condition.
The operational impact manifests when drivers invoke public API functions such as sdio_read_fifo(), sdio_write_fifo(), or incrementing register read/write helpers. These functions rely on sdio_io_rw_extended_helper to manage data transfers and enter a loop that calculates the per-iteration step size using the formula MIN(remaining, func->cis.max_blk_size). When max_blk_size is zero, this calculation results in a step size of zero for every iteration. Since the remaining byte count never decreases, the loop condition remains true indefinitely, causing the thread to spin forever. This behavior creates a permanent denial-of-service scenario where the calling thread becomes unresponsive and fails to return control to the scheduler or application logic.
From a security architecture perspective, this vulnerability is classified under CWE-20 Improper Input Validation because the system accepts input from an external source without verifying its validity against expected constraints. The lack of bounds checking on hardware-reported parameters allows for exploitation through physical access vectors. Specifically, in systems equipped with removable SDIO or combo card slots, an attacker can insert a specially crafted or defective card to trigger this condition. On embedded boards where the SDIO peripheral is soldered directly to the motherboard and not user-replaceable, this specific attack vector is mitigated by hardware design, although general robustness against faulty components remains beneficial for system reliability.
The consequences of this flaw extend beyond simple thread suspension due to concurrency control mechanisms inherent in the driver implementation. The infinite loop occurs while holding the per-card mutex func->card->lock. Because the lock is never released during the spin, any other subsystem or driver attempting to access the same SDIO peripheral will block indefinitely waiting for the mutex. This cascading effect can deny service not only to the immediate caller but also to dependent services such as Wi-Fi stacks that rely on the underlying SDIO interface for communication with wireless controllers. The result is a complete loss of availability for any functionality tied to that specific hardware resource until a system reset or power cycle occurs, which clears the locked state and resets the peripheral configuration.
This vulnerability does not involve memory safety violations such as buffer overflows, nor does it compromise data confidentiality or integrity. The primary impact is strictly related to service availability. There are no opportunities for privilege escalation or remote code execution derived from this specific logic error. However, the persistent blocking of system resources makes it a significant concern for real-time operating systems like Zephyr where predictable timing and resource availability are critical for correct operation.
To mitigate this vulnerability, developers must implement strict validation checks on values decoded from hardware CIS tuples before they are used in control flow decisions or arithmetic operations within transfer loops. The recommended fix involves checking if func->cis.max_blk_size is zero immediately after decoding the CIS data and returning an error code such as -EIO to abort the operation gracefully rather than proceeding into a loop with invalid parameters. This ensures that malformed hardware responses result in immediate failure reporting instead of indefinite resource consumption, preserving system stability and allowing higher-level software to handle the fault appropriately without hanging critical threads or locking shared mutexes indefinitely.