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.