Vulnerabilidad en kernel de Linux (CVE-2024-26628)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Reparar advertencia de dependencia de bloqueo =============================== ======================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.5.0-kfd-fkuehlin #276 No contaminado -------- ---------------------------------------------- ktrabajador/8: 2/2676 está intentando adquirir el bloqueo: ffff9435aae95c88 ((work_completion)(&svm_bo->eviction_work)){+.+.}-{0:0}, en: __flush_work+0x52/0x550 pero la tarea ya mantiene el bloqueo: ffff9435cd8e1720 ( &svms->lock){+.+.}-{3:3}, en: svm_range_deferred_list_work+0xe8/0x340 [amdgpu] cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #2 (&svms->lock){+.+.}-{3:3}: __mutex_lock+0x97/0xd30 kfd_ioctl_alloc_memory_of_gpu+0x6d/0x3c0 [amdgpu] kfd_ioctl+0x1b2 /0x5d0 [amdgpu] __x64_sys_ioctl+0x86/0xc0 do_syscall_64+0x39/0x80 Entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #1 (&mm->mmap_lock){++++}-{3:3}: down_read+0x42/0x160 svm_range_evi ct_svm_bo_worker+ 0x8b/0x340 [amdgpu] proceso_one_work+0x27a/0x540 trabajador_thread+0x53/0x3e0 kthread+0xeb/0x120 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 -> #0 ((work_completion)(&svm_bo->eviction_work) ){+.+ .}-{0:0}: __lock_acquire+0x1426/0x2200 lock_acquire+0xc1/0x2b0 __flush_work+0x80/0x550 __cancel_work_timer+0x109/0x190 svm_range_bo_release+0xdc/0x1c0 [amdgpu] svm_range_free+0x175 /0x180 [amdgpu] svm_range_deferred_list_work+0x15d/0x340 [amdgpu] Process_one_work+0x27a/0x540 trabajador_thread+0x53/0x3e0 kthread+0xeb/0x120 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 otra información que podría ayudarnos a depurar esto: Existe cadena de: (work_completion)(&svm_bo->eviction_work) --> &mm->mmap_lock --> &svms->lock Posible escenario de bloqueo inseguro: CPU0 CPU1 ---- ---- lock(&svms->lock); bloquear(&mm->mmap_lock); bloquear(&svms->bloquear); lock((work_completion)(&svm_bo->eviction_work)); Creo que esto realmente no puede llevar a un punto muerto en la práctica, porque svm_range_evict_svm_bo_worker solo toma mmap_read_lock si el recuento de BO no es 0. Eso significa que es imposible que svm_range_bo_release se esté ejecutando al mismo tiempo. Sin embargo, no existe una buena forma de anotar esto. Para evitar el problema, tome una referencia de BO en svm_range_schedule_evict_svm_bo en lugar de en el trabajador. De esa manera, es imposible que un BO sea liberado mientras el trabajo de desalojo está pendiente y la llamada cancel_work_sync en svm_range_bo_release puede eliminarse. v2: Use svm_bo_ref_unless_zero y explicó por qué es seguro. También se eliminaron las comprobaciones redundantes que ya se realizan en amdkfd_fence_enable_signaling.