Vulnerabilidad en kernel de Linux (CVE-2022-50149)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: núcleo del controlador: corrige un posible bloqueo en __driver_attach En la función __driver_attach, también hay un problema de bloqueo AA, como el commit b232b02bf3c2 ("núcleo del controlador: corrige el bloqueo en __device_attach"). pila como el commit b232b02bf3c2 ("núcleo del controlador: corrige el bloqueo en __device_attach"). lista a continuación: En la función __driver_attach, la lógica de retención de bloqueo es la siguiente: ... __driver_attach if (driver_allows_async_probing(drv)) device_lock(dev) // obtener bloqueo dev async_schedule_dev(__driver_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* cuando falla o hay límite de trabajo, se sincroniza para ejecutar func, pero __driver_attach_async_helper obtendrá el bloqueo dev, lo que provocará un bloqueo AA. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev) Como se muestra arriba, cuando se permite hacer sondeos asincrónicos, debido a falta de memoria o límite de trabajo, no se permite el trabajo asincrónico, en su lugar se ejecuta la sincronización. Esto provocará un bloqueo AA debido a que __driver_attach_async_helper obtiene el bloqueo dev. Reproducir: y se puede reproducir haciendo que la condición (if (!entry || atomic_read(&entry_count) > MAX_WORK)) sea insostenible, como se muestra a continuación: [ 370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" deshabilita este mensaje. [ 370.787154] tarea:swapper/0 estado:D pila: 0 pid: 1 ppid: 0 indicadores:0x00004000 [ 370.788865] Seguimiento de llamadas: [ 370.789374] [ 370.789841] __schedule+0x482/0x1050 [ 370.790613] schedule+0x92/0x1a0 [ 370.791290] schedule_preempt_disabled+0x2c/0x50 [ 370.792256] __mutex_lock.isra.0+0x757/0xec0 [ 370.793158] __mutex_lock_slowpath+0x1f/0x30 [ 370.794079] mutex_lock+0x50/0x60 [ 370.794795] __device_driver_lock+0x2f/0x70 [ 370.795677] ? driver_probe_device+0xd0/0xd0 [ 370.796576] __driver_attach_async_helper+0x1d/0xd0 [ 370.797318] ? driver_probe_device+0xd0/0xd0 [ 370.797957] async_schedule_node_domain+0xa5/0xc0 [ 370.798652] async_schedule_node+0x19/0x30 [ 370.799243] __driver_attach+0x246/0x290 [ 370.799828] ? driver_allows_async_probing+0xa0/0xa0 [ 370.800548] bus_for_each_dev+0x9d/0x130 [ 370.801132] driver_attach+0x22/0x30 [ 370.801666] bus_add_driver+0x290/0x340 [ 370.802246] driver_register+0x88/0x140 [ 370.802817] ? virtio_scsi_init+0x116/0x116 [ 370.803425] scsi_register_driver+0x1a/0x30 [ 370.804057] init_sd+0x184/0x226 [ 370.804533] do_one_initcall+0x71/0x3a0 [ 370.805107] kernel_init_freeable+0x39a/0x43a [ 370.805759] ? rest_init+0x150/0x150 [ 370.806283] kernel_init+0x26/0x230 [ 370.806799] ret_from_fork+0x1f/0x30 Para corregir el bloqueo, mueva async_schedule_dev fuera de device_lock, como podemos ver, en async_schedule_node_domain, el parámetro de queue_work_node es system_unbound_wq, por lo que puede aceptar operaciones concurrentes, lo que tampoco cambiará la lógica del código y no conducirá a un bloqueo.