CVE-2026-64458

What the bug is

Fix three issues in damon_hot_score() that comes from wrong handling of extreme (zero or too high) monitoring intervals user setup. 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. 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. 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. The issues can be relatively easily reproduced like below. The sysfs write permission is required, though. # ./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 [...] Fix the divide-by-zero intervals problems by explicitly handling the zero intervals in damon_max_nr_accesses(). Fix the out-of-bound array access by applying [0, DAMOS_MAX_SCORE] bounds before returning from damon_hot_score(). The issue was discovered [1] by Sashiko.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

include/linux/damon.h
mm/damon/ops-common.c

What this is

DAMONMAINTAINERS section matched on include/linux/damon.h · damon@lists.linux.dev · Maintained

Check it on the machine

grep -wE 'CONFIG_DAMON|CONFIG_DAMON_PADDR|CONFIG_DAMON_VADDR' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

Show whether Debian builds this, per release

Debian does not build this code in 1 release. It does build it in 4 releases, so the answer depends on which release the machine runs.

• bookwormn
• trixie, forky, sid, bookworm · linux-6.12y

n

not enabled on any flavour - this release does not build the code

y

built into the kernel image on every flavour - only a patch removes it

Build switches

CONFIG_DAMON, CONFIG_DAMON_PADDR, CONFIG_DAMON_VADDR

Reads as

all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published

2026-07-25 (3 months ago)source

CVSS

no vector published, unrated

Attack vector

not published

EPSS

0.18%, higher than 7.1% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

not yet assignedsource

Subsystem

include/linux

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
5.16	6.1.178	58321b4e6e4f
5.16	6.6.145	74fef68d5211
5.16	6.12.96	ef2ae10a4582
5.16	6.18.39	9c8f31eaae61
5.16	7.1.4	76e415ea88d2
5.16	7.2	35d4a3cf70a8

Debian advisories