-
CVE-2025-38554
- EPSS 0.02%
- Published 19.08.2025 17:15:31
- Last modified 20.08.2025 14:40:17
- Source 416baaa9-dc9f-4396-8d5f-8c081f
- Teams watchlist Login
- Open Login
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. [surenb@google.com: v3]
Verknüpft mit AI von unstrukturierten Daten zu bestehenden CPE der NVD
This information is available to logged-in users. Login
Daten sind bereitgestellt durch das CVE Programm von einer CVE Numbering Authority (CNA) (Unstrukturiert).
VendorLinux
≫
Product
Linux
Default Statusunaffected
Version <
6e88fe54721dee17d3496bc998f0c7d243896348
Version
3104138517fc66aad21f4a2487bb572e9fc2e3ec
Status
affected
Version <
1bcd236a2536a451e385f8d6d2bb589689ec812f
Version
3104138517fc66aad21f4a2487bb572e9fc2e3ec
Status
affected
Version <
9bbffee67ffd16360179327b57f3b1245579ef08
Version
3104138517fc66aad21f4a2487bb572e9fc2e3ec
Status
affected
VendorLinux
≫
Product
Linux
Default Statusaffected
Version
6.15
Status
affected
Version <
6.15
Version
0
Status
unaffected
Version <=
6.15.*
Version
6.15.10
Status
unaffected
Version <=
6.16.*
Version
6.16.1
Status
unaffected
Version <=
*
Version
6.17-rc1
Status
unaffected
Zu dieser CVE wurde keine CISA KEV oder CERT.AT-Warnung gefunden.
Type | Source | Score | Percentile |
---|---|---|---|
EPSS | FIRST.org | 0.02% | 0.049 |
Source | Base Score | Exploit Score | Impact Score | Vector string |
---|