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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cgroup/bpf: utiliza una cola de trabajo dedicada para la destrucción de bpf de cgroup Se encontró un problema hung_task que se muestra a continuación: INFORMACIÓN: la tarea kworker/0:0:8 se bloqueó durante más de 327 segundos. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" deshabilita este mensaje. Cola de trabajo: eventos cgroup_bpf_release Rastreo de llamadas: __schedule+0x5a2/0x2050 ? find_held_lock+0x33/0x100 ? wq_worker_sleeping+0x9e/0xe0 schedule+0x9f/0x180 schedule_preempt_disabled+0x25/0x50 __mutex_lock+0x512/0x740 ? cgroup_bpf_release+0x1e/0x4d0 ? cgroup_bpf_release+0xcf/0x4d0 ? proceso_trabajos_programados+0x161/0x8a0 ? cgroup_bpf_release+0x1e/0x4d0 ? mutex_lock_nested+0x2b/0x40 ? __pfx_delay_tsc+0x10/0x10 mutex_lock_nested+0x2b/0x40 cgroup_bpf_release+0xcf/0x4d0 ? proceso_trabajos_programados+0x161/0x8a0 ? trace_event_raw_event_workqueue_execute_start+0x64/0xd0 ? Este problema se puede reproducir con la siguiente prueba pressuse: 1. Se elimina una gran cantidad de cgroups de cpuset. 2. Enciende y apaga la CPU repetidamente. 3. Establece watchdog_thresh repetidamente. Los scripts se pueden obtener en el ENLACE mencionado arriba de la firma. El motivo de este problema es que cgroup_mutex y cpu_hotplug_lock se adquieren en tareas diferentes, lo que puede provocar un bloqueo. Puede provocar un bloqueo mediante los siguientes pasos: 1. Se elimina una gran cantidad de conjuntos de CPU de forma asincrónica, lo que coloca una gran cantidad de trabajos cgroup_bpf_release en system_wq. El max_active de system_wq es WQ_DFL_ACTIVE(256). En consecuencia, todos los trabajos activos son trabajos cgroup_bpf_release y muchos trabajos cgroup_bpf_release se colocarán en la cola inactiva. Como se ilustra en el diagrama, hay 256 (en la cola activa) + n (en la cola inactiva) trabajos. 2. La configuración de watchdog_thresh mantendrá cpu_hotplug_lock.read y colocará el trabajo smp_call_on_cpu en system_wq. Sin embargo, el paso 1 ya ha llenado system_wq, 'sscs.work' se coloca en la cola inactiva. 'sscs.work' tiene que esperar hasta que los trabajos que se colocaron en la cola inactiva anteriormente se hayan ejecutado (n cgroup_bpf_release), por lo que se bloqueará por un tiempo. 3. La CPU sin conexión requiere cpu_hotplug_lock.write, que está bloqueado por el paso 2. 4. Los conjuntos de CPU que se eliminaron en el paso 1 colocan los trabajos de cgroup_release en cgroup_destroy_wq. Están compitiendo para obtener cgroup_mutex todo el tiempo. Cuando cgroup_metux es adquirido por un trabajo en css_killed_work_fn, llamará a cpuset_css_offline, que necesita adquirir cpu_hotplug_lock.read. Sin embargo, cpuset_css_offline se bloqueará para el paso 3. 5. En este momento, hay 256 trabajos en la cola activa que son cgroup_bpf_release, están intentando adquirir cgroup_mutex y, como resultado, todos ellos están bloqueados. En consecuencia, no se puede ejecutar sscs.work. En definitiva, esta situación provoca el bloqueo de cuatro procesos, lo que genera un punto muerto. system_wq(paso1) WatchDog(paso2) cpu offline(paso3) cgroup_destroy_wq(paso4) ... 2000+ cgroups eliminados asyn 256 activos + n inactivos __lockup_detector_reconfigure P(cpu_hotplug_lock.read) poner sscs.work en system_wq 256 + n + 1(sscs.work) sscs.work esperar a ser ejecutado warting sscs.work finalizar percpu_down_write P(cpu_hotplug_lock.write) ...bloqueando... css_killed_work_fn P(cgroup_mutex) cpuset_css_offline P(cpu_hotplug_lock.read) ...bloqueando... 256 cgroup_bpf_release mutex_lock(&cgroup_mutex); ..bloqueo... Para solucionar el problema, coloque los trabajos de cgroup_bpf_release en una cola de trabajo dedicada que pueda romper el bucle y resolver el problema. Las colas de trabajo del sistema son para cosas diversas que no deberían crear una gran cantidad de elementos de trabajo simultáneos. Si algo va a generar > ---truncado---