CVE-2026-23012
HIGHCVSS Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Lifecycle Timeline
3Description
In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: remove call_control in inactive contexts If damon_call() is executed against a DAMON context that is not running, the function returns error while keeping the damon_call_control object linked to the context's call_controls list. Let's suppose the object is deallocated after the damon_call(), and yet another damon_call() is executed against the same context. The function tries to add the new damon_call_control object to the call_controls list, which still has the pointer to the previous damon_call_control object, which is deallocated. As a result, use-after-free happens. This can actually be triggered using the DAMON sysfs interface. It is not easily exploitable since it requires the sysfs write permission and making a definitely weird file writes, though. Please refer to the report for more details about the issue reproduction steps. Fix the issue by making two changes. Firstly, move the final kdamond_call() for cancelling all existing damon_call() requests from terminating DAMON context to be done before the ctx->kdamond reset. This makes any code that sees NULL ctx->kdamond can safely assume the context may not access damon_call() requests anymore. Secondly, let damon_call() to cleanup the damon_call_control objects that were added to the already-terminated DAMON context, before returning the error.
Analysis
A use-after-free vulnerability in Linux kernel DAMON subsystem allows local users with sysfs write permissions to trigger memory corruption by calling damon_call() against inactive contexts, causing dangling pointers in the call_controls list. An attacker could leverage this to achieve information disclosure or denial of service, though exploitation complexity is moderate due to permission requirements. …
Sign in for full analysis, threat intelligence, and remediation guidance.
Remediation
Within 7 days: Identify all affected systems and apply vendor patches promptly. If patching is delayed, consider network segmentation to limit exposure.
Sign in for detailed remediation steps.
Priority Score
Vendor Status
Share
External POC / Exploit Code
Leaving vuln.today