Vulnerabilidad en Linux (CVE-2023-54316)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> refscale: Corrección del uso no inicializado de wait_queue_head_t<br /> <br /> Ejecutar la prueba refscale ocasionalmente bloquea el kernel con el siguiente error:<br /> <br /> [ 8569.952896] BUG: no se puede manejar el fallo de página para la dirección: ffffffffffffffe8<br /> [ 8569.952900] #PF: acceso de lectura de supervisor en modo kernel<br /> [ 8569.952902] #PF: error_code(0x0000) - página no presente<br /> [ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0<br /> [ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI<br /> [ 8569.952916] Nombre del hardware: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021<br /> [ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190<br /> :<br /> [ 8569.952940] Traza de llamada:<br /> [ 8569.952941] <br /> [ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale]<br /> [ 8569.952959] kthread+0x10e/0x130<br /> [ 8569.952966] ret_from_fork+0x1f/0x30<br /> [ 8569.952973] <br /> <br /> La causa probable es que se llama a init_waitqueue_head() después de la llamada a la función torture_create_kthread() que crea el kthread ref_scale_reader. Aunque es muy probable que esta llamada a init_waitqueue_head() se complete antes de que este kthread sea creado y comience a ejecutarse, es posible que el kthread que realiza la llamada se retrase entre las llamadas a torture_create_kthread() e init_waitqueue_head(). En este caso, el nuevo kthread utilizará la cabecera de la cola de espera antes de que esté correctamente inicializada, lo cual no es bueno para la salud y el bienestar del kernel.<br /> <br /> El bloqueo anterior ocurrió aquí:<br /> <br /> static inline void __add_wait_queue(...)<br /> {<br /> :<br /> if (!(wq-&amp;gt;flags &amp;amp; WQ_FLAG_PRIORITY)) &amp;lt;=== Bloqueo aquí<br /> <br /> El desplazamiento de flags desde la entrada list_head en wait_queue_entry es -0x18. Si reader_tasks[i].wq.head.next es NULL, ya que la estructura reader_task asignada se inicializa a cero, la instrucción intentará acceder a la dirección 0xffffffffffffffe8, que es exactamente la dirección de fallo mencionada anteriormente.<br /> <br /> Este commit, por lo tanto, invoca init_waitqueue_head() antes de crear el kthread.