CVE-2026-89760 (GCVE-0-2026-89760)
Vulnerability from cvelistv5
Published
2026-09-11 19:47
Modified
2026-10-19 08:52
Severity ?
VLAI Severity ?
EPSS score ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
mm, swap: don't free a hibernation slot that is in the swap cache
A slot with a folio in the swap cache is freed when the folio leaves the
cache, not when its count drops. swap_put_entries_cluster() follows that
rule. swap_free_hibernation_slot() does not, it calls
__swap_cluster_free_entries() whether or not a folio sits on the slot.
Cluster readahead can put one there. It walks a raw page_cluster sized
window of offsets around the faulting entry, and a hibernation slot passes
__swap_cache_add_check() because it is not a folio and its count is not
zero. Freeing the slot then clears the entry under that folio.
The folio is now unreachable from the swap table, and the offset goes back
to the allocator. The folio is still on the LRU though, so reclaim can
pick it up later. It then takes the old offset out of folio->swap and
overwrites the table entry there, which by then may belong to someone
else.
This bug can trigger silent memory corruption, process crashes, or data
instability across completely unrelated userspace applications - typically
occurring when uswsusp is preparing the hibernation image.
I found this while working on giving hibernation slots their own marker in
the swap table, which I had discussed with Kairui.
(https://lore.kernel.org/linux-mm/abp7aDgYLrxF3Me8@KASONG-MC4/) As far as
I know there are no reports, so there is no Reported-by/Closes to add.
Check for a cached folio before freeing. The slot is then left in the
ordinary state where only the swap cache holds it, and it is freed when
the folio leaves the cache, either through the reclaim below or through
normal reclaim later.
References
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"mm/swapfile.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "a6df73156f2d85746c69adbf13d0f5ea200e0626",
"status": "affected",
"version": "0d6af9bcf383bcdf601e670bb605861b01e318e7",
"versionType": "git"
},
{
"lessThan": "10d9012e83efedde8718ceaa5053f836e0c8596c",
"status": "affected",
"version": "0d6af9bcf383bcdf601e670bb605861b01e318e7",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"mm/swapfile.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "7.1"
},
{
"lessThan": "7.1",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.2.4",
"versionStartIncluding": "7.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.3",
"versionStartIncluding": "7.1",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm, swap: don\u0027t free a hibernation slot that is in the swap cache\n\nA slot with a folio in the swap cache is freed when the folio leaves the\ncache, not when its count drops. swap_put_entries_cluster() follows that\nrule. swap_free_hibernation_slot() does not, it calls\n__swap_cluster_free_entries() whether or not a folio sits on the slot.\n\nCluster readahead can put one there. It walks a raw page_cluster sized\nwindow of offsets around the faulting entry, and a hibernation slot passes\n__swap_cache_add_check() because it is not a folio and its count is not\nzero. Freeing the slot then clears the entry under that folio.\n\nThe folio is now unreachable from the swap table, and the offset goes back\nto the allocator. The folio is still on the LRU though, so reclaim can\npick it up later. It then takes the old offset out of folio-\u003eswap and\noverwrites the table entry there, which by then may belong to someone\nelse.\n\nThis bug can trigger silent memory corruption, process crashes, or data\ninstability across completely unrelated userspace applications - typically\noccurring when uswsusp is preparing the hibernation image.\n\nI found this while working on giving hibernation slots their own marker in\nthe swap table, which I had discussed with Kairui. \n(https://lore.kernel.org/linux-mm/abp7aDgYLrxF3Me8@KASONG-MC4/) As far as\nI know there are no reports, so there is no Reported-by/Closes to add.\n\nCheck for a cached folio before freeing. The slot is then left in the\nordinary state where only the swap cache holds it, and it is freed when\nthe folio leaves the cache, either through the reclaim below or through\nnormal reclaim later."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The bug is reached only through local hibernation swap alloc/free (/dev/snapshot SNAPSHOT_ALLOC_SWAP_PAGE and SNAPSHOT_FREE_SWAP_PAGES, kernel hibernate()/swsusp_write, or swsusp_unmark) racing with local swapin; it is not reachable from network packets or remote protocols.\nAC:L - The attacker controls cluster readahead via tmpfs/shmem swapin (shmem_swapin_cluster always calls swap_cluster_readahead) in the same percpu cluster that swap_alloc_hibernation_slot uses; SNAPSHOT_ALLOC_SWAP_PAGE does not require a freeze, so neighboring hibernation slots can be cached and the sequence retried at will.\nPR:L - The readahead half needs only an ordinary local account (mmap of /dev/shm, pageout, faults). Hibernation is available to a local seat user via logind/polkit or idle/lid policy on typical laptop, desktop, and embedded systems without init-namespace root.\nUI:N - The attacker drives swap activity from their own threads and can start hibernation themselves (logind/systemctl hibernate) or wait for ordinary unattended hibernation; no separate victim action such as mounting a filesystem or opening a file is required.\nS:U - Corruption stays in the host kernel swap table and the same kernel\u0027s anonymous/shmem pages; this is standard local kernel impact, not a VM escape, IOMMU/DMA bypass, or other cross-authority boundary.\nC:H - Freeing a swap-cache folio\u0027s hibernation slot returns that offset to the allocator while the folio remains on the LRU; later reclaim overwrites a reused swap-table entry so another task can be given the stale folio, disclosing hibernation-image or other processes\u0027 memory.\nI:H - The same stale-folio reclaim writes into a swap-table slot that may already hold another folio pointer or swap count, corrupting MM metadata and yielding a kernel write/type-confusion primitive suitable for control-flow hijack rather than a bounded integrity change.\nA:H - The commit documents silent memory corruption and process crashes across unrelated userspace; a reused swap-table entry overwritten with a stale or non-folio value oopses or panics on swapin and can repeatedly crash the system."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T08:52:13.808Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/a6df73156f2d85746c69adbf13d0f5ea200e0626"
},
{
"url": "https://git.kernel.org/stable/c/10d9012e83efedde8718ceaa5053f836e0c8596c"
}
],
"title": "mm, swap: don\u0027t free a hibernation slot that is in the swap cache",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-89760",
"datePublished": "2026-09-11T19:47:02.090Z",
"dateReserved": "2026-09-11T19:38:34.763Z",
"dateUpdated": "2026-10-19T08:52:13.808Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…