From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: CVE-2022-49052: mm: fix unexpected zeroed page mapping with zram swap
Date: Wed, 26 Feb 2025 02:54:17 +0100 [thread overview]
Message-ID: <2025022651-CVE-2022-49052-4ea2@gregkh> (raw)
Description
===========
In 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.
The Linux kernel CVE team has assigned CVE-2022-49052 to this issue.
Affected and fixed versions
===========================
Issue introduced in 4.15 with commit 0bcac06f27d7528591c27ac2b093ccd71c5d0168 and fixed in 4.19.242 with commit f86d55cf616199404c05f5b0c5c41b17351baa02
Issue introduced in 4.15 with commit 0bcac06f27d7528591c27ac2b093ccd71c5d0168 and fixed in 5.4.193 with commit f098f8b9820fe3f2e41aefc4329dfe8a3859d1c1
Issue introduced in 4.15 with commit 0bcac06f27d7528591c27ac2b093ccd71c5d0168 and fixed in 5.10.112 with commit 20ed94f8181a25212e7404e44958e234f407624b
Issue introduced in 4.15 with commit 0bcac06f27d7528591c27ac2b093ccd71c5d0168 and fixed in 5.15.35 with commit 12ba1d38115a101c45d8e0ca3aa1181fd148e57f
Issue introduced in 4.15 with commit 0bcac06f27d7528591c27ac2b093ccd71c5d0168 and fixed in 5.17.4 with commit afac4b88699a06c8b9369f9d759a1ec3c254b788
Issue introduced in 4.15 with commit 0bcac06f27d7528591c27ac2b093ccd71c5d0168 and fixed in 5.18 with commit e914d8f00391520ecc4495dd0ca0124538ab7119
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2022-49052
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
mm/page_io.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/f86d55cf616199404c05f5b0c5c41b17351baa02
https://git.kernel.org/stable/c/f098f8b9820fe3f2e41aefc4329dfe8a3859d1c1
https://git.kernel.org/stable/c/20ed94f8181a25212e7404e44958e234f407624b
https://git.kernel.org/stable/c/12ba1d38115a101c45d8e0ca3aa1181fd148e57f
https://git.kernel.org/stable/c/afac4b88699a06c8b9369f9d759a1ec3c254b788
https://git.kernel.org/stable/c/e914d8f00391520ecc4495dd0ca0124538ab7119
reply other threads:[~2025-02-26 1:57 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025022651-CVE-2022-49052-4ea2@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.