---
id: CVE-2026-74482
title: 'mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios'
summary: |-
  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) …
severity: high
cvss: 7.8
cvssVector: 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'
cvssSource: cna
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 <
    bc2f5eabaaf60ec18da70b619a8fba1bfb7dea3a
  - >-
    Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 <
    f87c08060818ebb19bafed37c38244538da25097
  - >-
    Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 <
    6f5c272d71845a669e4c8ee5c72b376e29a0e6e5
  - >-
    Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 <
    be106f7855f03d3128ed0ce70ba74b484a90b473
  - >-
    Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 <
    e3dd774dbfd0b5bc2dbd0995221751b1234f8205
  - >-
    Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 <
    10065fb891651d9541e7a5a2db84c1e656ece4f9
  - >-
    Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 <
    d640efe94d86d3be893d4c19220362546a637e90
  - >-
    Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 <
    e923bd21058ea02fd0dcd3549d151d143fd036e5
  - Linux 4.8
ssvc:
  exploitation: none
  automatable: 'no'
  technicalImpact: total
  timestamp: '2026-10-16T18:57:49.050841Z'
published: '2026-08-15'
updated: '2026-10-16'
sourceUpdated: '2026-10-16T19:05:49.129Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-74482'
references:
  - url: 'https://git.kernel.org/stable/c/bc2f5eabaaf60ec18da70b619a8fba1bfb7dea3a'
  - url: 'https://git.kernel.org/stable/c/f87c08060818ebb19bafed37c38244538da25097'
  - url: 'https://git.kernel.org/stable/c/6f5c272d71845a669e4c8ee5c72b376e29a0e6e5'
  - url: 'https://git.kernel.org/stable/c/be106f7855f03d3128ed0ce70ba74b484a90b473'
  - url: 'https://git.kernel.org/stable/c/e3dd774dbfd0b5bc2dbd0995221751b1234f8205'
  - url: 'https://git.kernel.org/stable/c/10065fb891651d9541e7a5a2db84c1e656ece4f9'
  - url: 'https://git.kernel.org/stable/c/d640efe94d86d3be893d4c19220362546a637e90'
  - url: 'https://git.kernel.org/stable/c/e923bd21058ea02fd0dcd3549d151d143fd036e5'
tags:
  - cve.org
epss: 0.00126
epssPercentile: 0.0203
ingestedAt: '2026-10-16T19:46:24.357Z'
---

## Overview

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.

## Affected

- `Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 < bc2f5eabaaf60ec18da70b619a8fba1bfb7dea3a`
- `Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 < f87c08060818ebb19bafed37c38244538da25097`
- `Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 < 6f5c272d71845a669e4c8ee5c72b376e29a0e6e5`
- `Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 < be106f7855f03d3128ed0ce70ba74b484a90b473`
- `Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 < e3dd774dbfd0b5bc2dbd0995221751b1234f8205`
- `Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 < 10065fb891651d9541e7a5a2db84c1e656ece4f9`
- `Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 < d640efe94d86d3be893d4c19220362546a637e90`
- `Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 < e923bd21058ea02fd0dcd3549d151d143fd036e5`
- `Linux 4.8`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.