CVE-2025-40270 in Linux
Summary
by MITRE • 12/07/2025
In the Linux kernel, the following vulnerability has been resolved:
mm, swap: fix potential UAF issue for VMA readahead
Since commit 78524b05f1a3 ("mm, swap: avoid redundant swap device pinning"), the common helper for allocating and preparing a folio in the swap cache layer no longer tries to get a swap device reference internally, because all callers of __read_swap_cache_async are already holding a swap entry reference. The repeated swap device pinning isn't needed on the same swap device.
Caller of VMA readahead is also holding a reference to the target entry's swap device, but VMA readahead walks the page table, so it might encounter swap entries from other devices, and call __read_swap_cache_async on another device without holding a reference to it.
So it is possible to cause a UAF when swapoff of device A raced with swapin on device B, and VMA readahead tries to read swap entries from device A. It's not easy to trigger, but in theory, it could cause real issues.
Make VMA readahead try to get the device reference first if the swap device is a different one from the target entry.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 02/23/2026
This vulnerability exists within the linux kernel's memory management subsystem, specifically in the swap cache handling mechanism that governs how virtual memory areas interact with swap devices. The issue stems from a potential use-after-free condition that can occur during the process of virtual memory area readahead operations when dealing with multiple swap devices. The vulnerability was introduced through a code optimization in commit 78524b05f1a3 which eliminated redundant swap device pinning in the swap cache layer, assuming all callers already held appropriate swap entry references. However, this assumption proved incorrect for certain scenarios involving virtual memory area readahead operations that traverse page tables and may encounter swap entries from different devices without maintaining proper device references.
The technical flaw manifests when the virtual memory area readahead mechanism attempts to process swap entries from a swap device that differs from the target entry's device, while lacking the necessary reference to that specific swap device. This creates a race condition scenario where a swapoff operation on device A can occur simultaneously with swapin operations on device B, causing the readahead mechanism to attempt accessing freed memory structures when processing swap entries from device A. The vulnerability specifically affects the __read_swap_cache_async helper function which no longer attempts to acquire swap device references internally, relying instead on callers to maintain proper reference counts. This design change was intended to reduce redundant operations but inadvertently created a scenario where the virtual memory area readahead code could access swap devices without proper reference management.
The operational impact of this vulnerability extends beyond simple memory corruption, potentially enabling privilege escalation attacks and system instability. When the race condition occurs during concurrent swapoff and swapin operations, the use-after-free condition can lead to arbitrary code execution or system crashes, particularly in environments with multiple swap devices where readahead operations frequently traverse different swap entries. The vulnerability is particularly concerning in high-concurrency scenarios where multiple processes are simultaneously accessing swap space, as the timing requirements for triggering the race condition can be met through normal system operations. Security implications include potential information disclosure through memory corruption, denial of service through system crashes, and in worst-case scenarios, privilege escalation that could allow attackers to execute malicious code with kernel privileges.
Mitigation strategies should focus on ensuring proper reference management during virtual memory area readahead operations by implementing device reference acquisition before processing swap entries from different devices. The recommended solution involves modifying the virtual memory area readahead code to explicitly acquire swap device references when encountering swap entries from devices different from the target entry, thereby preventing the race condition that leads to the use-after-free scenario. System administrators should monitor for swap device operations during system maintenance windows and consider disabling swapoff operations during high-concurrency periods. The fix should be applied through kernel updates that incorporate the proper device reference handling for virtual memory area readahead operations, following the principle of least privilege in memory management operations. This vulnerability aligns with CWE-416, Use After Free, and maps to ATT&CK technique T1068, Exploitation for Privilege Escalation, through potential privilege escalation pathways that could arise from memory corruption in kernel space.