{"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:\n\nmm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios\n\n__folio_split() keeps dereferencing the mapping after the split:\nshmem_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.02028,"ingestedAt":"2026-10-16T19:46:24.357Z","slug":"CVE-2026-74482","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios\n\n__folio_split() keeps dereferencing the mapping after the split:\nshmem_uncharge(mapping->host) and remap_page() while the folios are still\nfrozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the\nafter-split folios have been unlocked and freed.\n\nNothing holds an inode reference across that.  The split relies on @folio\n-- which the beyond-EOF drop loop never removes, as it starts at\nfolio_next(folio) -- staying locked and in the page cache to hold off\neviction.  But the unlock loop unlocks @folio before i_mmap_unlock_read()\nruns.  If the caller's @lock_at is a tail beyond EOF, as memory_failure()\npasses when splitting a poisoned tail of a shmem THP that reaches past\ni_size during truncation, it too is gone from the page cache; so once\n@folio is unlocked no locked, in-cache folio pins the inode, and a\nconcurrent final iput() can evict and RCU-free it before\ni_mmap_unlock_read() touches i_mmap_rwsem:\n\n  BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790\n   i_mmap_unlock_read include/linux/fs.h:537 [inline]\n   __folio_split+0x732/0x1640 mm/huge_memory.c:4100\n   try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675\n   memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470\n\n  Freed by task 4601:\n   shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177\n   evict+0x57f/0xac0 fs/inode.c:870\n\nDo every mapping dereference while @folio still pins the inode: drop\ni_mmap_rwsem right after remap_page(), before the loop that unlocks and\nfrees the after-split folios, and clear @mapping so the exit path does not\nunlock it again.  shmem_uncharge() and remap_page() already run before\nthat point, so after this nothing past the unlock loop touches the inode\nor the mapping.\n\nThis is now a rule the split depends on, alongside keeping @folio frozen\nuntil the page cache is updated: no inode or mapping dereference once the\nafter-split folios start being unlocked.\n\n## Affected\n\n- `Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 < bc2f5eabaaf60ec18da70b619a8fba1bfb7dea3a`\n- `Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 < f87c08060818ebb19bafed37c38244538da25097`\n- `Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 < 6f5c272d71845a669e4c8ee5c72b376e29a0e6e5`\n- `Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 < be106f7855f03d3128ed0ce70ba74b484a90b473`\n- `Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 < e3dd774dbfd0b5bc2dbd0995221751b1234f8205`\n- `Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 < 10065fb891651d9541e7a5a2db84c1e656ece4f9`\n- `Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 < d640efe94d86d3be893d4c19220362546a637e90`\n- `Linux >= baa355fd331424526e742d41d9b90d5f9d10f716 < e923bd21058ea02fd0dcd3549d151d143fd036e5`\n- `Linux 4.8`\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"twilight","depthScore":43,"depthScoreParts":{"impact":42.9,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}