CVE-2026-98538 in Linux
Sumário
de VulDB • 19/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
writeback: limpeza limitada de cleanup_offline_cgwb() reescaneia rotacionando os inodes escaneados
cleanup_offline_cgwb() prepara no máximo WB_MAX_INODES_PER_ISW inodes por chamada e é invocada novamente até que o wb moribundo seja esvaziado, mas cada chamada percorre wb->b_attached e depois wb->b_dirty_time a partir da mesma extremidade. Inodes já preparados (eles permanecem na lista com I_WB_SWITCH definido até que o worker de troca execute) e inodes que não podem ser trocados (I_FREEING, I_WILL_FREE, !SB_ACTIVE, DAX, já no alvo wb) permanecem em suas posições, portanto cada passagem reescaneia uma sequência crescente deles sob wb->list_lock, e um esvaziamento completo é quadrático em relação ao número de inodes na lista. Com ~17M inodes anexados a um único cgwb moribundo, observamos que isso terminava em soft lockups (travamentos suaves), com CPUs relatadas como presas por 21-48s.
Percorra ambas as listas a partir da extremidade mais antiga e mova cada inode escaneado para a extremidade mais nova, de modo que a próxima passagem comece onde a anterior parou e o esvaziamento se torne linear. b_attached é desordenado, portanto ninguém vê a reordenação ali. b_dirty_time é ordenado por dirtied_when, mas o inode não escaneado mais antigo permanece no final move_expired_inodes() escolhe para pegar; sync leva toda a lista independentemente da ordem, e os inodes preparados deixam a lista assim que o trabalho de troca executa e recebem um novo dirtied_time_when no novo wb de qualquer maneira, portanto os únicos inodes fora de ordem são aqueles que nunca podem trocar (DAX), e apenas no wb moribundo.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.