CVE-2026-43388

mm/damon/core: clear walk_control on inactive context in damos_walk()

HIGH
7.8
CVSS Score
Published: May 8, 2026 at 02:21 PM UTC
Updated: June 17, 2026 at 10:49 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.8
Exploit prediction
EPSS 0.1%

Description

In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: clear walk_control on inactive context in damos_walk() damos_walk() sets ctx->walk_control to the caller-provided control structure before checking whether the context is running. If the context is inactive (damon_is_running() returns false), the function returns -EINVAL without clearing ctx->walk_control. 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 call_control in inactive contexts") for damon_call(), which had the same pattern of linking a control object and returning an error without unlinking it. The dangling walk_control pointer can cause: 1. Use-after-free if the context is later started and kdamond    dereferences ctx->walk_control (e.g., in damos_walk_cancel()    which writes to control->canceled and calls complete()) 2. Permanent -EBUSY from subsequent damos_walk() 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 damos_walk() 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 damon_ctx object that doesn't have the invalid damos_walk_control pointer, so everything will work fine again. Fix this by clearing ctx->walk_control under walk_control_lock before returning -EINVAL, mirroring the fix pattern from f9132fbc2e83.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

6.14 ≤ v < 6.18.196.14 ≤ v < 6.19.96.14 ≤ v < 7.06.19 ≤ v < 6.19.96.147.0 rc17.0 rc27.0 rc3bf0eaba0ff9c9c8e6fd58ddfa1a8b6df4b813f61
Vendor states this is fixed in 9320c77134ab8d7701e20608bbf08517df4fa321 (fixed)
Vendor states this is fixed in ce0aa47c963b8c3e5beace89e2b5a665a64b5b6b (fixed)
Vendor states this is fixed in d210fdcac9c0d1380eab448aebc93f602c1cd4e6 (fixed)
Vendor states this is fixed in 6.14 (unaffected)
Vendor states this is fixed in 6.18.19 (unaffected)
Vendor states this is fixed in 6.19.9 (unaffected)
Vendor states this is fixed in 7.0 (unaffected)

CVSS

Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
HIGH
Integrity
HIGH
Availability
HIGH
Vector?

Quick Info

StatusANALYZED
CWE
CWE-416

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card