Look up another CVE · open CVE-2025-21949 in the interactive tracker
CVE-2025-21949
LoongArch: Set hugetlb mmap base address aligned with pmd size
Published 2025-04-01 (19 months ago) by the Linux kernel CNA. Subsystem arch/loongarch. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2025-21949 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 6.16.3-1 | Update the kernel and reboot. Fixed in 6.16.3-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.16.3-1 | Update the kernel and reboot. Fixed in 6.16.3-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
With ltp test case "testcases/bin/hugefork02", there is a dmesg error report message such as: kernel BUG at mm/hugetlb.c:5550! Oops - BUG[#1]: CPU: 0 UID: 0 PID: 1517 Comm: hugefork02 Not tainted 6.14.0-rc2+ #241 Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 pc 90000000004eaf1c ra 9000000000485538 tp 900000010edbc000 sp 900000010edbf940 a0 900000010edbfb00 a1 9000000108d20280 a2 00007fffe9474000 a3 00007ffff3474000 a4 0000000000000000 a5 0000000000000003 a6 00000000003cadd3 a7 0000000000000000 t0 0000000001ffffff t1 0000000001474000 t2 900000010ecd7900 t3 00007fffe9474000 t4 00007fffe9474000 t5 0000000000000040 t6 900000010edbfb00 t7 0000000000000001 t8 0000000000000005 u0 90000000004849d0 s9 900000010edbfa00 s0 9000000108d20280 s1 00007fffe9474000 s2 0000000002000000 s3 9000000108d20280 s4 9000000002b38b10 s5 900000010edbfb00 s6 00007ffff3474000 s7 0000000000000406 s8 900000010edbfa08 ra: 9000000000485538 unmap_vmas+0x130/0x218 ERA: 90000000004eaf1c __unmap_hugepage_range+0x6f4/0x7d0 PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) Process hugefork02 (pid: 1517, threadinfo=00000000a670eaf4, task=000000007a95fc64) Call Trace: [<90000000004eaf1c>] __unmap_hugepage_range+0x6f4/0x7d0 [<9000000000485534>] unmap_vmas+0x12c/0x218 [<9000000000494068>] exit_mmap+0xe0/0x308 [<900000000025fdc4>] mmput+0x74/0x180 [<900000000026a284>] do_exit+0x294/0x898 [<900000000026aa30>] do_group_exit+0x30/0x98 [<900000000027bed4>] get_signal+0x83c/0x868 [<90000000002457b4>] arch_do_signal_or_restart+0x54/0xfa0 [<90000000015795e8>] irqentry_exit_to_user_mode+0xb8/0x138 [<90000000002572d0>] tlb_do_page_fault_1+0x114/0x1b4 The problem is that base address allocated from hugetlbfs is not aligned with pmd size. Here add a checking for hugetlbfs and align base address with pmd size. After this patch the test case "testcases/bin/hugefork02" passes to run. This is similar to the commit 7f24cbc9c4d42db8a3c8484d1 ("mm/mmap: teach generic_get_unmapped_area{_topdown} to handle hugetlb mappings").
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
arch/loongarch/mm/mmap.c
- What this is
- LOONGARCHMAINTAINERS section matched on arch/loongarch/ · loongarch@lists.linux.dev · Maintained
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS Debian linux-config packages
Signals
- Published
- 2025-04-01 (19 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 7.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- arch/loongarch
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.19 | 6.13.7 | 242b34f48a37 |
| 5.19 | 6.14 | 3109d5ff484b |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The vulnerability is reached through the local `mmap()`/`munmap()` syscall interface on a LoongArch system; no network or remote input is involved.
- AC:LAttack complexity, low
- The mmap base is randomized and therefore essentially never PMD-aligned, and the attacker can force a misaligned hugetlb VMA deterministically by first creating an ordinary mapping of arbitrary page-multiple size; no race and no uncontrollable condition is involved, and CONFIG_HUGETLBFS is enabled in the LoongArch defconfig.
- PR:LPrivileges required, low
- Any unprivileged local user can call `mmap(MAP_ANONYMOUS|MAP_HUGETLB|MAP_NORESERVE)`, which uses HUGETLB_ANONHUGE_INODE and therefore bypasses the `can_do_hugetlb_shm()` capability check entirely, needs no hugetlbfs mount, and succeeds even with an empty hugepage pool.
- UI:NUser interaction, none
- The attacking process performs mmap and munmap (or simply exits) entirely on its own; no action by any other user is required.
- S:UScope, unchanged
- The corruption and crash occur within the kernel's own memory-management state on the same host; no VM, IOMMU, or other security-authority boundary is crossed.
- C:HConfidentiality impact, high
- The misaligned VMA causes a huge PMD entry to map up to PMD_SIZE-1 bytes beyond the VMA end and produces underflowed page-cache indices, so hugetlb pages become readable at addresses outside the mapping and can be aliased by unrelated later mappings; the resulting hugetlb folio refcount confusion via the THP split/zap paths yields a use-after-free read primitive on memory that can be reallocated elsewhere.
- I:HIntegrity impact, high
- The out-of-bounds huge PMD can overwrite an existing PTE-table pointer via `set_huge_pte_at()` and drives hugetlb folios through `__split_huge_pmd()`/`zap_huge_pmd()`, corrupting page tables and folio refcounts — an attacker-controlled write into memory outside the intended mapping.
- A:HAvailability impact, high
- `__unmap_hugepage_range()` hits an unconditional `BUG_ON(start & ~huge_page_mask(h))`, producing a kernel oops (panic with panic_on_oops) from inside `exit_mmap()` while mmap/hugetlb locks are held, leaving the system in an unrecoverable state; it is trivially and repeatedly triggerable by any user.