Evidence used
- No CISA KEV confirmation is currently recorded.
- Exploitation requires an existing local or physical foothold with privileges.
- EPSS is 0.24% for the current model date.
BlackTreeCVE IntelligenceLinux · Linux
High technical severity; prioritise exposed affected systems while verifying vendor guidance.
Debian findings are scoped to the named distribution, release and source package. An absent finding does not mean a package is unaffected.
A published vendor fix does not prove that a matching update is enabled and installable on a particular asset. Confirm the local package candidate before scheduling remediation.
| Distribution release | Source package | Vendor state | Fixed version | Evidence |
|---|---|---|---|---|
| Debian trixietrixie · source | linux | Vendor fix publishedDebian records a fixed source-package version for this release. | 6.7.9-1 | Debian Security Tracker ↗Source updated 6 Oct 2026 |
| Debian bookwormbookworm · source | linux | Vendor fix publishedDebian records a fixed source-package version for this release. | 6.1.140-1 | Debian Security Tracker ↗Source updated 6 Oct 2026 |
| Debian forkyforky · source | linux | Vendor fix publishedDebian records a fixed source-package version for this release. | 6.7.9-1 | Debian Security Tracker ↗Source updated 6 Oct 2026 |
| Debian sidsid · source | linux | Vendor fix publishedDebian records a fixed source-package version for this release. | 6.7.9-1 | Debian Security Tracker ↗Source updated 6 Oct 2026 |
High technical severity; prioritise exposed affected systems while verifying vendor guidance.
Patch availableIn the Linux kernel, the following vulnerability has been resolved: Both cadence-quadspi ->runtime_suspend() and ->runtime_resume() implementations start with: struct cqspi_st *cqspi = dev_get_drvdata(dev); struct spi_controller *host = dev_get_drvdata(dev); This obviously cannot be correct, unless "struct cqspi_st" is the first member of " struct spi_controller", or the other way around, but it is not the case. "struct spi_controller" is allocated by devm_spi_alloc_host(), which allocates an extra amount of memory for private data, used to store "struct cqspi_st". The ->probe() function of the cadence-quadspi driver then sets the device drvdata to store the address of the "struct cqspi_st" structure. Therefore: struct cqspi_st *cqspi = dev_get_drvdata(dev); is correct, but: struct spi_controller *host = dev_get_drvdata(dev); is not, as it makes "host" point not to a "struct spi_controller" but to the same "struct cqspi_st" structure as above. This obviously leads to bad things (memory corruption, kernel crashes) directly during ->probe(), as ->probe() enables the device using PM runtime, leading the ->runtime_resume() hook being called, which in turns calls spi_controller_resume() with the wrong pointer. This has at least been reported [0] to cause a kernel crash, but the exact behavior will depend on the memory contents. [0] https://lore.kernel.org/all/20240226121803.5a7r5wkpbbowcxgx@dhruva/ This issue potentially affects all platforms that are currently using the cadence-quadspi driver.
In the Linux kernel, the following vulnerability has been resolved: Both cadence-quadspi ->runtime_suspend() and ->runtime_resume() implementations start with: struct cqspi_st *cqspi = dev_get_drvdata(dev); struct spi_controller *host = dev_get_drvdata(dev); This obviously cannot be correct, unless "struct cqspi_st" is the first member of " struct spi_controller", or the other way around, but it is not the case. "struct spi_controller" is allocated by devm_spi_alloc_host(), which allocates an extra amount of memory for private data, used to store "struct cqspi_st". The ->probe() function of the cadence-quadspi driver then sets the device drvdata to store the address of the "struct cqspi_st" structure. Therefore: struct cqspi_st *cqspi = dev_get_drvdata(dev); is correct, but: struct spi_controller *host = dev_get_drvdata(dev); is not, as it makes "host" point not to a "struct spi_controller" but to the same "struct cqspi_st" structure as above. This obviously leads to bad things (memory corruption, kernel crashes) directly during ->probe(), as ->probe() enables the device using PM runtime, leading the ->runtime_resume() hook being called, which in turns calls spi_controller_resume() with the wrong pointer. This has at least been reported [0] to cause a kernel crash, but the exact behavior will depend on the memory contents. [0] https://lore.kernel.org/all/20240226121803.5a7r5wkpbbowcxgx@dhruva/ This issue potentially affects all platforms that are currently using the cadence-quadspi driver.
A bounds error lets data be written beyond the intended memory region, potentially corrupting control data.
An attacker operating through local access may attempt exploitation with low privileges. If successful, the issue may disrupt the affected service.
In the Linux kernel, the following vulnerability has been resolved: Both cadence-quadspi ->runtime_suspend() and ->runtime_resume() implementations start with: struct cqspi_st *cqspi = dev_get_drvdata(dev); struct spi_controller *host = dev_get_drvdata(dev); This obviously cannot be correct, unless "struct cqspi_st" is the first member of " struct spi_controller", or the other way around, but it is not the case. "struct spi_controller" is allocated by devm_spi_alloc_host(), which allocates an extra amount of memory for private data, used to store "struct cqspi_st". The ->probe() function of the cadence-quadspi driver then sets the device drvdata to store the address of the "struct cqspi_st" structure. Therefore: struct cqspi_st *cqspi = dev_get_drvdata(dev); is correct, but: struct spi_controller *host = dev_get_drvdata(dev); is not, as it makes "host" point not to a "struct spi_controller" but to the same "struct cqspi_st" structure as above. This obviously leads to bad things (memory corruption, kernel crashes) directly during ->probe(), as ->probe() enables the device using PM runtime, leading the ->runtime_resume() hook being called, which in turns calls spi_controller_resume() with the wrong pointer. This has at least been reported [0] to cause a kernel crash, but the exact behavior will depend on the memory contents. [0] https://lore.kernel.org/all/20240226121803.5a7r5wkpbbowcxgx@dhruva/ This issue potentially affects all platforms that are currently using the cadence-quadspi driver.
A bounds error lets data be written beyond the intended memory region, potentially corrupting control data.
An attacker operating through local access may attempt exploitation with low privileges. If successful, the issue may disrupt the affected service.
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
No exploit-tagged reference or CISA SSVC proof-of-concept state is currently recorded. Research may still exist outside the structured feeds.
CWE-787: Out-of-bounds Write. The product writes data past the end, or before the beginning, of the intended buffer.
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCommon Vulnerability Scoring System 3.1: the compact vector below is decoded into plain language.
Operational remediation based on structured source evidence.
Published 4 Apr 2024 · Last source change 5 Aug 2026, 11:27 UTC · CWE-787 · Out-of-bounds Write
Core structured fields are present and their contributing authorities are shown above.
No material field changes have been recorded since change tracking began. Routine source refreshes and cosmetic edits are intentionally excluded.