Description
In the Linux kernel, the following vulnerability has been resolved:

mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios

__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.
Published: 2026-08-15
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

In the Linux kernel, a use‑after‑free flaw in the mm/huge_memory module is triggered when a huge anonymous shmem page is split. The kernel releases the i_mmap_rwsem lock before all after‑split folios are safely unlocked, allowing a mapping dereference to occur after the inode is freed. This race condition leads to a kernel‑mode memory corruption that can manifest as a crash or, if an attacker can control the conditions, an escalation of privileges. The vulnerability is a use‑after‑free defect.

Affected Systems

All Linux kernel releases that do not include the upstream patch reordering the unlock sequence are affected. Because the CNA does not list specific version ranges, any unsupported or legacy kernel that has not incorporated the fix is potentially at risk. The flaw resides in the core kernel and applies across all distributions that ship the unchanged kernel.

Risk and Exploitability

The CVSS score of 7.8 indicates moderate severity, and the EPSS score of <1% suggests exploitation is unlikely at present. Based on the description, it is inferred that a local attacker with sufficient privileges to generate memory pressure or manipulate shmem huge pages could trigger the race condition. The vulnerability is not listed in the CISA KEV catalog. Exploitation would require local access and the ability to induce the split operation, leading to a kernel panic or privilege escalation.

Generated by OpenCVE AI on August 21, 2026 at 20:40 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a kernel update that includes the upstream patch for the shmem THP split bug.
  • If an update is not available, manually cherry‑pick the patch that moves the i_mmap_rwsem unlock after remap_page to avoid the race.
  • As a temporary workaround, disable shmem huge pages by setting /sys/kernel/mm/transparent_hugepage/shmem_huge_enabled to never.

Generated by OpenCVE AI on August 21, 2026 at 20:40 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DSA Debian DSA DSA-6466-1 linux security update
History

Thu, 20 Aug 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-825
References
Metrics threat_severity

None

threat_severity

Moderate


Wed, 19 Aug 2026 17:00:00 +0000


Mon, 17 Aug 2026 14:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Mon, 17 Aug 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Mon, 17 Aug 2026 06:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Sat, 15 Aug 2026 16:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Sat, 15 Aug 2026 12:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios __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.
Title mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-19T16:37:38.544Z

Reserved: 2026-08-15T05:44:03.904Z

Link: CVE-2026-74482

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-15T13:17:53.053

Modified: 2026-08-19T17:21:05.477

Link: CVE-2026-74482

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-08-15T00:00:00Z

Links: CVE-2026-74482 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-21T20:45:03Z

Weaknesses