Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.6",
  "pubDate": "2026-09-14T17:17:42.823Z",
  "pubdate": "2026-09-14T17:17:42.823Z",
  "executiveSummary": "The Zephyr SDIO subsystem is susceptible to a Denial of Service (DoS) vulnerability due to improper input validation within the sdio_io_rw_extended_helper() function.\nThe vulnerability arises when the system processes an SDIO card that reports a maximum block size (max_blk_size) of zero via its Card Information Structure (CIS).\nThis invalid value triggers an infinite loop during byte-I/O transfers, causing the thread to hang indefinitely while holding a per-card mutex.\nBecause the mutex is never released, the affected SDIO peripheral and all associated subsystems (such as Wi-Fi) become permanently unavailable until a hardware reset occurs.\nThe attack is physically exploitable on systems with removable SDIO card slots through the insertion of a malicious or malformed SDIO card.\nThis vulnerability represents a risk to system availability in environments supporting hot-pluggable hardware, though it does not provide an avenue for memory corruption, confidentiality breaches, or unauthorized integrity modification.",
  "technicalDetails": "The root cause of the vulnerability is the lack of sanity checking for the func->cis.max_blk_size attribute within the sdio_decode_cis() function. This value is parsed directly from the SDIO card's CIS FUNCE tuple. When an attacker provides a crafted device that reports a max_blk_size of 0, the logic in sdio_io_rw_extended_helper() fails to account for the zero-size boundary.\nInside sdio_io_rw_extended_helper(), the transfer logic utilizes a loop to process data using size = MIN(remaining, func->cis.max_blk_size) as the incrementing step. When max_blk_size is 0, the MIN() operation consistently results in a step size of 0. Consequently, the remaining byte count in the transfer buffer never decrements, causing the loop to execute infinitely.\nThe attack flow follows a deterministic path: 1) An attacker inserts a malicious SDIO card into the host device. 2) The Zephyr OS initializes the card and executes sdio_decode_cis(), which populates func->cis.max_blk_size with 0. 3) A user-space or kernel-space driver initiates an SDIO operation (e.g., sdio_read_fifo() or sdio_write_fifo()). 4) The driver calls sdio_io_rw_extended_helper() while holding the func->card->lock mutex. 5) The function enters the byte-I/O loop, hangs indefinitely, and fails to release the card mutex. 6) Subsequent attempts to communicate with the SDIO peripheral result in a permanent block, effectively disabling all subsystems reliant on that card.\nThe vulnerable component is identified as subsys/sd/sdio.c. The exploit requires physical access to the device if the SDIO port is exposed, though it is not exploitable on boards with permanently soldered, trusted peripherals where the CIS tuple cannot be manipulated. There are no authentication or privilege requirements to trigger the flaw, as the logic failure occurs at the driver/subsystem initialization and execution level.\nThe impact is limited exclusively to a Denial of Service. Because the affected thread is blocked on a mutex, resources protected by that lock remain inaccessible, and the calling thread cannot resume, leading to potential system instability depending on the kernel's scheduler and the critical nature of the blocked process."
}