CVE-2025-38554
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-08-19

Last updated on: 2025-11-18

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: mm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped By inducing delays in the right places, Jann Horn created a reproducer for a hard to hit UAF issue that became possible after VMAs were allowed to be recycled by adding SLAB_TYPESAFE_BY_RCU to their cache. Race description is borrowed from Jann's discovery report: lock_vma_under_rcu() looks up a VMA locklessly with mas_walk() under rcu_read_lock(). At that point, the VMA may be concurrently freed, and it can be recycled by another process. vma_start_read() then increments the vma->vm_refcnt (if it is in an acceptable range), and if this succeeds, vma_start_read() can return a recycled VMA. In this scenario where the VMA has been recycled, lock_vma_under_rcu() will then detect the mismatching ->vm_mm pointer and drop the VMA through vma_end_read(), which calls vma_refcount_put(). vma_refcount_put() drops the refcount and then calls rcuwait_wake_up() using a copy of vma->vm_mm. This is wrong: It implicitly assumes that the caller is keeping the VMA's mm alive, but in this scenario the caller has no relation to the VMA's mm, so the rcuwait_wake_up() can cause UAF. The diagram depicting the race: T1 T2 T3 == == == lock_vma_under_rcu mas_walk <VMA gets removed from mm> mmap <the same VMA is reallocated> vma_start_read __refcount_inc_not_zero_limited_acquire munmap __vma_enter_locked refcount_add_not_zero vma_end_read vma_refcount_put __refcount_dec_and_test rcuwait_wait_event <finish operation> rcuwait_wake_up [UAF] Note that rcuwait_wait_event() in T3 does not block because refcount was already dropped by T1. At this point T3 can exit and free the mm causing UAF in T1. To avoid this we move vma->vm_mm verification into vma_start_read() and grab vma->vm_mm to stabilize it before vma_refcount_put() operation. [[email protected]: v3]
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-08-19
Last Modified
2025-11-18
Generated
2026-05-06
AI Q&A
2025-08-19
EPSS Evaluated
2026-05-05
NVD
CVE-2025-38554
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-416 The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a use-after-free (UAF) issue in the Linux kernel's memory management related to virtual memory areas (VMAs). It occurs when a VMA's associated memory descriptor (mm) is freed after the VMA's reference count (vm_refcnt) is dropped. Due to a race condition involving concurrent access and recycling of VMAs, a process can access a VMA that has been freed and reallocated, leading to a UAF scenario. The problem arises because the code assumes the caller keeps the VMA's mm alive, but in this race condition, it does not, causing the rcuwait_wake_up() function to operate on freed memory.


How can this vulnerability impact me? :

This vulnerability can lead to use-after-free conditions in the Linux kernel, which may cause system instability, crashes, or potentially allow an attacker to execute arbitrary code with kernel privileges. Exploiting this flaw could compromise system security by enabling privilege escalation or denial of service.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is fixed by updating the Linux kernel to a version that includes the patch which moves vma->vm_mm verification into vma_start_read() and stabilizes it before vma_refcount_put() operation. Therefore, the immediate step is to apply the kernel update or patch that addresses this use-after-free issue.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart