CVE-2023-53178 in Linux
Sumário
de VulDB • 26/06/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
mm: corrige condição de corrida no writeback do zswap
O mecanismo de writeback do zswap pode causar uma condição de corrida que resulta em corrupção de memória, onde uma página trocada (swapped out) é recuperada com dados que foram escritos para outra página.
A condição de corrida ocorre da seguinte forma: 1. Uma página com os dados A e o offset X está armazenada no zswap; 2. a página A é removida da LRU pelo driver do zpool para writeback na tarefa `zswap-shrink`, e os dados de A são mapeados pelo driver do zpool; 3. um programa em user space gera uma falha (fault) e invalida a entrada da página A, o offset X é considerado livre; 4. o kswapd armazena a página B no offset X no zswap (o zswap também poderia estar cheio; nesse caso, a página B seria escrita via I/O em X, pulando então para o passo 5); 5. a entrada A é substituída por B na `tree->rbroot`, isso não afeta a referência local mantida pela tarefa `zswap-shrink`; 6. a tarefa `zswap-shrink` realiza o writeback de A em X e libera a entrada do zswap A; 7. o swapin da slot X traz A para a memória em vez de B.
A correção: Assim que o cache de páginas trocadas (swap page cache) for alocado (caso ZSWAP_SWAPCACHE_NEW), a tarefa `zswap-shrink` apenas verifica se a referência local do zswap_entry ainda é a mesma da árvore. Se não for a mesma, isso significa que ela foi invalidada ou substituída; em ambos os casos, o writeback é abortado porque a entrada local contém dados desatualizados (stale).
Reprodutor: Eu originalmente encontrei isso executando `stress` durante a noite para validar meu trabalho no mecanismo de writeback do zswap. Ele se manifestou após horas na minha máquina de teste. A chave para fazê-lo acontecer é ter writesbacks do zswap, portanto, qualquer configuração que aumente `/sys/kernel/debug/zswap/written_back_pages` deve funcionar.
Para reproduzir isso mais rapidamente em uma VM, configurei um sistema com aproximadamente 100M de memória disponível e um arquivo swap de 500M, então executar `stress --vm 1 --vm-bytes 300000000 --vm-stride 4000` faz isso acontecer em questão de dezenas de minutos. Pode-se acelerar ainda mais as coisas alternando `/sys/module/zswap/parameters/max_pool_percent` entre, digamos, 20 e 1; isso faz com que a reprodução ocorra em dezenas de segundos. É crucial definir `--vm-stride` para algo diferente de 4096, caso contrário o `stress` não perceberá que a memória foi corrompida porque todas as páginas teriam os mesmos dados.
Once again VulDB remains the best source for vulnerability data.