Descripción
En el kernel de Linux se resolvió la siguiente vulnerabilidad: lockd: fijar el siguiente archivo durante la liberación del lock en nlm_inspect_file. nlm_traverse_files() fija el archivo actual con f_count++ durante un mutex_unlock para nlm_inspect_file(), pero nada fija el puntero next guardado. Una llamada concurrente a nlm_release_file() puede liberar con kfree el siguiente archivo durante la ventana de desbloqueo, y el iterador desreferencia memoria liberada en el siguiente paso del bucle. La corrección fija tanto el archivo actual como el siguiente antes de liberar el lock. Se avanza intercambiando los cursores fijados al final de cada iteración, de modo que next siempre se mantiene vivo durante el desbloqueo. Se llama siempre a nlm_file_release() después de liberar la fijación de iteración, independientemente de si el archivo cumplió el predicado. Se usa nlm_file_inuse(), que recorre en vivo la lista de locks del inode, en lugar del campo f_locks en caché, para que los archivos omitidos que nunca ejecutaron nlm_inspect_file() se evalúen correctamente. Como ahora cada archivo de un bucket del hash se fija y se libera, los archivos omitidos por el predicado is_failover_file que no tienen locks, bloques, recursos compartidos ni referencias externas se eliminan durante el recorrido. El código anterior nunca evaluaba los archivos omitidos para su limpieza. El nuevo comportamiento es intencional: dichos archivos están obsoletos y no deben persistir en la tabla.
Qué hacer
Revisa si usas el producto afectado y en qué versión, y aplica la actualización o la mitigación que indique el aviso del fabricante. CISA no ha confirmado que se esté explotando; si eso cambia, esta ficha pasa a «explotada» y te avisamos en el boletín.
Versiones afectadas
- Linux Afectadas: 01df9c5e918ae5559f2d96da0143f8bfbb9e6171 y anteriores a e3c413f789eaf0170275c7eba523ead73d963f30 · 01df9c5e918ae5559f2d96da0143f8bfbb9e6171 y anteriores a 08a455f87b14c7ff22ae3fdadda62a796a3a5572 · 01df9c5e918ae5559f2d96da0143f8bfbb9e6171 y anteriores a 550c19222c7132c888e23c9d89079ba1c9bc4cca · 01df9c5e918ae5559f2d96da0143f8bfbb9e6171 y anteriores a 350087f231c11efcd288c310707c40eab63ca583 · 01df9c5e918ae5559f2d96da0143f8bfbb9e6171 y anteriores a c24bdb7df2f34bdc38ca8a73796f5acb40f1830c · 01df9c5e918ae5559f2d96da0143f8bfbb9e6171 y anteriores a 41f0a6d31615fcae261bf28a0aa50050dc93a401 · 01df9c5e918ae5559f2d96da0143f8bfbb9e6171 y anteriores a e999a88133654c6dfc68487fb49da5f20dfa2d4f · 01df9c5e918ae5559f2d96da0143f8bfbb9e6171 y anteriores a 526c49cff3f72c3ec74752016380c7567040581b
- Linux Afectadas: 2.6.18 No afectadas: 5.10.270 · 5.15.221 · 6.1.188 · 6.6.157 · 6.12.109 · 6.18.50
Según el registro de la vulnerabilidad en CVE.org, tal como lo publicó el fabricante. Confirma tu versión exacta en el aviso del fabricante.
Referencias
- Referencia en git.kernel.orggit.kernel.org/stable/c/e3c413f789eaf0170275c7eba523ead73d963f30
- Referencia en git.kernel.orggit.kernel.org/stable/c/08a455f87b14c7ff22ae3fdadda62a796a3a5572
- Referencia en git.kernel.orggit.kernel.org/stable/c/550c19222c7132c888e23c9d89079ba1c9bc4cca
- Referencia en git.kernel.orggit.kernel.org/stable/c/350087f231c11efcd288c310707c40eab63ca583
- Referencia en git.kernel.orggit.kernel.org/stable/c/c24bdb7df2f34bdc38ca8a73796f5acb40f1830c
- Referencia en git.kernel.orggit.kernel.org/stable/c/41f0a6d31615fcae261bf28a0aa50050dc93a401
- Referencia en git.kernel.orggit.kernel.org/stable/c/e999a88133654c6dfc68487fb49da5f20dfa2d4f
- Referencia en git.kernel.orggit.kernel.org/stable/c/526c49cff3f72c3ec74752016380c7567040581b
Ver el texto original en inglés (CVE.org)
lockd: pin next file across nlm_inspect_file lock-drop
In the Linux kernel, the following vulnerability has been resolved: lockd: pin next file across nlm_inspect_file lock-drop nlm_traverse_files() pins the current file with f_count++ across a mutex_unlock for nlm_inspect_file(), but nothing pins the saved next pointer. A concurrent nlm_release_file() can kfree the next file during the unlock window, and the iterator dereferences freed memory on the next loop step. Pin both current and next before the lock-drop. Advance by swapping the pinned cursors at the end of each iteration so next is always held alive across the unlock. Always call nlm_file_release() after dropping the iteration pin, regardless of whether the file matched the predicate. Use nlm_file_inuse(), which does a live walk of the inode lock list, rather than the cached f_locks field, so skipped files that never ran nlm_inspect_file() are evaluated correctly. Because every file in a hash bucket is now pinned and released, files skipped by the is_failover_file predicate that have no locks, blocks, shares, or external references are deleted during traversal. The old code never evaluated skipped files for cleanup. The new behavior is intentional: such files are stale and should not persist in the table.