CVE-2026-43388

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: clear walk_control on inactive context in damos_walk()<br /> <br /> damos_walk() sets ctx-&gt;walk_control to the caller-provided control<br /> structure before checking whether the context is running. If the context<br /> is inactive (damon_is_running() returns false), the function returns<br /> -EINVAL without clearing ctx-&gt;walk_control. This leaves a dangling<br /> pointer to a stack-allocated structure that will be freed when the caller<br /> returns.<br /> <br /> This is structurally identical to the bug fixed in commit f9132fbc2e83<br /> ("mm/damon/core: remove call_control in inactive contexts") for<br /> damon_call(), which had the same pattern of linking a control object and<br /> returning an error without unlinking it.<br /> <br /> The dangling walk_control pointer can cause:<br /> 1. Use-after-free if the context is later started and kdamond<br />    dereferences ctx-&gt;walk_control (e.g., in damos_walk_cancel()<br />    which writes to control-&gt;canceled and calls complete())<br /> 2. Permanent -EBUSY from subsequent damos_walk() calls, since the<br />    stale pointer is non-NULL<br /> <br /> Nonetheless, the real user impact is quite restrictive. The<br /> use-after-free is impossible because there is no damos_walk() callers who<br /> starts the context later. The permanent -EBUSY can actually confuse<br /> users, as DAMON is not running. But the symptom is kept only while the<br /> context is turned off. Turning it on again will make DAMON internally<br /> uses a newly generated damon_ctx object that doesn&amp;#39;t have the invalid<br /> damos_walk_control pointer, so everything will work fine again.<br /> <br /> Fix this by clearing ctx-&gt;walk_control under walk_control_lock before<br /> returning -EINVAL, mirroring the fix pattern from f9132fbc2e83.