PT-2026-35004 · Linux · Linux
Published
2026-04-24
·
Updated
2026-04-24
·
CVE-2026-31652
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/stat: deallocate damon call() failure leaking damon ctx
damon stat start() always allocates the module's damon ctx object
(damon stat context). Meanwhile, if damon call() in the function fails,
the damon ctx object is not deallocated. Hence, if the damon call() is
failed, and the user writes Y to “enabled” again, the previously
allocated damon ctx object is leaked.
This cannot simply be fixed by deallocating the damon ctx object when
damon call() fails. That's because damon call() failure doesn't guarantee
the kdamond main function, which accesses the damon ctx object, is
completely finished. In other words, if damon stat start() deallocates
the damon ctx object after damon call() failure, the not-yet-terminated
kdamond could access the freed memory (use-after-free).
Fix the leak while avoiding the use-after-free by keeping returning
damon stat start() without deallocating the damon ctx object after
damon call() failure, but deallocating it when the function is invoked
again and the kdamond is completely terminated. If the kdamond is not yet
terminated, simply return -EAGAIN, as the kdamond will soon be terminated.
The issue was discovered [1] by sashiko.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux