Vulnerabilidad en kernel de Linux (CVE-2024-26629)
Fecha de publicación:
13/03/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: arreglar RELEASE_LOCKOWNER La prueba en so_count en nfsd4_release_lockowner() no tiene sentido y es dañina. Vuelva a usar check_for_locks(), cambiándolo para no dormir. Primero: dañino. Como se documenta en el comentario de kdoc para nfsd4_release_lockowner(), la prueba en so_count puede devolver transitoriamente un falso positivo, lo que resulta en una devolución de NFS4ERR_LOCKS_HELD cuando en realidad no se mantienen bloqueos. Esto es claramente una violación del protocolo y con el cliente NFS de Linux puede provocar un comportamiento incorrecto. Si se envía RELEASE_LOCKOWNER mientras algún otro subproceso todavía está procesando una solicitud de LOCK que falló porque, en el momento en que se recibió esa solicitud, el propietario determinado tenía un bloqueo en conflicto, entonces el subproceso nfsd que procesa esa solicitud de LOCK puede contener una referencia (conflock) a el propietario del bloqueo que hace que nfsd4_release_lockowner() devuelva un error incorrecto. El cliente NFS de Linux ignora ese error NFS4ERR_LOCKS_HELD porque nunca envía NFS4_RELEASE_LOCKOWNER sin liberar primero ningún bloqueo, por lo que sabe que el error es imposible. Se supone que el propietario de la cerradura fue liberado, por lo que puede utilizar el mismo identificador de propietario de la cerradura en alguna solicitud de bloqueo posterior. Cuando reutiliza un identificador de propietario de bloqueo para el cual falló una RELEASE anterior, naturalmente usará un lock_seqid de cero. Sin embargo, el servidor, que no liberó al propietario del bloqueo, esperará un lock_seqid mayor y, por lo tanto, responderá con NFS4ERR_BAD_SEQID. Claramente es perjudicial permitir un falso positivo, lo que permite la prueba so_count. La prueba es una tontería porque... bueno... no significa nada. so_count es la suma de tres recuentos diferentes. 1/ el conjunto de estados enumerados en so_stateids 2/ el conjunto de bloqueos vfs activos propiedad de cualquiera de esos estados 3/ varios recuentos transitorios, como bloqueos en conflicto. Cuando se prueba con '2', queda claro que una de ellas es la referencia transitoria obtenida por find_lockowner_str_locked(). No está claro cuál se espera que sea el otro. En la práctica, el recuento suele ser 2 porque hay precisamente un estado en so_stateids. Si hubiera más, esto fracasaría. En mis pruebas veo dos circunstancias en las que se llama a RELEASE_LOCKOWNER. En un caso, se llama a CLOSE antes de RELEASE_LOCKOWNER. Eso da como resultado que se eliminen todos los estados de bloqueo y, por lo tanto, se descarte el propietario de la cerradura (se elimina cuando no hay más referencias, lo que generalmente sucede cuando se descarta el estado de bloqueo). Cuando nfsd4_release_lockowner() descubre que el propietario del bloqueo no existe, devuelve éxito. El otro caso muestra un so_count de '2' y precisamente un estado listado en so_stateid. Parece que el cliente Linux utiliza un propietario de bloqueo independiente para cada archivo, lo que da como resultado un estado de bloqueo por propietario de bloqueo, por lo que esta prueba en '2' es segura. Para otro cliente puede que no sea seguro. Entonces, este parche cambia check_for_locks() para usar el (nuevo) find_any_file_locked() para que no tome una referencia en nfs4_file y así nunca llame a nfsd_file_put(), y por lo tanto nunca duerma. Con esta verificación, es seguro restaurar el uso de check_for_locks() en lugar de probar so_count con el misterioso '2'.
Gravedad CVSS v3.1: MEDIA
Última modificación:
23/12/2025
