7.8

CVE-2025-38554: linux Use After Free

CVSS: 7.8v3.1HighModified
AliasesUBUNTU-CVE-2025-38554
Published 19-08-2025Last modified 05-08-2026

Vulnerability summary

CVE-2025-38554 is a high (CVSS 7.8) Use After Free vulnerability in linux. EPSS estimates a 0.17% chance of exploitation in the next 30 days, higher than 6.5% of scored vulnerabilities.

Overall risk
31/100
0100
Medium · default modelHow is this calculated?
CVSS score
7.8/10
010
High · v3.1 (CVE.org)
EPSS score
0.17%
0%100%
Low · +0.01 pp in 30 days
KEVNot listedIn no KEV catalog
RansomwareNone recordedNo known use recorded
Public exploits0No public exploits recorded

Advisory lineage

Upstream 0 · Downstream 8 · Related 8

Timeline

  1. 19-08-2025
    PublishedVulnerability first disclosed.
  2. 05-08-2026
    Last modifiedVulnerability information updated.

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. [surenb@google.com: v3]

CVSS metrics

3 scores · 3 sources · 1 version

EPSS trend

Probability

0.17%

Chance of exploitation in the next 30 days

Percentile

7%

Versus all other CVEs

30-day change

+0.01 pp

From 0.17% on 21-09-2026

21-09-202621-10-2026
EPSS score
0.17%

Known exploited

Compare KEV catalogs

Not in any of the 3 tracked catalogs.

Public exploits

0 found

No public exploits indexed.

Weaknesses

CWE · root cause

Affected systems

Ubuntu83 products
  • linux-allwinner-5.19All versions (No fix recorded)
  • linux-aws-5.0All versions (No fix recorded)
  • linux-aws-5.11All versions (No fix recorded)
  • linux-aws-5.13All versions (No fix recorded)
  • linux-aws-5.19All versions (No fix recorded)
Linux2 products
  • linux≥ 3104138517fc66aad21f4a2487bb572e9fc2e3ec, < 6e88fe54721dee17d3496bc998f0c7d243896348 | ≥ 3104138517fc66aad21f4a2487bb572e9fc2e3ec, < 1bcd236a2536a451e385f8d6d2bb589689ec812f | ≥ 3104138517fc66aad21f4a2487bb572e9fc2e3ec, < 9bbffee67ffd16360179327b57f3b1245579ef08 | 6.15
  • linux_kernel≥ 6.15, < 6.15.10 | ≥ 6.16, < 6.16.1

2 vendors · 85 products

References

6 links