No kernel Linux, a seguinte vulnerabilidade foi resolvida. rqspinlock: Reinicializar cauda ao preservar a fila no impasse Atualmente, a destruição da fila de garçom é suprimida para rqspinlock nos casos em que um bloqueio é detectado. Verificações de bloqueio ocorrem relativamente frequentemente (na entrada para AA, dentro 1 ms para ABBA), e os threads do garçom podem não estar envolvidos em cenários de bloqueio envolvendo bloqueios. Assim, é útil não soltar a fila e deixar que outros garçons apunhalem a aquisição da fechadura depois de detectarmos um bloqueio e sair. No entanto, precisamos seguir a mesma lógica que fizemos anteriormente para a etiqueta waitq_timeout: reiniciar a cauda, e se não pudermos, sinalizar o próximo garçom de forma adequada. Em caso de impasse, este sinal marcaria o nó MCS como desbloqueado, e em caso de desbloqueio, ele sinalizaria RES_ TEMEPOUT_VAL. A diferença é assim no valor propagado, que decide se a fila permanece ativa ou se é vazada.
Não fazendo a reiniciação da cauda, e esperando pelo próximo garçom pode levar a casos onde somos o garçom final, e assim nenhum próximo garçom chega, levando a paradas intermitentes neste caminho. Uma vez que o próximo garçom se juntar, nós seremos desbloqueados. No caso teórico, quando o próximo garçom nunca se junta, corremos o risco de parar indefinidamente. Isto só pode acontecer para bloqueios do ABBA, uma vez que a entrada na fila de espera é guardada com cheques AA. Uma sequência precisa de execuções que conduzam a este cenário pode ser:.
CPU 0 mantém o bloqueio A. CPU 1 mantém fechada B. CPU 2 Tentativas bloqueio B, torna- se o garçom pendente para B. CPU 0 Tentativas bloquear B. B tem bloqueado + bits pendentes definidos, assim CPU 0 filas. CPU 1 Tentativas bloquear A. CPU 0 detecta um bloqueio ABBA. Uma vez que a detecção do bloqueio ocorre para a CPU 0, ele ficará esperando o próximo garçom na fila para povoar o nó- > próximo, que irá experimentar atrasos até que esse garçom chegue.
Corrija isso ajustando a lógica para a verificação de bloqueios anteriores à etiqueta waitq_timeout. Faria sentido consolidar o código para ambos os casos e usar 'ret' para distinguir o valor que está sendo propagado, mas isso é deixado como um exercício para uma tarefa de refactoring futura para evitar o ruído de diff neste patch. Registro de aconselhamento: GHSA- fm 7 x- 6 qpm- 975 r. Identificadores relacionados: CVE- 2026 - 74686.
Tempo: GitHub Advisory Database publicou este registro em 2026 - 08 - 22 T 18: 30: 29.000 Z e lista a sua última modificação como 2026 - 08 - 22 T 18: 30: 29.000 Z. Severidade: não classificado. Nenhum vetor de pontuação está listado no registro.
Software afetado: o registro de aconselhamento não fornece um pacote normalizado ou faixa de versões. Classificação e evidência: nenhum identificador CWE está listado. O registro contém 3 suporte de referências nestes tipos: AVISO, WEB.