GHSA-783X-7HM8-JFWG
Vulnerability from github – Published: 2025-10-14 21:30 – Updated: 2025-10-14 21:30In the Linux kernel, the following vulnerability has been resolved:
mm: fix unexpected zeroed page mapping with zram swap
Two processes under CLONE_VM cloning, user process can be corrupted by seeing zeroed page unexpectedly.
CPU A CPU B
do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage valid data swap_slot_free_notify delete zram entry swap_readpage zeroed(invalid) data pte_lock map the zero data to userspace pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return and next refault will read zeroed data
The swap_slot_free_notify is bogus for CLONE_VM case since it doesn't increase the refcount of swap slot at copy_mm so it couldn't catch up whether it's safe or not to discard data from backing device. In the case, only the lock it could rely on to synchronize swap slot freeing is page table lock. Thus, this patch gets rid of the swap_slot_free_notify function. With this patch, CPU A will see correct data.
CPU A CPU B
do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage original data pte_lock map the original data swap_free swap_range_free bd_disk->fops->swap_slot_free_notify swap_readpage read zeroed data pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return on next refault will see mapped data by CPU B
The concern of the patch would increase memory consumption since it could keep wasted memory with compressed form in zram as well as uncompressed form in address space. However, most of cases of zram uses no readahead and do_swap_page is followed by swap_free so it will free the compressed form from in zram quickly.
{
"affected": [],
"aliases": [
"CVE-2022-49052"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:42Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix unexpected zeroed page mapping with zram swap\n\nTwo processes under CLONE_VM cloning, user process can be corrupted by\nseeing zeroed page unexpectedly.\n\n CPU A CPU B\n\n do_swap_page do_swap_page\n SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path\n swap_readpage valid data\n swap_slot_free_notify\n delete zram entry\n swap_readpage zeroed(invalid) data\n pte_lock\n map the *zero data* to userspace\n pte_unlock\n pte_lock\n if (!pte_same)\n goto out_nomap;\n pte_unlock\n return and next refault will\n read zeroed data\n\nThe swap_slot_free_notify is bogus for CLONE_VM case since it doesn\u0027t\nincrease the refcount of swap slot at copy_mm so it couldn\u0027t catch up\nwhether it\u0027s safe or not to discard data from backing device. In the\ncase, only the lock it could rely on to synchronize swap slot freeing is\npage table lock. Thus, this patch gets rid of the swap_slot_free_notify\nfunction. With this patch, CPU A will see correct data.\n\n CPU A CPU B\n\n do_swap_page do_swap_page\n SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path\n swap_readpage original data\n pte_lock\n map the original data\n swap_free\n swap_range_free\n bd_disk-\u003efops-\u003eswap_slot_free_notify\n swap_readpage read zeroed data\n pte_unlock\n pte_lock\n if (!pte_same)\n goto out_nomap;\n pte_unlock\n return\n on next refault will see mapped data by CPU B\n\nThe concern of the patch would increase memory consumption since it\ncould keep wasted memory with compressed form in zram as well as\nuncompressed form in address space. However, most of cases of zram uses\nno readahead and do_swap_page is followed by swap_free so it will free\nthe compressed form from in zram quickly.",
"id": "GHSA-783x-7hm8-jfwg",
"modified": "2025-10-14T21:30:25Z",
"published": "2025-10-14T21:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49052"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/12ba1d38115a101c45d8e0ca3aa1181fd148e57f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20ed94f8181a25212e7404e44958e234f407624b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/afac4b88699a06c8b9369f9d759a1ec3c254b788"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e914d8f00391520ecc4495dd0ca0124538ab7119"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f098f8b9820fe3f2e41aefc4329dfe8a3859d1c1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f86d55cf616199404c05f5b0c5c41b17351baa02"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.