Look up another CVE · open CVE-2026-74482 in the interactive tracker
CVE-2026-74482
mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem mm. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-74482 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 | fixedDLA-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6466-1 · 2026-08-25 · text | 6.12.105-1 | Update the kernel and reboot. DSA-6466-1 shipped the fix on 2026-08-25, in 6.12.105-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.8-1 | Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.8-1 | Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4788-1 · 2026-09-19 · text | 6.12.107-1~deb12u1 | Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
__folio_split() keeps dereferencing the mapping after the split: shmem_uncharge(mapping->host) and remap_page() while the folios are still frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the after-split folios have been unlocked and freed. Nothing holds an inode reference across that. The split relies on @folio -- which the beyond-EOF drop loop never removes, as it starts at folio_next(folio) -- staying locked and in the page cache to hold off eviction. But the unlock loop unlocks @folio before i_mmap_unlock_read() runs. If the caller's @lock_at is a tail beyond EOF, as memory_failure() passes when splitting a poisoned tail of a shmem THP that reaches past i_size during truncation, it too is gone from the page cache; so once @folio is unlocked no locked, in-cache folio pins the inode, and a concurrent final iput() can evict and RCU-free it before i_mmap_unlock_read() touches i_mmap_rwsem: BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790 i_mmap_unlock_read include/linux/fs.h:537 [inline] __folio_split+0x732/0x1640 mm/huge_memory.c:4100 try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675 memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470 Freed by task 4601: shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177 evict+0x57f/0xac0 fs/inode.c:870 Do every mapping dereference while @folio still pins the inode: drop i_mmap_rwsem right after remap_page(), before the loop that unlocks and frees the after-split folios, and clear @mapping so the exit path does not unlock it again. shmem_uncharge() and remap_page() already run before that point, so after this nothing past the unlock loop touches the inode or the mapping. This is now a rule the split depends on, alongside keeping @folio frozen until the page cache is updated: no inode or mapping dereference once the after-split folios start being unlocked.
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.
mm/huge_memory.c
- What this is
- MEMORY MANAGEMENT - THP (TRANSPARENT HUGE PAGE)MAINTAINERS section matched on mm/huge_memory.c · linux-mm@kvack.org · Maintained
Check it on the machine
grep -w CONFIG_TRANSPARENT_HUGEPAGE /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormYnot built on amd64/rt/amd64, arm64/rt/arm64, armhf/armmp, armhf/rt/armmp, i386/rt/686-pae
- trixieYnot built on amd64/rt/amd64, arm64/rt/arm64, armel/rpi, armhf/armmp, armhf/rt/armmp
- forky, sidYnot built on amd64/rt-amd64, arm64/rt-arm64, armhf/armmp
- bookworm · linux-6.12Ynot built on amd64/rt/amd64, arm64/rt/arm64, armhf/armmp, armhf/rt/armmp
- Y
- built in where it is built at all; some flavours do not build it
- Build switch
- CONFIG_TRANSPARENT_HUGEPAGE
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 kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-15 (2 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.13%, higher than 2.0% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- mm
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.8 | 5.10.265 | bc2f5eabaaf6 |
| 4.8 | 5.15.216 | f87c08060818 |
| 4.8 | 6.1.183 | 6f5c272d7184 |
| 4.8 | 6.6.151 | be106f7855f0 |
| 4.8 | 6.12.103 | e3dd774dbfd0 |
| 4.8 | 6.18.44 | 10065fb89165 |
| 4.8 | 7.1.8 | d640efe94d86 |
| 4.8 | 7.2 | e923bd21058e |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4788-1 | 2026-09-19 | bookworm 6.12.107-1~deb12u1 | tracker |
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
| DSA-6466-1 | 2026-08-25 | trixie 6.12.105-1 | tracker |
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 UAF is in __folio_split() on the memory_failure()->try_to_split_thp_page() path while splitting file-backed shmem THPs; reachability is via local syscalls (memfd/mmap/madvise/ftruncate) or admin hwpoison injection, not network or physical interfaces.
- AC:LAttack complexity, low
- An attacker can deterministically create a shmem THP with tail pages beyond EOF and race MADV_HWPOISON-driven memory_failure() against concurrent truncate/close(iput) using attacker-controlled threads; both sides of the race are attacker-driven.
- PR:LPrivileges required, low
- Reliable exploitation uses MADV_HWPOISON to invoke memory_failure() on a chosen tail page; CAP_SYS_ADMIN is available to user-namespace/container root, and the shmem THP setup needs only ordinary local mapping and truncation privileges.
- UI:NUser interaction, none
- No separate victim action is required; the attacker creates, maps, poisons, and truncates their own memfd/shmem/tmpfs object to reach the vulnerable split path.
- S:UScope, unchanged
- Impact is a kernel slab use-after-free on inode/mapping metadata in core MM within the same kernel security domain, not a VM escape, sandbox breakout, or other cross-authority boundary violation.
- C:HConfidentiality impact, high
- KASAN reports slab-use-after-free in i_mmap_unlock_read() after shmem_free_in_core_inode() RCU-frees the inode; this inode/mapping UAF can be heap-sprayed into an arbitrary kernel memory read primitive.
- I:HIntegrity impact, high
- The same UAF corrupts freed inode slab objects and i_mmap_rwsem state, enabling heap grooming for arbitrary kernel writes and potential privilege escalation via control-flow hijacking per kernel UAF guidance.
- A:HAvailability impact, high
- The use-after-free provokes a KASAN BUG/oops during i_mmap_unlock_read() and corrupts core MM inode state, capable of kernel panic or hang when triggered on production shmem/tmpfs workloads.