CVE-2026-64458 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/ops-common: handle extreme intervals in damon_hot_score()
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability resides within the linux kernel's damon subsystem, specifically in the damon_hot_score() function which handles monitoring and scoring of memory access patterns. This subsystem is designed to provide dynamic access monitoring for memory management optimization, particularly through the damos (dynamic access monitoring and optimization) framework that supports various memory management actions including lru_prio. The flaw manifests when users configure extreme monitoring intervals through sysfs interfaces, creating scenarios where divide-by-zero operations occur and array bounds are exceeded.
The technical implementation issues stem from improper validation of user-specified monitoring intervals within the damon_max_nr_accesses() function which is invoked by damon_hot_score(). When a sampling interval of zero is configured, the mathematical calculation within damon_max_nr_accesses() leads to a direct divide-by-zero error that crashes the kernel. This represents a classic security vulnerability pattern where user input validation fails to account for edge cases, specifically null or zero values that should be explicitly handled. The aggregation interval handling presents similar problems where setting it to zero causes incorrect return values of zero instead of the expected minimum value of one, which then propagates into further divide-by-zero conditions in the calling damon_hot_score() function.
When users configure extremely high aggregation intervals, the vulnerability manifests as out-of-bounds array access through the damon_hot_score() function returning values outside the valid range of [0, DAMOS_MAX_SCORE]. This numeric overflow occurs because the return value is used directly as an index into a regions_score_histogram array that has a size of DAMOS_MAX_SCORE+1 elements. The absence of bounds checking before array indexing creates a potential for memory corruption and system instability, representing a direct violation of memory safety principles that could be exploited by malicious actors to cause denial of service or potentially execute arbitrary code.
The vulnerability impacts the kernel's memory management subsystem through the damon framework which is used for dynamic memory access pattern monitoring and optimization. This affects systems where memory management policies are dynamically adjusted based on access patterns, particularly those using lru_prio actions that prioritize memory pages for retention in the page cache. The exploitation requires write permissions to sysfs interfaces which limits the attack surface but still represents a critical kernel-level vulnerability that could be leveraged by privileged users or potentially through other kernel interfaces.
The fix implements explicit handling of zero intervals in damon_max_nr_accesses() to prevent divide-by-zero conditions, and applies proper bounds checking to damon_hot_score() to ensure return values remain within the [0, DAMOS_MAX_SCORE] range before being used as array indices. This approach follows established security practices for input validation and memory safety, aligning with common software security principles that require robust error handling and boundary checking. The solution addresses the core issue without disrupting normal operation of the damon subsystem while maintaining compatibility with legitimate use cases.
This vulnerability demonstrates characteristics consistent with CWE-369 (Divide by Zero) and CWE-129 (Improper Validation of Array Index) in the Common Weakness Enumeration catalog. The exploitation pattern also aligns with ATT&CK techniques related to privilege escalation through kernel vulnerabilities, specifically targeting the kernel's memory management subsystem. The fix maintains backward compatibility while addressing security concerns that could be escalated through kernel exploit chains, particularly relevant for systems running in high-security environments where kernel stability and memory safety are paramount considerations.