CVE-2026-74645 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/lru_sort: error out for >10000 active_mem_bp
damos_quota_score() can trigger division by zero if the target value is zero. DAMON_LRU_SORT lets users set the target value for the hot memory scheme via active_mem_bp parameter. It avoids setting it as the target value if the parameter value is zero. However, it also sets the cold memory scheme with a target value that is calculated as '10000 - active_mem_bp + 2'. Hence, if a user sets active_mem_bp 10002, the cold memory scheme's quota goal target value can be zero. As a result, division by zero can be triggered. Fix by returning an error when the user tries to start DAMON with >10000 active_mem_bp parameter value.
It makes no sense to set active_mem_bp with 10002. It also requires module parameters write permission to reproduce the issue. That said, the consequence is quite bad.
One reliable way to reproduce the issue is like below:
# cd /sys/module/damon_lru_sort/parameters # echo 1000 > wmarks_high # echo 995 > wmarks_mid # echo 0 > wmarks_low # echo 10002 > active_mem_bp # echo Y > enabled # dmesg -w [...]
[ 597.421247] Oops: divide error: 0000 [#1] SMP NOPTI
[ 597.428848] RIP: 0010:damos_quota_score+0x6f/0x480
This issue was discovered [1] by Sashiko.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel's Dynamic Memory Access Monitoring (DAMON) subsystem, specifically the LRU sorting scheme implemented in mm/damon/lru_sort, contains a critical arithmetic vulnerability that leads to a division-by-zero error within the damos_quota_score function. This flaw arises from an incomplete validation of user-supplied parameters during the initialization of memory access monitoring schemes. DAMON allows system administrators and users with appropriate privileges to configure various thresholds for identifying hot and cold memory regions based on access patterns. The active_mem_bp parameter is used to define the target value for the hot memory scheme, representing a percentage-based weight or quota goal. While the implementation correctly prevents setting this specific hot memory target to zero, it fails to adequately validate the resulting configuration when calculating parameters for the complementary cold memory scheme.
The technical root cause lies in the calculation logic for the cold memory scheme's quota goal. The kernel computes this value using the formula 10000 minus active_mem_bp plus two. This arithmetic operation is designed to balance the monitoring weights between hot and cold regions, ensuring that the total weight remains within a reasonable range. However, when an attacker or misconfigured user sets the active_mem_bp parameter to a value greater than 10002, such as 10002 itself, the resulting calculation yields zero for the cold memory scheme's target. Specifically, if active_mem_bp is set to 10002, the expression evaluates to one hundred thousand minus ten thousand two plus two, which equals zero in integer arithmetic contexts where overflow or underflow logic might be misapplied or simply results in a null divisor scenario depending on internal scaling factors. This zero value is then passed directly into the damos_quota_score function without any subsequent checks for validity before being used as a denominator.
The operational impact of this vulnerability is severe, manifesting as a kernel panic due to an illegal division operation. When the DAMON subsystem attempts to score memory access patterns using the invalid quota target, the CPU triggers a divide error exception. This results in an Oops message and typically causes the affected kernel thread or potentially the entire system to crash if not handled gracefully by higher-level fault handlers. The provided reproduction steps demonstrate that writing 10002 to the active_mem_bp parameter while enabling the DAMON LRU sort module reliably triggers this divide error, as evidenced by stack traces pointing directly to damos_quota_score. This denial of service condition can disrupt system stability and availability, particularly in environments where DAMON is actively monitoring memory access for performance optimization or security auditing purposes.
From a vulnerability classification perspective, this issue aligns with CWE-369, which describes divide-by-zero errors that occur when software performs an arithmetic division operation using zero as the divisor. This type of flaw often leads to application crashes or system instability and is frequently categorized under CWE-20 for improper input validation where boundary conditions are not adequately checked. In terms of attack vectors, this vulnerability requires local access with write permissions to the DAMON module parameters via sysfs interfaces, placing it within the scope of LOCAL privilege escalation attempts if combined with other vulnerabilities, though primarily it serves as a Denial of Service vector against kernel stability. It does not allow for arbitrary code execution directly but degrades system reliability significantly.
Mitigation strategies focus on enforcing stricter input validation at the point of parameter acceptance. The primary fix involves modifying the DAMON LRU sort initialization logic to explicitly reject any active_mem_bp value that exceeds 10000, thereby preventing the calculation from ever reaching a state where the cold memory target becomes zero or negative in unintended ways. System administrators should ensure they are running patched versions of the Linux kernel that include this correction. Additionally, restricting write access to /sys/module/damon_lru_sort/parameters can reduce the risk of accidental misconfiguration by unprivileged users. Regular auditing of module parameter configurations and keeping systems updated with security patches released by distribution vendors is essential to maintain resilience against such arithmetic flaws in core subsystems like DAMON.