Look up another CVE · open CVE-2026-64501 in the interactive tracker
CVE-2026-64501
iio: adc: ad_sigma_delta: fix CS held asserted and state leaks
Published 2026-07-25 (3 months ago) by the Linux kernel CNA. Subsystem drivers/iio. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-64501 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.4-1 | Update the kernel and reboot. Fixed in 7.1.4-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.4-1 | Update the kernel and reboot. Fixed in 7.1.4-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
In ad_sigma_delta_single_conversion(), set_mode(AD_SD_MODE_IDLE) and disable_one() were called from the out: block while keep_cs_asserted was still true. This caused any SPI transfer issued by those callbacks to carry cs_change=1, leaving CS permanently asserted after the conversion. Fix by moving both calls into the out_unlock: block, after keep_cs_asserted is cleared, matching the pattern already used in ad_sd_calibrate(). In the error path of ad_sd_buffer_postenable(), if an operation fails after set_mode(AD_SD_MODE_CONTINUOUS) has already succeeded (e.g. spi_offload_trigger_enable()), the device is left in continuous conversion mode with CS physically asserted. Additionally, bus_locked remaining true after spi_bus_unlock() causes subsequent SPI operations to call spi_sync_locked() without the bus lock actually held, allowing concurrent SPI access. Fix the error path by clearing keep_cs_asserted first, then calling set_mode(AD_SD_MODE_IDLE) to revert the device mode and deassert CS, then clearing bus_locked before releasing the bus. For devices that implement neither set_mode nor disable_one (such as MAX11205, which has no physical CS pin), no SPI transfer is issued during cleanup and the cs_change flag has no effect on any physical line.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/iio/adc/ad_sigma_delta.c
- What this is
- ANALOG DEVICES INC IIO DRIVERSMAINTAINERS section matched on drivers/iio/*/ad* · linux@analog.com · Supported
- Kernel module
- ad_sigma_delta
Check it on the machine
grep -wE 'CONFIG_AD_SIGMA_DELTA|CONFIG_IIO' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w ad_sigma_deltaPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- trixie, forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_AD_SIGMA_DELTA, CONFIG_IIO
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-25 (3 months ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 5.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/iio
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.14 | 6.18.39 | c313bb7c3885 |
| 6.14 | 7.1.4 | f1de829ee87a |
| 6.14 | 7.2 | c72da0688575 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- An attacker reaches the vulnerable conversion path through local reads of IIO `*_raw` sysfs attributes; physical access to the installed ADC is unnecessary.
- AC:LAttack complexity, low
- The normal single-conversion cleanup deterministically leaves CS asserted, and the attacker can repeat the trigger or interrupt their own conversion wait without winning a race.
- PR:LPrivileges required, low
- IIO raw attributes are world-readable and the path contains no capability or authentication check, so an ordinary unprivileged local user can trigger it.
- UI:NUser interaction, none
- The attacker directly reads the sysfs attribute or initiates permitted device access; no victim action is required.
- S:UScope, unchanged
- The affected ADC, SPI controller, shared-bus devices, and kernel operate under the same system security authority; this is not a sandbox or virtualization boundary escape.
- C:NConfidentiality impact, none
- The state corruption creates no kernel-memory disclosure or unauthorized read primitive; the separate heap-overflow issue in CVE-2026-64502 is not part of this CVE.
- I:HIntegrity impact, high
- With CS stuck active, attacker-influenced traffic for another shared-bus device can be consumed as commands by register-based ADCs, including writes to mode, channel, offset, and gain registers that can completely corrupt measurement integrity.
- A:HAvailability impact, high
- The persistently selected ADC can contend on MISO, consume sibling-device traffic, and leave the ADC or shared SPI bus unusable until reset or corrective access; an unprivileged attacker can repeatedly restore this condition.