Dan Moulding

**Nome do software vulnerável e versões afetadas** Versões do kernel Linux anteriores à 6.6.37 **Descrição** O problema está relacionado a um impasse na função `raid5d()`, o que pode causar o travamento do sistema. Isso se deve a uma dependência anômala na implementação atual de `raid5d()`: 1. `md check recovery()` de `raid5d()` deve manter `reconfig mutex` para limpar `MD SB CHANGE PENDING`; 2. `raid5d()` lida com E/S em um loop infinito, até que todas as E/S sejam emitidas; 3. As E/S de `raid5d()` devem aguardar até que `MD SB CHANGE PENDING` seja limpo. Esse comportamento foi introduzido antes da versão 2.6 e, como consequência, se outro contexto mantiver `reconfig mutex` e `md check recovery()` não puder atualizar `super block`, então `raid5d()` desperdiçará um CPU a 100% devido ao loop infinito, até que `reconfig mutex` seja liberado. **Recomendações** Para resolver o problema, atualize o kernel do Linux para a versão 6.6.37 ou posterior. Como solução alternativa temporária, considere desativar a função `raid5d()` até que um patch esteja disponível. Restrinja o acesso ao módulo vulnerável para minimizar o risco de exploração. Evite usar a função `md check recovery()` no endpoint da API afetado até que o problema seja resolvido. Aplique a correção ignorando a E/S do problema se `MD SB CHANGE PENDING` ainda estiver definido após `md check recovery()`, permitindo que a thread do daemon seja ativada quando `reconfig mutex` for liberado.