CVE-2025-39877

What it actually does

state_show() in damon sysfs dereferences kdamond->damon_ctx without holding damon_sysfs_lock, creating a use-after-free window when damon_sysfs_turn_damon_on(), damon_sysfs_kdamonds_rm_dirs(), or damon_sysfs_kdamond_release() frees or replaces the context under the lock.

Why it matters to the business

Kernel memory corruption in the DAMON monitoring subsystem can lead to system crashes, denial of service, or local privilege escalation on Linux hosts, especially those running container-optimized images targeted by known threat actors.

How an attack unfolds

An attacker with local access races state_show() against damon_sysfs_turn_damon_on() or removal functions so that a freed damon_ctx is dereferenced and locked, enabling memory corruption; VMSCAPE and related container-optimized OS campaigns have demonstrated similar kernel primitives for escalation.

How to fix it

Upgrade the Linux kernel to commit 3858c44341ad49dc7544b19cc9f9ecffaa7cc50e or later stable releases containing the damon_sysfs_lock acquisition in state_show(); apply the corresponding Debian package updates once available for the running kernel.

How to confirm the fix worked

Confirm the running kernel contains commit 3858c44341ad49dc7544b19cc9f9ecffaa7cc50e, verify state_show() acquires damon_sysfs_lock before dereferencing damon_ctx, and test concurrent sysfs operations under load to ensure no UAF occurs.

Typical attack path

1. Obtain local unprivileged shell on affected Linux kernel
2. Trigger concurrent DAMON sysfs operations via crafted writes to /sys/kernel/mm/damon/
3. Race state_show() with context destruction under damon_sysfs_lock
4. Trigger use-after-free dereference and lock acquisition on freed ctx
5. Leverage resulting memory corruption for privilege escalation or DoS

How to detect it

Search kernel logs and audit trails for concurrent DAMON sysfs activity around crashes or oops involving damon_ctx or kdamond_lock; correlate with process activity from known container-optimized OS exploitation campaigns such as VMSCAPE.

What your security team should do

• Prioritize kernel upgrade to the fixed commit on all production systems within the next maintenance window
• Restrict unprivileged access to /sys/kernel/mm/damon/ via mount options or SELinux policies until patched
• Monitor for similar DAMON-related races reported under CVE-2025-39946 and CVE-2025-40018
• Include the fixed commit hash in vulnerability scanning signatures