CVE-2024-26757

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md: No ignorar la matriz de solo lectura en md_check_recovery() Generalmente, si la matriz no es de lectura y escritura, md_check_recovery() no registrará un nuevo sync_thread en primer lugar. Y si la matriz es de lectura y escritura y sync_thread está registrado, md_set_readonly() cancelará el registro de sync_thread antes de configurar la matriz como de solo lectura. md/raid sigue este comportamiento, por lo que no hay problema. Después de commit f52f5c71f3d4 ("md: arreglar la detención del hilo de sincronización"), el siguiente bloqueo puede activarse mediante test shell/integrity-caching.sh: 1) la matriz es de solo lectura. Superbloque de actualización dm-raid: rs_update_sbs ro = mddev->ro mddev->ro = 0 -> establecer matriz de lectura y escritura md_update_sb 2) registrar un nuevo hilo de sincronización simultáneamente. 3) dm-raid vuelve a configurar la matriz en solo lectura: rs_update_sbs mddev->ro = ro 4) detiene la matriz: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 5) hilo de sincronización realizado: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 6) el hilo del demonio no puede cancelar el registro del hilo de sincronización: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING no se puede borrar, por lo tanto el paso 4 se bloquea; La causa principal es que dm-raid manipula 'mddev->ro' por sí solo; sin embargo, dm-raid realmente debería detener el hilo de sincronización antes de configurar la matriz como de solo lectura. Desafortunadamente, necesito leer más código antes de poder refactorizar el controlador de 'mddev->ro' en dm-raid, por lo tanto, solucionemos el problema de la manera más fácil por ahora para evitar la regresión de dm-raid.