https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 10:14:46 +0000 https://vulnerability.circl.lu/vuln/cve-2026-64458 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mm/damon/ops-common: handle extreme intervals in damon_hot_score()</p> <p>Fix three issues in damon_hot_score() that comes from wrong handling of extreme (zero or too high) monitoring intervals user setup.</p> <p>When the user sets sampling interval zero, damon_max_nr_accesses(), which is called from damon_hot_score(), causes a divide-by-zero. Needless to say, it is a problem.</p> <p>When the user sets the aggregation interval zero, the function returns zero. It is wrong, since the real maximum nr_acceses in the setup should be one. Worse yet, it can cause another divide-by-zero from its caller, damon_hot_score(), since it uses damon_max_nr_accesses() return value as a denominator.</p> <p>When the user sets the aggregation interval very high, damon_hot_score() could return a value out of [0, DAMOS_MAX_SCORE] range. Since the return value is used as an index to the regions_score_histogram array, which is DAMOS_MAX_SCORE+1 size, it causes out of bounds array access.</p> <p>The issues can be relatively easily reproduced like below. The sysfs write permission is required, though.</p> <p># ./damo start --damos_action lru_prio --damos_quota_space 100M \ --damos_quota_interval 1s # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 &gt; contexts/0/monitoring_attrs/intervals/sample_us # echo 0 &gt; contexts/0/monitoring_attrs/intervals/aggr_us # echo commit &gt; state # dmesg [...] [ 131.329762] Oops: divide er…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mm/damon/ops-common: handle extreme intervals in damon_hot_score()</p> <p>Fix three issues in damon_hot_score() that comes from wrong handling of extreme (zero or too high) monitoring intervals user setup.</p> <p>When the user sets sampling interval zero, damon_max_nr_accesses(), which is called from damon_hot_score(), causes a divide-by-zero. Needless to say, it is a problem.</p> <p>When the user sets the aggregation interval zero, the function returns zero. It is wrong, since the real maximum nr_acceses in the setup should be one. Worse yet, it can cause another divide-by-zero from its caller, damon_hot_score(), since it uses damon_max_nr_accesses() return value as a denominator.</p> <p>When the user sets the aggregation interval very high, damon_hot_score() could return a value out of [0, DAMOS_MAX_SCORE] range. Since the return value is used as an index to the regions_score_histogram array, which is DAMOS_MAX_SCORE+1 size, it causes out of bounds array access.</p> <p>The issues can be relatively easily reproduced like below. The sysfs write permission is required, though.</p> <p># ./damo start --damos_action lru_prio --damos_quota_space 100M \ --damos_quota_interval 1s # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 &gt; contexts/0/monitoring_attrs/intervals/sample_us # echo 0 &gt; contexts/0/monitoring_attrs/intervals/aggr_us # echo commit &gt; state # dmesg [...] [ 131.329762] Oops: divide er…</p> https://vulnerability.circl.lu/vuln/cve-2026-64458