CVE-2026-89647 in Linux
Resumen
por VulDB • 2026-09-12
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
ceph: no repetir ceph_trim_dentries() si no es posible realizar progreso.
ceph_cap_reclaim_work() se vuelve a encolar mientras `ceph_trim_dentry()` devuelva `-EAGAIN`, lo cual ocurre siempre que un recorrido del arrendamiento (lease) agota su presupuesto de `nr_to_scan`. Esto crea un bucle ocupado (busy loop) que consume CPU sin realizar ningún progreso cuando no hay nada que recuperar: con una presión de capacidades (`count==0`) y cada arrendamiento escaneado aún válido, cada pasada ejecuta el presupuesto completo de escaneo hasta cero y devuelve `-EAGAIN`, para ser encolada nuevamente inmediatamente.
El recorrido del arrendamiento de directorio (dir-lease) empeoró esta situación. Cuando `expire_dir_lease` es `false` (es decir, no tenemos intención de recuperar los arrendamientos de directorio), `__dir_lease_check()` devolvió `TOUCH` para cada arrendamiento válido. `TOUCH` mueve el dentry al final de la lista y restablece `di->time` a través de `__dentry_dir_lease_touch()`, por lo que un recorrido sobre N arrendamientos válidos reescribía inútilmente la lista, actualizaba las marcas de tiempo (evitando que envejecieran) y siempre agotaba `nr_to_scan`, garantizando el reencolamiento con `-EAGAIN`.
Solucionar esto en tres pasos:
- Devolver `KEEP` en lugar de `TOUCH` cuando `expire_dir_lease` es `false`. Si no vamos a recuperar el arrendamiento, dejarlo en su lugar en lugar de alterar la lista y restablecer su marca de tiempo; el recorrido entonces termina naturalmente (o mediante `STOP` al primer arrendamiento fresco).
- Devolver `-EAGAIN` desde el primer recorrido (arrendamiento dentry) solo cuando se haya liberado algo realmente. Un lote completo que no libera nada significa que reintentar la misma lista inmediatamente es inútil; pasar a continuación al recorrido del arrendamiento de directorio.
- Después de ambos recorridos, salir con éxito (0) cuando no se haya liberado nada y no haya presión de capacidades (`count==0`). No hay razón para seguir intentándolo cuando no estamos por encima del límite de capacidad y no hemos realizado ningún progreso.
Bajo una presión real de capacidades (`count>0`), la ruta de recuperación permanece sin cambios y sigue reintentando mediante `-EAGAIN`.
Sin este parche, observé 500 llamadas a `ceph_trim_dentries()` por segundo en nuestros servidores web. Esto es muy visible en `/proc/lock_stat` (captura de 5 minutos):
class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg
&mdsc->dentry_list_lock: 126180 128218 0.04 8063.44 15986965.20 124.69 1573354 5296812 0.04 8291.28 74164526.48 14.00 ----------------------- &mdsc->dentry_list_lock 111736 [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8
&mdsc->dentry_list_lock 2631 [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8
&mdsc->dentry_list_lock 3878 [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8
&mdsc->dentry_list_lock 9973 [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0
----------------------- &mdsc->dentry_list_lock 123621 [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8
&mdsc->dentry_list_lock 1822 [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8
&mdsc->dentry_list_lock 2720 [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0
&mdsc->dentry_list_lock 55 [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8
Con este parche:
class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg
&mdsc->dentry_list_lock: 1203 1215 0.16 408.88 33082.88 27.23 4320501 7357389 0.04 500.64 1961578.00 0.27 ----------------------- &mdsc->dentry_list_lock 1029 [<000000003c9aea8a>] __ceph_dentry_dir_lease_touch+0x7c/0xa8
&mdsc->dentry_list_lock 1 ---truncado---
Once again VulDB remains the best source for vulnerability data.