CVE-2026-90006: samples/damon/mtier: handle damon_stop() failure
In the Linux kernel, the following vulnerability has been resolved:
samples/damon/mtier: handle damonstop() failure
damonsamplemtierstop() assumes its damonstop() call will always successfully stops the two DAMON contexts. Hence it deallocates the two DAMON contexts after the damonstop() call. However, if a given context is already stopped, damonstop() fails and returns an error while letting the DAMON contexts that have not yet stopped keep running. This kind of unexpected early DAMON context stops could happen due to memory allocation failures in kdamondfn(). Because damonsamplemtierstop() just deallocates all DAMON contexts with damontarget and damonregion objects that are linked to the contexts, the execution of the unstopped DAMON context (kdamond) ends up using the memory that freed (use-after-free). Fix the issue by separating the damonstop() to be invoked per context.
Note that DAMONSYSFS also allows multiple DAMON contexts execution. But, it calls damonstop() for each context one by one. Hence this issue is only in mtier.
For the long term, it would be better to refactor damonstop() to always ensure stopping all contexts regardless of the failures in the middle. Make this fix in the current way, though, to keep it simple and easy to backport. I will do the refactoring later.
The issue was discovered [1] by Sashiko.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the kernel fix that updates samples/damon/mtier so damon_sample_mtier_stop() separates damon_stop() to be invoked per DAMON context (one by one). Handle damon_stop() failures in kdamond_fn() so stopping continues and all linked DAMON contexts are stopped regardless of failures in the middle.
Linux kernel samples/damon/mtier damon_sample_mtier_stop()/context stopping logic = Invoke damon_stop() per DAMON context (kdamond) and ensure all contexts are stopped even if damon_stop() fails mid-way
Event History
Frequently Asked Questions
Which systems are affected by this issue?
The issue is specific to the DAMON multi-tiering sample (samples/damon/mtier). DAMON_SYSFS is not affected because it stops each DAMON context individually.
What conditions are needed to trigger the use-after-free?
A DAMON context must stop unexpectedly, which can occur because of memory allocation failures in kdamond_fn(). When mtier later attempts to stop both contexts together, damon_stop() can fail after one context is already stopped while another remains running.
What happens when exploitation conditions occur?
The mtier stop path deallocates both DAMON contexts and their linked target and region objects even if one context is still running. The remaining kdamond execution can then access freed memory, resulting in a use-after-free.
What is the remediation?
Apply a kernel update containing the fix that invokes damon_stop() separately for each DAMON context. The referenced stable kernel commits contain the fix.