CVE-2026-98207: mmc: spi: reset bytes_xfered before retrying CRC failures
In the Linux kernel, the following vulnerability has been resolved:
mmc: spi: reset bytesxfered before retrying CRC failures
mmcspidatado() updates data->bytesxfered after each block has been transferred successfully. If a later block in the same data request fails with a CRC error, data->bytesxfered may therefore contain the number of bytes completed before the failing block.
mmcspirequest() has a private recovery path for such CRC failures. It sends STOPTRANSMISSION, clears data->error and jumps back to crcrecover to issue the same command and data request again. However, it does not clear data->bytesxfered before the retry.
If the retry succeeds, the request is completed with the bytes from the failed attempt still included in data->bytesxfered. For a multi-block request this can make the completed request report more bytes than were transferred by the successful retry, and can even exceed the request size when most blocks completed before the CRC error.
This is most likely to be observed on MMC-over-SPI systems where long multi-block transfers occasionally hit a data CRC error but the mmcspi-internal retry succeeds. The data itself is retried, but the completion accounting is not.
Clear data->bytesxfered together with data->error before repeating the request so the final completion reports only the bytes transferred by the successful attempt.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the mmc_spi CRC-recovery retry path, clear data->bytes_xfered together with data->error before repeating the data request, so completion accounting reflects only the successful retry.
Event History
Frequently Asked Questions
Which systems are most likely to encounter this issue?
Systems using MMC-over-SPI are affected in the described scenario, particularly when long multi-block transfers experience an intermittent data CRC error and the driver's internal retry succeeds.
What conditions are required for the incorrect transfer count to occur?
A multi-block data request must successfully transfer one or more blocks, then encounter a CRC error on a later block. The MMC SPI driver's retry must then succeed without resetting the prior bytes_xfered count.
What is the practical effect of the flaw?
The retried request can report more bytes transferred than were transferred during the successful retry. In some cases, the reported count can exceed the request size, although the data itself is retried.