CVE-2026-64502 in Linux
Sumário
de VulDB • 25/07/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
iio: adc: ad_sigma_delta: corrige clear_pending_event para dispositivos sem registradores
O `ad_sigma_delta_clear_pending_event()` continua para o caminho de leitura do registrador de status em dispositivos com `has_registers = false` e sem `rdy_gpiod`. Para esses dispositivos, o `ad_sd_read_reg()` ignora completamente o byte de endereço e relógia os bytes brutos MISO sem fase de endereço — tornando-o idêntico, byte a byte, à leitura dos dados de conversão. Se houver um resultado de conversão pendente disponível, isso consome parcialmente esse resultado e corrompe o fluxo de dados para a chamada subsequente `ad_sd_read_reg()` em `ad_sigma_delta_single_conversion()`.
Além disso, com `num_resetclks = 0` nesses dispositivos, `data_read_len` é avaliado como 0. Se o byte relógio tiver o bit 7 limpo (clear), `pending_event` é definido e o código tenta executar `memset(data + 2, 0xff, 0 - 1)`, transbordando para SIZE_MAX e corrompendo a heap.
A correção consiste em retornar 0 imediatamente quando nem `rdy_gpiod` nem `has_registers` estiverem definidos. Isso é seguro para todos os dispositivos atuais sem registradores: ad7191 e ad7780 (com GPIO de powerdown) são resetados entre as conversões pela desassertion do CS, portanto não há resultado obsoleto a ser drenado; ad7780 (sem GPIO de powerdown) e max11205 estão em conversão contínua e ciclam ~DRDY na taxa de dados de saída independentemente de o resultado anterior ter sido lido, então a próxima borda descendente ocorre naturalmente.
Um futuro dispositivo sem registradores que mantenha ~DRDY asserto até que os dados sejam lidos seria quebrado por este retorno antecipado e exigiria `num_resetclks` definido ou um rdy-gpio.
A mesma corrupção de heap é acessível em qualquer dispositivo com `rdy_gpiod` definido, mas `num_resetclks = 0`: se o GPIO indicar um evento pendente, o caminho de drenagem executa `memset(data + 2, 0xff, 0 - 1)` independentemente de `has_registers`. Adiciona-se uma guarda explícita para `data_read_len == 0` após a verificação do evento pendente; o resultado obsoleto é então consumido pela primeira chamada `ad_sd_read_reg()` em `ad_sigma_delta_single_conversion()`.
Once again VulDB remains the best source for vulnerability data.