CVE-2026-43388: mm/damon/core: clear walk_control on inactive context in damos_walk()
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/core: clear walkcontrol on inactive context in damoswalk()
damoswalk() sets ctx->walkcontrol to the caller-provided control structure before checking whether the context is running. If the context is inactive (damonisrunning() returns false), the function returns -EINVAL without clearing ctx->walkcontrol. This leaves a dangling pointer to a stack-allocated structure that will be freed when the caller returns.
This is structurally identical to the bug fixed in commit f9132fbc2e83 ("mm/damon/core: remove callcontrol in inactive contexts") for damoncall(), which had the same pattern of linking a control object and returning an error without unlinking it.
The dangling walkcontrol pointer can cause: 1. Use-after-free if the context is later started and kdamond dereferences ctx->walkcontrol (e.g., in damoswalkcancel() which writes to control->canceled and calls complete()) 2. Permanent -EBUSY from subsequent damoswalk() calls, since the stale pointer is non-NULL
Nonetheless, the real user impact is quite restrictive. The use-after-free is impossible because there is no damoswalk() callers who starts the context later. The permanent -EBUSY can actually confuse users, as DAMON is not running. But the symptom is kept only while the context is turned off. Turning it on again will make DAMON internally uses a newly generated damonctx object that doesn't have the invalid damoswalkcontrol pointer, so everything will work fine again.
Fix this by clearing ctx->walkcontrol under walkcontrollock before returning -EINVAL, mirroring the fix pattern from f9132fbc2e83.
Affected Software
Remediation
Event History
Frequently Asked Questions
Who is realistically exposed to exploitation?
The CVSS vector requires local access and low privileges. The report characterizes practical impact as highly restrictive and states that the use-after-free is impossible through the existing damos_walk() caller paths.
What behavior could indicate that the affected path was reached?
A stale non-NULL walk_control pointer can cause subsequent damos_walk() calls to return -EBUSY permanently.
Is a fix available?
Yes. A patch is available, with stable kernel references provided for the fix.