CVE-2024-53169

In the Linux kernel, the following vulnerability has been resolved: nvme-fabrics: fix kernel crash while shutting down controller The nvme keep-alive operation, which executes at a periodic interval, could potentially sneak in while shutting down a fabric controller. This may lead to a race between the fabric controller admin queue destroy code path (invoked while shutting down controller) and hw/hctx queue dispatcher called from the nvme keep-alive async request queuing operation. This race could lead to the kernel crash shown below: Call Trace: autoremove_wake_function+0x0/0xbc (unreliable) __blk_mq_sched_dispatch_requests+0x114/0x24c blk_mq_sched_dispatch_requests+0x44/0x84 blk_mq_run_hw_queue+0x140/0x220 nvme_keep_alive_work+0xc8/0x19c [nvme_core] process_one_work+0x200/0x4e0 worker_thread+0x340/0x504 kthread+0x138/0x140 start_kernel_thread+0x14/0x18 While shutting down fabric controller, if nvme keep-alive request sneaks in then it would be flushed off. The nvme_keep_alive_end_io function is then invoked to handle the end of the keep-alive operation which decrements the admin->q_usage_counter and assuming this is the last/only request in the admin queue then the admin->q_usage_counter becomes zero. If that happens then blk-mq destroy queue operation (blk_mq_destroy_ queue()) which could be potentially running simultaneously on another cpu (as this is the controller shutdown code path) would forward progress and deletes the admin queue. So, now from this point onward we are not supposed to access the admin queue resources. However the issue here's that the nvme keep-alive thread running hw/hctx queue dispatch operation hasn't yet finished its work and so it could still potentially access the admin queue resource while the admin queue had been already deleted and that causes the above crash. The above kernel crash is regression caused due to changes implemented in commit a54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()"). Ideally we should stop keep-alive before destroyin g the admin queue and freeing the admin tagset so that it wouldn't sneak in during the shutdown operation. However we removed the keep alive stop operation from the beginning of the controller shutdown code path in commit a54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()") and added it under nvme_uninit_ctrl() which executes very late in the shutdown code path after the admin queue is destroyed and its tagset is removed. So this change created the possibility of keep-alive sneaking in and interfering with the shutdown operation and causing observed kernel crash. To fix the observed crash, we decided to move nvme_stop_keep_alive() from nvme_uninit_ctrl() to nvme_remove_admin_tag_set(). This change would ensure that we don't forward progress and delete the admin queue until the keep- alive operation is finished (if it's in-flight) or cancelled and that would help contain the race condition explained above and hence avoid the crash. Moving nvme_stop_keep_alive() to nvme_remove_admin_tag_set() instead of adding nvme_stop_keep_alive() to the beginning of the controller shutdown code path in nvme_stop_ctrl(), as was the case earlier before commit a54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()"), would help save one callsite of nvme_stop_keep_alive().
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:6.11:-:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.11:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.11:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.11:rc7:*:*:*:*:*:*

History

19 Sep 2025, 17:16

Type Values Removed Values Added
CPE cpe:2.3:o:linux:linux_kernel:6.11:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.11:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.11:rc7:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.11:-:*:*:*:*:*:*
CWE NVD-CWE-noinfo
First Time Linux
Linux linux Kernel
References () https://git.kernel.org/stable/c/30794f4952decb2ec8efa42f704cac5304499a41 - () https://git.kernel.org/stable/c/30794f4952decb2ec8efa42f704cac5304499a41 - Patch
References () https://git.kernel.org/stable/c/5416b76a8156c1b8491f78f8a728f422104bb919 - () https://git.kernel.org/stable/c/5416b76a8156c1b8491f78f8a728f422104bb919 - Patch
References () https://git.kernel.org/stable/c/e9869c85c81168a1275f909d5972a3fc435304be - () https://git.kernel.org/stable/c/e9869c85c81168a1275f909d5972a3fc435304be - Patch
CVSS v2 : unknown
v3 : unknown
v2 : unknown
v3 : 4.7
Summary
  • (es) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-fabrics: se corrige el fallo del kernel al apagar el controlador La operación de mantenimiento de conexión de nvme, que se ejecuta a intervalos periódicos, podría colarse mientras se apaga un controlador de red. Esto puede provocar una ejecución entre la ruta del código de destrucción de la cola de administración del controlador de red (invocada mientras se apaga el controlador) y el despachador de cola hw/hctx llamado desde la operación de puesta en cola de solicitudes asincrónicas de mantenimiento de conexión de nvme. Esta ejecución podría provocar el bloqueo del kernel que se muestra a continuación: Rastreo de llamada: autoremove_wake_function+0x0/0xbc (no confiable) __blk_mq_sched_dispatch_requests+0x114/0x24c blk_mq_sched_dispatch_requests+0x44/0x84 blk_mq_run_hw_queue+0x140/0x220 nvme_keep_alive_work+0xc8/0x19c [nvme_core] process_one_work+0x200/0x4e0 worker_thread+0x340/0x504 kthread+0x138/0x140 start_kernel_thread+0x14/0x18 Al apagar el controlador de estructura, si la solicitud de mantenimiento de conexión de nvme se cuela, se eliminará. Luego se invoca la función nvme_keep_alive_end_io para gestionar el final de la operación keep-alive que disminuye el admin->q_usage_counter y, asumiendo que esta es la última/única solicitud en la cola de administración, entonces el admin->q_usage_counter se convierte en cero. Si eso sucede, entonces la operación de destrucción de cola blk-mq (blk_mq_destroy_queue()) que podría estar ejecutándose simultáneamente en otra CPU (ya que esta es la ruta del código de apagado del controlador) reenviaría el progreso y eliminaría la cola de administración. Entonces, ahora a partir de este punto en adelante no se supone que accedamos a los recursos de la cola de administración. Sin embargo, el problema aquí es que el hilo de keep-alive de nvme que ejecuta la operación de despacho de cola hw/hctx aún no ha terminado su trabajo y, por lo tanto, aún podría acceder potencialmente al recurso de la cola de administración mientras que la cola de administración ya se había eliminado y eso causa el bloqueo anterior. El fallo del kernel anterior es una regresión causada por los cambios implementados en el commit a54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()"). Lo ideal sería detener el keep-alive antes de destruir la cola de administración y liberar el conjunto de etiquetas de administración para que no se introduzca durante la operación de apagado. Sin embargo, eliminamos la operación de detención de keep-alive del comienzo de la ruta del código de apagado del controlador en el commit a54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()") y la agregamos bajo nvme_uninit_ctrl() que se ejecuta muy tarde en la ruta del código de apagado después de que se destruye la cola de administración y se elimina su conjunto de etiquetas. Por lo tanto, este cambio creó la posibilidad de que el keep-alive se introduzca e interfiera con la operación de apagado y cause el fallo del kernel observado. Para solucionar el fallo observado, decidimos mover nvme_stop_keep_alive() de nvme_uninit_ctrl() a nvme_remove_admin_tag_set(). Este cambio garantizaría que no avancemos el progreso ni eliminemos la cola de administración hasta que la operación de mantenimiento de la actividad finalice (si está en curso) o se cancele, y eso ayudaría a contener la condición de ejecución explicada anteriormente y, por lo tanto, evitar el fallo. Mover nvme_stop_keep_alive() a nvme_remove_admin_tag_set() en lugar de agregar nvme_stop_keep_alive() al comienzo de la ruta del código de apagado del controlador en nvme_stop_ctrl(), como era el caso antes de el commit a54a93d0e359 ("nvme: mover la operación de mantenimiento de la actividad de detención a nvme_uninit_ctrl()"), ayudaría a ahorrar un sitio de llamada de nvme_stop_keep_alive().

27 Dec 2024, 14:15

Type Values Removed Values Added
New CVE

Information

Published : 2024-12-27 14:15

Updated : 2025-10-01 21:16


NVD link : CVE-2024-53169

Mitre link : CVE-2024-53169

CVE.ORG link : CVE-2024-53169


JSON object : View

Products Affected

linux

  • linux_kernel