CVE-2026-64501

This CVE reveals a subtle but serious flaw in the ad_sigma_delta SPI driver abstraction: chip-select state, bus-lock ownership, and device mode are maintained as independent variables when they should be treated as a unified protocol state. Two distinct bugs share this root cause. In the first, the cleanup sequence calls `set_mode(AD_SD_MODE_IDLE)` and `disable_one()` while `keep_cs_asserted` is still true. This causes those SPI transfers to carry `cs_change=1` behavior into a context where CS should not toggle—the transfers execute when CS should be quiescent. The fix is straightforward but easy to miss: these calls must execute after `keep_cs_asserted` is cleared. The second bug is more severe. The error path in `ad_sd_buffer_postenable()` correctly reverts mode and CS state but fails to clear the `bus_locked` flag. After an error, `spi_bus_unlock()` returns while `bus_locked` remains true. Subsequent callers then enter `spi_sync_locked()` believing the bus is serialized when it isn't—this creates a real race condition allowing concurrent SPI access. Affected drivers include AD717x, AD719x, AD7685, and others using the ad_sigma_delta abstraction. MAX11205 is unaffected because it has no physical CS pin, though note that `cs_change` still affects transfer timing even without a physical line to toggle—if MAX11205 shares a bus with a CS-using device, the abstraction's assumptions may not hold. Audit your codebase for any driver using ad_sigma_delta that implements custom set_mode or disable_one callbacks. Verify that cleanup paths clear `bus_locked` last, after all state implying bus ownership has been reverted. The three invariants—CS assertion, bus lock ownership, and device mode—must be maintained together. If your driver lacks these callbacks, confirm that no implicit CS behavior is being assumed during error recovery.

Reviewed through automated stages and approved by a human before publication.