{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-98207 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-98207 is a vulnerability in Linux, published on 6 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-98207 and fix it if it is affected.\n\nWhat it is: CVE-2026-98207 is a vulnerability in Linux, published on 6 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-98207 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-98207/ (Markdown: https://insights.sbomify.com/CVE-2026-98207/index.md)","id":"CVE-2026-98207","markdown":"https://insights.sbomify.com/CVE-2026-98207/index.md","name":"CVE-2026-98207","record":{"aliases":["AZL-106002","BELL-CVE-2026-98207","DEBIAN-CVE-2026-98207","GHSA-gx8r-25rx-rh7g","UBUNTU-CVE-2026-98207"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["data_read"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel MMC driver","requires_auth":"none","summary":"A flaw in the Linux kernel MMC SPI driver allows attackers to read stale data from previous failed transfers due to incorrect byte counting during CRC error retries.","user_interaction":"not_required","vuln_class":"information_disclosure"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmmc: spi: reset bytes_xfered before retrying CRC failures\n\nmmc_spi_data_do() updates data-\u003ebytes_xfered after each block has been\ntransferred successfully.  If a later block in the same data request\nfails with a CRC error, data-\u003ebytes_xfered may therefore contain the\nnumber of bytes completed before the failing block.\n\nmmc_spi_request() has a private recovery path for such CRC failures.  It\nsends STOP_TRANSMISSION, clears data-\u003eerror and jumps back to\ncrc_recover to issue the same command and data request again.  However,\nit does not clear data-\u003ebytes_xfered before the retry.\n\nIf the retry succeeds, the request is completed with the bytes from the\nfailed attempt still included in data-\u003ebytes_xfered.  For a multi-block\nrequest this can make the completed request report more bytes than were\ntransferred by the successful retry, and can even exceed the request size\nwhen most blocks completed before the CRC error.\n\nThis is most likely to be observed on MMC-over-SPI systems where long\nmulti-block transfers occasionally hit a data CRC error but the\nmmc_spi-internal retry succeeds.  The data itself is retried, but the\ncompletion accounting is not.\n\nClear data-\u003ebytes_xfered together with data-\u003eerror before repeating the\nrequest so the final completion reports only the bytes transferred by the\nsuccessful attempt.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"mmc: spi: reset bytes_xfered before retrying CRC failures","id":"CVE-2026-98207","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"information_disclosure","year":"2026"},"n_packages":0,"n_references":8,"next":{"headline":"mmc: sdio_uart: fix xmit_fifo leak when the port table is full","id":"CVE-2026-98208"},"packages":[],"prev":{"headline":"Input: cyttsp5 - clamp the HID report size before memcpy","id":"CVE-2026-98206"},"products":["Linux"],"published":"2026-10-06","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-19","vendors":["Linux"]},"summary":"A flaw in the Linux kernel MMC SPI driver allows attackers to read stale data from previous failed transfers due to incorrect byte counting during CRC error retries.","url":"https://insights.sbomify.com/CVE-2026-98207/"}