CVE-2026-68165: Patch Linux DAMON Divide-by-Zero Flaw

The newly published CVE tracks a six-line validation added to

, inside

. The change rejects ranges whose effective start is at or beyond their effective end, returning

before DAMON rearranges its monitoring regions. It is small code, but it is positioned at the one common handoff used by the relevant DAMON callers, which is why it fixes more than the specific sysfs example in the advisory.

The NVD entry currently carries no CVSS assessment, no CWE classification, and no exploitation status. That absence should not be read as evidence of either low impact or active exploitation. It reflects a record published before NVD enrichment, and the kernel material describes a reproducible invalid-input crash condition rather than a completed privilege-escalation chain.

An invalid memory range reaches DAMON’s core​

DAMON represents a monitored address span as a start and end pair. Its core logic assumes that a region has positive length:

. That invariant was not enforced consistently at the interface boundary.

The Linux kernel mailing-list posting from DAMON maintainer SJ Park describes three ways bad input can arrive at the core: the DAMON sysfs interface, DAMON_RECLAIM, and DAMON_LRU_SORT. DAMON_RECLAIM is the proactive memory-reclamation facility that identifies cold memory and can page it out under configured memory-pressure conditions. DAMON_LRU_SORT uses DAMON data to promote and demote pages on the kernel’s LRU lists.

Both are administrative tuning facilities, not ordinary desktop features. Linux’s documentation says DAMON_RECLAIM and DAMON_LRU_SORT are enabled and configured through kernel module parameters, including

and

; the DAMON sysfs interface lives beneath

when

is enabled. The upstream documentation also notes that the DAMON admin directory is for root use.

The CVE’s proof sequence uses the sysfs route. It creates a region with both

and

set to zero, then commits the modified configuration. On a kernel compiled with

, the monitor worker emits a warning that the start address is greater than or equal to the end address.

That configuration option is primarily intended for DAMON development and test coverage, so the visible warning is more likely on development, test, custom-kernel, and CI systems than on a conventional distribution kernel. The more important defect is behind it: kernel code later merges regions under the assumption that their sizes are non-zero. An empty region breaks that math.

The patch validates aligned addresses, not only the literal input​

The eventual fix does more than check whether the supplied

value is numerically smaller than

. It applies DAMON’s minimum-region-size alignment before comparing them.

That detail matters. DAMON works with region granularity, so two apparently different input values can collapse to the same effective boundary after alignment. A simplistic

validation could accept a tiny range that becomes zero-length in the subsystem’s actual representation. The finalized validation rejects a range when the aligned start is at or beyond the aligned end.

This is a sensible place to fix the defect. Rather than making DAMON_SYSFS, DAMON_RECLAIM, and DAMON_LRU_SORT each implement their own version of range validation,

now becomes the shared gatekeeper. The Linux 7.2-rc5 change log independently lists the commit alongside a related change that disallows overlapping input ranges, suggesting maintainers are tightening the broader contract for caller-provided DAMON regions rather than treating this as a one-off warning cleanup.

There is a limitation to keep in mind: this patch protects callers that reach the shared

implementation. The originating bug was associated with the introduction of DAMON_RECLAIM, but the common helper arrived later. That history creates an awkward version picture.

The CVE’s version data needs more careful reading than “5.16 and later”​

The CVE record identifies Linux 5.16 as the start of the affected code lineage because DAMON_RECLAIM entered there. It also lists fixed stable-kernel points: Linux 6.6.148, 6.12.101, 6.18.42, and 7.1.6, with Linux 7.2-rc5 identified as containing the upstream fix.

Taken literally, that data invites the conclusion that every kernel from 5.16 onward is exposed in exactly the same way. The patch discussion says otherwise. Park explicitly noted that

did not exist in the original buggy commit and that the first long-term-support branch with both that helper and all relevant callers was Linux 6.1.y.

That does not make Linux 5.16 through 6.0 safe. It means the upstream fix cannot simply be transplanted unchanged into every historical branch. Older kernels can contain the broader class of bad-input handling problem through different DAMON caller code, while newer branches can be fixed centrally. The CVE’s structured affected-version data captures the lineage; the patch discussion captures the implementation reality. Administrators should use both.

For current upstream stable lines, the useful patch thresholds are:

• Linux 6.6 systems should be on 6.6.148 or a distribution kernel that has backported the corresponding fix.
• Linux 6.12 systems should be on 6.12.101 or an equivalent vendor-patched build.
• Linux 6.18 systems should be on 6.18.42 or an equivalent vendor-patched build.
• Linux 7.1 systems should be on 7.1.6 or newer, while the upstream development fix is present in Linux 7.2-rc5.

The record does not name a fixed 6.1 release. That is especially important for fleets still running a 6.1-derived enterprise or appliance kernel: do not infer safety from the presence of

alone, and do not infer exposure from the upstream version number alone. Check the vendor’s kernel changelog or source package for the backport. Enterprise distributions commonly apply security and stability fixes without changing their base upstream version.

Who needs to act now​

The widest population of Linux machines is unlikely to be directly exposed through an unprivileged local account. DAMON’s configuration surfaces are administrative, and the module parameters shown in upstream source are owner-writable. A user who can alter the affected sysfs hierarchy or write DAMON module settings generally already has substantial control over kernel behavior.

That sharply limits the standalone security value of this CVE as a privilege-escalation target. There is no public exploit referenced by the CVE record or the upstream patch material, and no public reporting found for active exploitation. Calling it an arbitrary local-user kernel compromise would overstate what the record supports.

It is still a patch-worthy bug for systems where memory-management controls are automated. A privileged orchestration agent, test harness, performance-tuning script, or a management service with delegated root-level access can accidentally generate a zero-length range. The outcome can be a warning, a crash, or a disrupted DAMON worker at precisely the time the host is trying to manage memory pressure. For DAMON_RECLAIM and DAMON_LRU_SORT users, that can mean a reliability failure in the part of the system intended to reduce memory stress.

Windows users running Linux through WSL, Hyper-V virtual machines, Docker hosts, Kubernetes nodes, or dual-boot setups should focus on the Linux kernel actually running the workload. This CVE does not affect the Windows kernel. It can affect a Linux guest or host if that kernel includes the vulnerable DAMON code and exposes one of the affected configuration paths.

Patch the kernel, then audit DAMON automation​

The immediate remediation is to take the vendor’s kernel update containing the upstream fix or confirm that the distribution has backported it. A restart into the new kernel is required unless the vendor explicitly supplies and supports a live patch for this specific change.

Administrators who use DAMON should also review automation that writes

,

, or DAMON sysfs region files. Treat start-and-end validation as a client-side requirement even after the kernel patch: reject empty or inverted ranges before committing them, and ensure the values remain valid after any address-unit conversion or alignment logic.

The larger lesson is straightforward. DAMON’s interfaces are designed for advanced memory-management work, and the kernel now rejects one malformed configuration the subsystem should never have accepted. Systems that do not enable DAMON or delegate access to its controls have little reason to treat CVE-2026-68165 as an emergency. Systems that rely on DAMON_RECLAIM, DAMON_LRU_SORT, or custom DAMON sysfs automation should move to the fixed kernel line and verify their tooling does not recreate the invalid range the new validation was added to stop.