CVE-2026-74482
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:
Leer descripción completaMostrar menos
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.
Detalles técnicos trazas, registros y código del informe original
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
CVSS
- Versión: 3.1
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Puntuación base: 7.8
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días: 0.13%
- Percentil entre todas las CVEs puntuadas: 2
- Fecha de la puntuación: 5/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
🎯 Técnicas ATT&CK
Cómo se explota esta vulnerabilidad y qué consigue el atacante, en el lenguaje de MITRE ATT&CK.
- Explotación
T1068Exploitation for Privilege Escalationprivilege escalation85 % - Impacto principal
T1499.004Application or System Exploitationimpact75 % - Impacto secundario
T1565.001Stored Data Manipulationimpact60 %
Vulnerabilidad local (AV:L/PR:L) en kernel Linux que permite escalada de privilegios mediante race condition en liberación de memoria; potencial DoS por corrupción de estado del sistema.
Inferido por nuestro agente de análisis a partir de la descripción oficial, el vector CVSS y la CWE, y comprobado por un supervisor. Puede contener errores.
🛡️ Mitigaciones ATT&CK que cubren estas técnicas
Tecnologías afectadas (1)
⚠ Inferidas por IA a partir de la descripción — NVD aún no ha analizado esta CVE; no son CPE verificados.
Referencias
- https://git.kernel.org/stable/c/10065fb891651d9541e7a5a2db84c1e656ece4f9
- https://git.kernel.org/stable/c/6f5c272d71845a669e4c8ee5c72b376e29a0e6e5
- https://git.kernel.org/stable/c/bc2f5eabaaf60ec18da70b619a8fba1bfb7dea3a
- https://git.kernel.org/stable/c/be106f7855f03d3128ed0ce70ba74b484a90b473
- https://git.kernel.org/stable/c/d640efe94d86d3be893d4c19220362546a637e90
- https://git.kernel.org/stable/c/e3dd774dbfd0b5bc2dbd0995221751b1234f8205
- https://git.kernel.org/stable/c/e923bd21058ea02fd0dcd3549d151d143fd036e5
- https://git.kernel.org/stable/c/f87c08060818ebb19bafed37c38244538da25097
JSON original (NVD)
Mostrar
{
"id": "CVE-2026-74482",
"cveTags": [],
"metrics": {
"cvssMetricV31": [
{
"type": "Secondary",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"cvssData": {
"scope": "UNCHANGED",
"version": "3.1",
"baseScore": 7.8,
"attackVector": "LOCAL",
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"integrityImpact": "HIGH",
"userInteraction": "NONE",
"attackComplexity": "LOW",
"availabilityImpact": "HIGH",
"privilegesRequired": "LOW",
"confidentialityImpact": "HIGH"
},
"impactScore": 5.9,
"exploitabilityScore": 1.8
}
]
},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "baa355fd331424526e742d41d9b90d5f9d10f716",
"lessThan": "bc2f5eabaaf60ec18da70b619a8fba1bfb7dea3a",
"versionType": "git"
},
{
"status": "affected",
"version": "baa355fd331424526e742d41d9b90d5f9d10f716",
"lessThan": "f87c08060818ebb19bafed37c38244538da25097",
"versionType": "git"
},
{
"status": "affected",
"version": "baa355fd331424526e742d41d9b90d5f9d10f716",
"lessThan": "6f5c272d71845a669e4c8ee5c72b376e29a0e6e5",
"versionType": "git"
},
{
"status": "affected",
"version": "baa355fd331424526e742d41d9b90d5f9d10f716",
"lessThan": "be106f7855f03d3128ed0ce70ba74b484a90b473",
"versionType": "git"
},
{
"status": "affected",
"version": "baa355fd331424526e742d41d9b90d5f9d10f716",
"lessThan": "e3dd774dbfd0b5bc2dbd0995221751b1234f8205",
"versionType": "git"
},
{
"status": "affected",
"version": "baa355fd331424526e742d41d9b90d5f9d10f716",
"lessThan": "10065fb891651d9541e7a5a2db84c1e656ece4f9",
"versionType": "git"
},
{
"status": "affected",
"version": "baa355fd331424526e742d41d9b90d5f9d10f716",
"lessThan": "d640efe94d86d3be893d4c19220362546a637e90",
"versionType": "git"
},
{
"status": "affected",
"version": "baa355fd331424526e742d41d9b90d5f9d10f716",
"lessThan": "e923bd21058ea02fd0dcd3549d151d143fd036e5",
"versionType": "git"
}
],
"programFiles": [
"mm/huge_memory.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "4.8"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "4.8",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "5.10.265",
"versionType": "semver",
"lessThanOrEqual": "5.10.*"
},
{
"status": "unaffected",
"version": "5.15.216",
"versionType": "semver",
"lessThanOrEqual": "5.15.*"
},
{
"status": "unaffected",
"version": "6.1.183",
"versionType": "semver",
"lessThanOrEqual": "6.1.*"
},
{
"status": "unaffected",
"version": "6.6.151",
"versionType": "semver",
"lessThanOrEqual": "6.6.*"
},
{
"status": "unaffected",
"version": "6.12.103",
"versionType": "semver",
"lessThanOrEqual": "6.12.*"
},
{
"status": "unaffected",
"version": "6.18.44",
"versionType": "semver",
"lessThanOrEqual": "6.18.*"
},
{
"status": "unaffected",
"version": "7.1.8",
"versionType": "semver",
"lessThanOrEqual": "7.1.*"
},
{
"status": "unaffected",
"version": "7.2",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"mm/huge_memory.c"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-08-15T13:17:53.053",
"references": [
{
"url": "https://git.kernel.org/stable/c/10065fb891651d9541e7a5a2db84c1e656ece4f9",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/6f5c272d71845a669e4c8ee5c72b376e29a0e6e5",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/bc2f5eabaaf60ec18da70b619a8fba1bfb7dea3a",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/be106f7855f03d3128ed0ce70ba74b484a90b473",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/d640efe94d86d3be893d4c19220362546a637e90",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/e3dd774dbfd0b5bc2dbd0995221751b1234f8205",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/e923bd21058ea02fd0dcd3549d151d143fd036e5",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/f87c08060818ebb19bafed37c38244538da25097",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Received",
"descriptions": [
{
"lang": "en",
"value": "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) 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."
}
],
"lastModified": "2026-08-19T17:21:05.477",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}