CVE-2025-21693: Linux Kernel Use-After-Free Vulnerability

CVE-2025-21693 Overview

CVE-2025-21693 is a Use-After-Free (UAF) vulnerability in the Linux kernel's zswap memory subsystem. The flaw exists in the zswap_compress() and zswap_decompress() functions, where improper synchronization during CPU hotunplug events can lead to the use of freed memory resources. This vulnerability affects systems using zswap for compressed swap caching, potentially allowing local attackers to achieve privilege escalation or cause system instability.

The vulnerability was introduced in commit 1ec3b5fe6eec when the kernel switched to the crypto_acomp API for hardware acceleration. The original implementation used get_cpu_ptr() which disabled preemption, preventing CPU migration during critical operations. However, the new crypto_acomp API requires a sleepable context, making it impossible to disable preemption, thus creating a race condition window.

Critical Impact

Local attackers with low privileges can potentially exploit this Use-After-Free condition to achieve privilege escalation, execute arbitrary code in kernel context, or cause denial of service through system crashes.

Affected Products

• Linux Kernel versions prior to patched releases
• Linux Kernel 6.13-rc1 through 6.13-rc7
• Systems with zswap enabled and CPU hotplug capability

Discovery Timeline

• February 10, 2025 - CVE-2025-21693 published to NVD
• April 16, 2025 - Last updated in NVD database

Technical Details for CVE-2025-21693

Vulnerability Analysis

The vulnerability stems from a race condition in the zswap memory compression subsystem. When zswap_compress() or zswap_decompress() is called, the function retrieves the per-CPU acomp_ctx (asynchronous compression context) for the current CPU. However, since neither preemption nor migration are disabled, the executing thread can be migrated to a different CPU while still holding a reference to the original CPU's acomp_ctx.

If the original CPU is subsequently hotunplugged, the zswap_cpu_comp_dead() callback frees the resources associated with that CPU's acomp_ctx, including acomp_ctx.buffer, acomp_ctx.req, and acomp_ctx.acomp. The migrated thread then continues to use these freed resources, resulting in a classic Use-After-Free condition.

The CWE-416 (Use After Free) classification accurately describes this vulnerability, as freed memory is accessed after deallocation, potentially corrupting memory or allowing code execution through carefully crafted memory contents.

Root Cause

The root cause is the lack of proper synchronization between CPU hotplug events and compression/decompression operations in zswap. When the kernel transitioned from the crypto_comp API to the crypto_acomp API for hardware acceleration support, the original protection mechanism (get_cpu_ptr() which disables preemption) could no longer be used because crypto_acomp requires a sleepable context.

The fix implements synchronization using acomp_ctx.mutex to coordinate between CPU hotplug callbacks and compression/decompression paths. The mutex initialization was also moved from the CPU hotplug callback to pool initialization to prevent race conditions during mutex reinitialization.

Attack Vector

The attack vector is local, requiring an attacker to have low-privileged access to the target system. Exploitation involves triggering memory pressure to invoke zswap compression/decompression operations while simultaneously causing CPU hotunplug events. This is a complex attack that requires precise timing but does not require user interaction.

The attacker would need to:

1. Trigger sufficient memory pressure to invoke zswap operations
2. Time a CPU hotunplug event during the compression/decompression operation
3. Exploit the UAF condition to potentially execute code or escalate privileges

No proof-of-concept exploit code is currently publicly available. The vulnerability requires local access and specific system configurations (zswap enabled, CPU hotplug capability) to be exploitable.

Detection Methods for CVE-2025-21693

Indicators of Compromise

• Unexpected kernel panics or crashes related to memory corruption in zswap subsystem
• System log entries showing memory access violations in zswap_compress() or zswap_decompress() functions
• Unusual CPU hotplug activity combined with high memory pressure
• KASAN (Kernel Address Sanitizer) reports indicating use-after-free in mm/zswap.c

Detection Strategies

• Deploy kernel memory debugging tools such as KASAN to detect UAF conditions
• Monitor for kernel oops or panic messages containing references to zswap functions
• Implement system call auditing to detect unusual patterns of CPU affinity manipulation
• Use ftrace or eBPF probes to monitor zswap_compress() and zswap_decompress() invocations during CPU hotplug events

Monitoring Recommendations

• Configure kernel crash dump collection (kdump) to capture forensic data from kernel crashes
• Enable kernel audit logging for CPU hotplug events
• Monitor system memory pressure indicators alongside CPU topology changes
• Implement SentinelOne Singularity XDR for real-time kernel-level threat detection and behavioral analysis

How to Mitigate CVE-2025-21693

Immediate Actions Required

• Apply the latest kernel security patches from your Linux distribution
• Consider temporarily disabling zswap if CPU hotplug is required and patching is not immediately possible
• Restrict local access to trusted users until patches are applied
• Monitor systems for unusual memory-related kernel crashes

Patch Information

The Linux kernel developers have released patches to address this vulnerability. The fix implements proper synchronization using acomp_ctx.mutex between CPU hotplug callbacks and compression/decompression paths. Additionally, the patch ensures acomp_ctx.req is set to NULL when resources are freed, allowing compression/decompression paths to detect CPU offline status and retry on a different CPU.

Patches are available at:

• Kernel Git Commit 12dcb0ef540629a281533f9dedc1b6b8e14cfb65
• Kernel Git Commit 8d29ff5d50304daa41dc3cfdda4a9d1e46cf5be1

Workarounds

• Disable zswap by adding zswap.enabled=0 to kernel boot parameters
• Prevent CPU hotunplug operations on production systems where possible
• Limit physical and local access to affected systems
• Use containerization or virtualization to isolate workloads from kernel-level vulnerabilities

# Disable zswap at boot (add to GRUB configuration)
GRUB_CMDLINE_LINUX="zswap.enabled=0"

# Verify zswap status
cat /sys/module/zswap/parameters/enabled

# Check current kernel version
uname -r

# Apply kernel updates (Debian/Ubuntu)
sudo apt update && sudo apt upgrade linux-image-$(uname -r)

# Apply kernel updates (RHEL/CentOS)
sudo yum update kernel