CVE-2026-64458

What it actually does

This Linux kernel flaw is in DAMON, the Data Access MONitor subsystem, specifically the damon_hot_score() and damon_max_nr_accesses() logic used when DAMON-based schemes calculate memory-region hotness scores. If a user with permission to write DAMON sysfs controls sets extreme monitoring intervals, such as a zero sampling interval, zero aggregation interval, or an excessively large aggregation interval, the kernel can perform a divide-by-zero or use an out-of-range hotness score as an array index. The practical result is a kernel Oops and potential system crash or instability. Because exploitation requires the ability to modify DAMON sysfs configuration, this is primarily a local denial-of-service issue rather than a remote network-exploitable vulnerability.

Why it matters to the business

An attacker or misconfigured automation with sufficient local privileges to change DAMON settings could crash or destabilize affected Linux systems. For servers, appliances, CI workers, container hosts, or performance-tuning environments where privileged users or tools can access DAMON sysfs controls, this can cause service interruption, workload failure, forced reboots, and operational downtime. The currently reported EPSS is low and there is no known CISA KEV listing or ransomware association, so broad active exploitation is not indicated, but the impact can still be severe on systems where untrusted or semi-trusted users have elevated local access.

How an attack unfolds

An attacker first needs local access with permissions sufficient to write to DAMON sysfs configuration under /sys/kernel/mm/damon/admin/. The attacker enables or configures a DAMON context and sets monitoring interval values to edge cases the vulnerable kernel mishandles, such as writing 0 to sample_us or aggr_us, or setting an unusually large aggregation interval. When the DAMON state is committed, the kernel evaluates memory-region hotness through damon_hot_score(). On vulnerable kernels, the malformed intervals can cause damon_max_nr_accesses() or its caller to divide by zero, or can produce a hotness score outside the expected range and index past the bounds of the regions_score_histogram array. The system then logs a kernel Oops, may panic depending on panic-on-oops settings, and can become unavailable until rebooted or recovered.

How to fix it

Upgrade affected Linux kernels to a version that includes the upstream fix for DAMON interval handling in mm/damon/ops-common. Because no specific distribution package versions were provided, use the fixed kernel advisories from the relevant Linux distribution or vendor and confirm that the patch explicitly handles zero sampling and aggregation intervals in damon_max_nr_accesses() and clamps damon_hot_score() results to the valid [0, DAMOS_MAX_SCORE] range. As interim mitigation, restrict write access to /sys/kernel/mm/damon/admin/ to trusted administrators only, disable DAMON where it is not required, avoid granting broad root-like access to untrusted users or containers, and monitor or block automation that writes zero or extreme values to DAMON interval settings. If panic_on_oops is enabled on production systems, consider the operational risk because this bug can turn a kernel Oops into an immediate reboot or outage.

How to confirm the fix worked

Confirm the running kernel has the vendor fix by checking the installed kernel package version against the distribution advisory or by verifying that the kernel source contains the corrected DAMON logic for zero intervals and score clamping. On test systems only, validation can include attempting to configure DAMON with zero sample_us or aggr_us values and confirming that the system no longer logs a divide error, Oops, or crash when committing the configuration. Do not run crash-triggering proof-of-concept commands on production hosts. Also validate that only trusted administrative users can write to /sys/kernel/mm/damon/admin/ and that audit or EDR telemetry captures writes to DAMON interval and state files.

Typical attack path

1. Gain local shell access to an affected Linux system.
2. Obtain privileges that allow writing to DAMON sysfs controls, typically root or equivalent administrative capability.
3. Navigate to DAMON administrative sysfs paths such as /sys/kernel/mm/damon/admin/kdamonds/0/.
4. Write extreme interval values, such as 0, to contexts/0/monitoring_attrs/intervals/sample_us or contexts/0/monitoring_attrs/intervals/aggr_us, or set an excessively large aggregation interval.
5. Commit the DAMON configuration by writing commit to the DAMON state control.
6. Trigger vulnerable hotness-score calculation during DAMON operation.
7. Cause a kernel Oops, crash, or system instability, resulting in denial of service.

How to detect it

Look for evidence of suspicious or accidental DAMON sysfs configuration changes followed by kernel faults. Useful sources include kernel logs, dmesg output, systemd journal entries for the kernel, /var/log/kern.log, /var/log/messages, auditd logs, EDR telemetry for file writes under sysfs, shell history for administrative users, and configuration-management job logs. Key behavioral indicators are writes to /sys/kernel/mm/damon/admin/*/contexts/*/monitoring_attrs/intervals/sample_us or aggr_us with value 0 or unusually large numeric values, followed by a write of commit to a DAMON state file. Kernel logs may show Oops messages referencing divide error and damon_hot_score. If auditd is deployed, search for PATH records under /sys/kernel/mm/damon/admin/ and SYSCALL write events by unexpected users, sudo sessions, scripts, or containers. Because this vulnerability does not inherently create persistent files or network traffic, detection is primarily host-log and kernel-crash based.

• /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/monitoring_attrs/intervals/sample_us
• /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/monitoring_attrs/intervals/aggr_us
• /sys/kernel/mm/damon/admin/kdamonds/0/state
• echo 0 > contexts/0/monitoring_attrs/intervals/sample_us
• echo 0 > contexts/0/monitoring_attrs/intervals/aggr_us
• echo commit > state
• Oops: divide error
• RIP: 0010:damon_hot_score
• damon_hot_score+0x
• damon_max_nr_accesses
• regions_score_histogram
• /sys/kernel/mm/damon/admin/

What your security team should do

• Prioritize patching Linux systems that expose DAMON sysfs controls and support multi-user, build, research, performance-testing, or container-host workloads where privileged local misuse is plausible.
• Inventory systems with /sys/kernel/mm/damon/admin/ present and determine whether DAMON is enabled or used by performance-management tooling.
• Apply the vendor-provided fixed kernel and reboot into the updated kernel where required.
• Restrict access to DAMON sysfs paths to trusted administrators and review sudo, container, and automation permissions that could allow arbitrary sysfs writes.
• Add monitoring for writes of 0 or abnormal values to DAMON interval files and for commits to DAMON state files.
• Search recent kernel logs for Oops, divide error, and damon_hot_score entries to identify possible prior exploitation or accidental triggering.
• If unexpected crashes are observed, preserve kernel logs, audit logs, and systemd journal data before reboot cleanup or log rotation removes evidence.