CVE-2022-49052

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

doswappage doswappage SWPSYNCHRONOUSIO path SWPSYNCHRONOUSIO path swapreadpage valid data swapslotfreenotify delete zram entry swapreadpage zeroed(invalid) data ptelock map the zero data to userspace pteunlock ptelock if (!ptesame) goto outnomap; pte_unlock return and next refault will read zeroed data

The swapslotfreenotify is bogus for CLONEVM case since it doesn't increase the refcount of swap slot at copymm 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 swapslotfreenotify function. With this patch, CPU A will see correct data.

  CPU A                        CPU B

doswappage doswappage SWPSYNCHRONOUSIO path SWPSYNCHRONOUSIO path swapreadpage original data ptelock map the original data swapfree swaprangefree bddisk->fops->swapslotfreenotify swapreadpage read zeroed data pteunlock ptelock if (!ptesame) goto outnomap; 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 doswappage is followed by swap_free so it will free the compressed form from in zram quickly.