CVE-2026-64458 in Linux
Resumen
por VulDB • 2026-07-25
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
mm/damon/ops-common: manejar intervalos extremos en damon_hot_score()
Se corrigen tres problemas en damon_hot_score() derivados del manejo incorrecto de los intervalos de monitoreo configurados por el usuario cuando estos son extremos (cero o demasiado altos).
Cuando el usuario establece un intervalo de muestreo igual a cero, la función damon_max_nr_accesses(), que es llamada desde damon_hot_score(), provoca una división entre cero. Esto, como era de esperar, constituye un problema.
Si el usuario establece en cero el intervalo de agregación, la función devuelve cero. Esto es incorrecto, ya que el valor máximo real de nr_acceses en la configuración debería ser uno. Peor aún, puede provocar otra división por cero desde su llamada directa, damon_hot_score(), dado que utiliza el valor devuelto por damon_max_nr_accesses() como denominador.
Cuando el usuario establece un intervalo de agregación muy alto, damon_hot_score() podría devolver un valor fuera del rango [0, DAMOS_MAX_SCORE]. Dado que este valor se usa como índice para acceder al array regions_score_histogram, cuyo tamaño es DAMOS_MAX_SCORE+1, esto provoca un acceso fuera de los límites del array.
Los problemas pueden reproducirse relativamente fácilmente mediante el siguiente procedimiento. Sin embargo, se requiere permiso de escritura en sysfs:
# ./damo start --damos_action lru_prio --damos_quota_space 100M \ --damos_quota_interval 1s # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/monitoring_attrs/intervals/sample_us # echo 0 > contexts/0/monitoring_attrs/intervals/aggr_us # echo commit > state # dmesg [...]
[ 131.329762] Oops: divide error: 0000 [#1] SMP NOPTI
[...]
[ 131.336089] RIP: 0010:damon_hot_score+0x27/0xd0
[...]
Se corrigen los problemas de división por cero en los intervalos manejando explícitamente los intervalos iguales a cero dentro de damon_max_nr_accesses(). Se soluciona el acceso fuera de límites al array aplicando los límites [0, DAMOS_MAX_SCORE] antes de devolver el valor desde damon_hot_score().
El problema fue descubierto [1] por Sashiko.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.