The patch for CVE-2026-64502 fixes a heap corruption in the ad_sigma_delta IIO ADC driver, but understanding what it actually fixes — and what it doesn't — requires looking past the CVE description.
The vulnerability stems from ad_sigma_delta_clear_pending_event() attempting to drain pending events across fundamentally different hardware architectures. When a registerless ADC is configured without the rdy_gpiod interrupt line and without register support (has_registers = false), the code attempted a drain operation that ultimately called memset() with SIZE_MAX — a heap corruption vector that, while dramatic, is less dangerous than the alternative failure mode.
The real blast radius is silent data stream corruption. The original code could consume and discard valid ADC data while attempting to clear a pending event that the hardware never actually generated in the registerless configuration. Downstream consumers — thermal management, battery monitoring, industrial sensors — would receive corrupted readings with no indication the driver was at fault. That's an operational integrity failure that CVSS doesn't capture.
The fix adds an early return when neither rdy_gpiod nor has_registers is set, based on the assumption that current registerless devices either reset via CS deassertion or naturally cycle the ~DRDY line at the output data rate. This is correct for existing hardware but embeds a behavioral assumption in driver logic that the subsystem provides no mechanism to verify or enforce. The patch comment explicitly acknowledges that a future registerless device holding ~DRDY asserted until data is read would break — that's not a TODO, that's architectural debt with a due date.
The secondary fix (explicit data_read_len == 0 guard) is architecturally cleaner because it handles the failure case explicitly rather than assuming specific device behavior, but it's a band-aid on the rdy_gpiod path rather than a structural hardening.
For defenders: verify your kernel version includes this fix if you use ADI Sigma-Delta ADCs (AD717x, AD7177-2, AD7915, AD7923, and similar variants). Monitor IIO buffer data for unexpected discontinuities or stuck values that don't correlate with physical inputs — that's the silent corruption footprint. The heap corruption is theoretically severe but practically contained by SLUB allocation patterns; the data integrity issue is the one that will quietly propagate through your system.
The deeper concern isn't this specific bug — it's that the IIO subsystem provides no capability-based mechanism for drivers to express what they don't need. This class of implicit assumption will reproduce in future drivers with different failure modes.