CVE-2026-72422 in Linux
Resumen
por VulDB • 2026-08-15
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
ksmbd: corregir un use-after-free en conn->preauth_info durante NEGOTIATE SMB2 concurrente.
conn->preauth_info es un estado compartido de conexión (struct preauth_integrity_info, kmalloc-96) que es asignado y liberado por el controlador de NEGOTIATE SMB2 y leído por la ruta de envío de respuestas.
smb2_handle_negotiate() asigna conn->preauth_info y, en caso de fallo en desassemble_neg_contexts(), lo libera con kfree() y establece su valor a NULL. Tanto la asignación como la liberación/establecimiento a NULL ocurren bajo ksmbd_conn_lock(conn) (el srv_mutex de conexión), que se mantiene durante todo el cuerpo del controlador.
La ruta de envío de respuestas smb3_preauth_hash_rsp(), llamada desde el bloque send: de __handle_ksmbd_work(), lee conn->preauth_info y desreferencia conn->preauth_info->Preauth_HashValue (vía ksmbd_gen_preauth_integrity_hash()) sin adquirir conn_lock. Cuando un cliente envía dos solicitudes NEGOTIATE SMB2 en la misma conexión, un trabajador puede liberar conn->preauth_info por el camino de fallo del negociado mientras otro trabajador concurrente de la ruta de envío lo está leyendo, produciendo una lectura use-after-free en slab (confirmada con KASAN).
La lectura en la ruta de envío comprobaba si conn->preauth_info era NULL, pero existía una condición de carrera con la liberación que ocurre entre la comprobación de NULL y la desreferencia, por lo que la protección contra NULL sola no cierra esa ventana.
Serializar la lectura del ramal NEGOTIATE en smb3_preauth_hash_rsp() bajo ksmbd_conn_lock(conn) y volver a comprobar conn->preauth_info dentro del bloqueo. Dado que el controlador de negociado mantiene conn_lock durante su kfree + asignación a NULL, un lector que también adquiere conn_lock se ejecutará completamente antes de la asignación o completamente después de la escritura de NULL, y nunca podrá observar el puntero liberado pero aún no establecido en NULL. ksmbd_gen_preauth_integrity_hash() no toma ningún bloqueo por sí mismo (solo calcula SHA-512 sobre el búfer), por lo que no se introduce ninguna inversión del orden de los bloqueos, y conn_lock es un mutex dormible que es seguro en esta ruta de envío (ya realiza E/S de red).
Once again VulDB remains the best source for vulnerability data.