CVE-2024-39476

In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"") However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d(). Current implementation in raid5d() has a weird dependence: 1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared; This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfig_mutex', and md_check_recovery() can't update super_block, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfig_mutex' is released. Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MD_SB_CHANGE_PENDING is still set after md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex' is released. Meanwhile, the hang problem will be fixed as well.
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*

History

08 Jul 2024, 17:11

Type Values Removed Values Added
CWE CWE-667
First Time Linux
Linux linux Kernel
CVSS v2 : unknown
v3 : unknown
v2 : unknown
v3 : 5.5
CPE cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
References () https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a - () https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a - Mailing List, Patch
References () https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa - () https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa - Mailing List, Patch
References () https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b - () https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b - Mailing List, Patch
References () https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4 - () https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4 - Mailing List, Patch
References () https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787 - () https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787 - Mailing List, Patch
References () https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347 - () https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347 - Mailing List, Patch
References () https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447 - () https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447 - Mailing List, Patch
References () https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7 - () https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7 - Mailing List, Patch

05 Jul 2024, 12:55

Type Values Removed Values Added
Summary
  • (es) 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á.

05 Jul 2024, 07:15

Type Values Removed Values Added
New CVE

Information

Published : 2024-07-05 07:15

Updated : 2024-07-08 17:11


NVD link : CVE-2024-39476

Mitre link : CVE-2024-39476

CVE.ORG link : CVE-2024-39476


JSON object : View

Products Affected

linux

  • linux_kernel
CWE
CWE-667

Improper Locking