CVE-2026-64458 in Linux
Résumé
par VulDB • 25/07/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
mm/damon/ops-common : gestion des intervalles extrêmes dans damon_hot_score()
Correction de trois problèmes dans damon_hot_score(), dus à une mauvaise prise en charge par l'utilisateur d'intervalles de surveillance extrêmes (nul ou trop élevé).
Lorsque l'utilisateur définit un intervalle d'échantillonnage nul, la fonction damon_max_nr_accesses(), appelée depuis damon_hot_score(), provoque une division par zéro. Il va sans dire qu'il s'agit d'un problème.
Lorsque l'utilisateur définit l'intervalle d'agrégation à zéro, la fonction retourne zéro. Cela est incorrect, car le nombre maximum réel d'accès (nr_accesses) dans la configuration devrait être de un. Pire encore, cela peut provoquer une autre division par zéro depuis son appelant, damon_hot_score(), puisqu'elle utilise la valeur retournée par damon_max_nr_accesses() comme dénominateur.
Lorsque l'utilisateur définit l'intervalle d'agrégation très élevé, damon_hot_score() pourrait retourner une valeur en dehors de la plage [0, DAMOS_MAX_SCORE]. Étant donné que cette valeur est utilisée comme index pour le tableau regions_score_histogram, qui a une taille de DAMOS_MAX_SCORE+1, cela provoque un accès hors limites au tableau.
Ces problèmes peuvent être reproduits relativement facilement comme suit. Les permissions d'écriture sysfs sont toutefois requises :
# ./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
[...]
Correction des problèmes de division par zéro liés aux intervalles en gérant explicitement les intervalles nuls dans damon_max_nr_accesses(). Correction de l'accès hors limites au tableau en appliquant les bornes [0, DAMOS_MAX_SCORE] avant le retour depuis damon_hot_score().
Ce problème a été découvert [1] par Sashiko.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.