CVE-2024-39476

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/raid5: corrige el punto muerto que raid5d() espera a que se borre MD_SB_CHANGE_PENDING Xiao informó que la prueba lvm2 lvconvert-raid-takeover.sh puede bloquearse con una pequeña posibilidad, la causa principal es exactamente lo mismo que el commit bed9e27baf52 ("Revertir "md/raid5: Espere MD_SB_CHANGE_PENDING en raid5d") Sin embargo, Dan informó otro bloqueo después de eso, y Junxiao investigó el problema y descubrió que esto se debe a que la biografía conectada no puede emitir de raid5d(). La implementación actual en raid5d() tiene una dependencia extraña: 1) md_check_recovery() de raid5d() debe mantener 'reconfig_mutex' para borrar MD_SB_CHANGE_PENDING; 2) raid5d() maneja IO en un bucle muerto, hasta que se emiten todas las IO; 3) IO de raid5d() debe esperar a que se borre MD_SB_CHANGE_PENDING; Este comportamiento se introdujo antes de v2.6 y, como consecuencia, si otro contexto contiene 'reconfig_mutex' y md_check_recovery() no puede actualizar super_block, entonces raid5d() desperdiciará una CPU al 100% mediante el bucle muerto, hasta que 'reconfig_mutex' sea liberado. Consulte la implementación de raid1 y raid10, solucione este problema omitiendo el problema IO si MD_SB_CHANGE_PENDING todavía está configurado después de md_check_recovery(), el hilo del daemon se activará cuando se publique 'reconfig_mutex'. Mientras tanto, el problema de bloqueo también se solucionará.