CVE-2026-23012

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: remove call_control in inactive contexts<br /> <br /> If damon_call() is executed against a DAMON context that is not running,<br /> the function returns error while keeping the damon_call_control object<br /> linked to the context&amp;#39;s call_controls list. Let&amp;#39;s suppose the object is<br /> deallocated after the damon_call(), and yet another damon_call() is<br /> executed against the same context. The function tries to add the new<br /> damon_call_control object to the call_controls list, which still has the<br /> pointer to the previous damon_call_control object, which is deallocated. <br /> As a result, use-after-free happens.<br /> <br /> This can actually be triggered using the DAMON sysfs interface. It is not<br /> easily exploitable since it requires the sysfs write permission and making<br /> a definitely weird file writes, though. Please refer to the report for<br /> more details about the issue reproduction steps.<br /> <br /> Fix the issue by making two changes. Firstly, move the final<br /> kdamond_call() for cancelling all existing damon_call() requests from<br /> terminating DAMON context to be done before the ctx-&gt;kdamond reset. This<br /> makes any code that sees NULL ctx-&gt;kdamond can safely assume the context<br /> may not access damon_call() requests anymore. Secondly, let damon_call()<br /> to cleanup the damon_call_control objects that were added to the<br /> already-terminated DAMON context, before returning the error.