Cloudanix VulnDB

CVE-2026-98207

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A storage driver bug can make the system claim it moved more data than it actually did when certain errors occur, which may cause files or programs to become corrupted on devices that connect memory cards over a simple wiring interface.

Exploitation
Other
Attacker needs
Local User
Complexity
Theoretical
Impact
Other
Component
OS kernel
Class
Other
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

In the Linux kernel MMC SPI driver, the CRC error recovery path in mmc_spi_request() retries a multi-block transfer without resetting data->bytes_xfered, so a successful retry completes with an inflated byte count that includes data from the failed attempt and can exceed the original request size.

Why it matters to the business

Systems using MMC storage over SPI may experience incorrect transfer accounting on long multi-block operations that encounter transient CRC errors, leading to data integrity problems, filesystem errors, or application failures; the issue is rare but affects embedded and industrial devices with this interface.

How an attack unfolds

An attacker capable of inducing data CRC errors on the SPI bus during MMC transfers can trigger the driver's internal retry logic; because the byte counter is not cleared, the successful retry reports an incorrect (larger) transfer size to the block layer, potentially causing upper-layer code to act on invalid completion status.

How to fix it

Update to a Linux kernel containing the fix that clears data->bytes_xfered together with data->error before the crc_recover retry; rebuild and deploy the updated kernel on all affected MMC-over-SPI systems.

How to confirm the fix worked

Confirm the presence of the patch that resets bytes_xfered before the retry loop; exercise multi-block MMC transfers over SPI while injecting CRC errors and verify that the final request completion reports only the bytes from the successful attempt.

Typical attack path

  1. Induce or wait for a CRC error on a multi-block MMC read/write over SPI
  2. Allow the driver's private recovery path to issue STOP_TRANSMISSION and retry the request
  3. Observe the completed request returning an inflated bytes_xfered value that mixes failed and successful blocks
  4. Trigger downstream code that trusts the reported byte count, leading to data corruption or logic errors

How to detect it

Review kernel logs for MMC SPI retry messages around the time of data integrity complaints; inspect block layer completion traces for requests whose reported byte count exceeds the original request length after a CRC error.

What your security team should do

  • Prioritize kernel updates on embedded and industrial systems that use MMC-over-SPI storage
  • Monitor vendor BSP releases for the corrected MMC SPI driver
  • Add regression tests that simulate CRC errors during multi-block transfers to verify correct byte accounting

The record

In the Linux kernel, the following vulnerability has been resolved: mmc: spi: reset bytes_xfered before retrying CRC failures mmc_spi_data_do() updates data->bytes_xfered after each block has been transferred successfully. If a later block in the same data request fails with a CRC error, data->bytes_xfered may therefore contain the number of bytes completed before the failing block. mmc_spi_request() has a private recovery path for such CRC failures. It sends STOP_TRANSMISSION, clears data->error and jumps back to crc_recover to issue the same command and data request again. However, it does not clear data->bytes_xfered before the retry. If the retry succeeds, the request is completed with the bytes from the failed attempt still included in data->bytes_xfered. 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 mmc_spi-internal retry succeeds. The data itself is retried, but the completion accounting is not. Clear data->bytes_xfered together with data->error before repeating the request so the final completion reports only the bytes transferred by the successful attempt.

Affected packages

Ecosystem Package Introduced Fixed