CVE-2023-53178
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-15

Last updated on: 2025-12-02

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: mm: fix zswap writeback race condition The zswap writeback mechanism can cause a race condition resulting in memory corruption, where a swapped out page gets swapped in with data that was written to a different page. The race unfolds like this: 1. a page with data A and swap offset X is stored in zswap 2. page A is removed off the LRU by zpool driver for writeback in zswap-shrink work, data for A is mapped by zpool driver 3. user space program faults and invalidates page entry A, offset X is considered free 4. kswapd stores page B at offset X in zswap (zswap could also be full, if so, page B would then be IOed to X, then skip step 5.) 5. entry A is replaced by B in tree->rbroot, this doesn't affect the local reference held by zswap-shrink work 6. zswap-shrink work writes back A at X, and frees zswap entry A 7. swapin of slot X brings A in memory instead of B The fix: Once the swap page cache has been allocated (case ZSWAP_SWAPCACHE_NEW), zswap-shrink work just checks that the local zswap_entry reference is still the same as the one in the tree. If it's not the same it means that it's either been invalidated or replaced, in both cases the writeback is aborted because the local entry contains stale data. Reproducer: I originally found this by running `stress` overnight to validate my work on the zswap writeback mechanism, it manifested after hours on my test machine. The key to make it happen is having zswap writebacks, so whatever setup pumps /sys/kernel/debug/zswap/written_back_pages should do the trick. In order to reproduce this faster on a vm, I setup a system with ~100M of available memory and a 500M swap file, then running `stress --vm 1 --vm-bytes 300000000 --vm-stride 4000` makes it happen in matter of tens of minutes. One can speed things up even more by swinging /sys/module/zswap/parameters/max_pool_percent up and down between, say, 20 and 1; this makes it reproduce in tens of seconds. It's crucial to set `--vm-stride` to something other than 4096 otherwise `stress` won't realize that memory has been corrupted because all pages would have the same data.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-15
Last Modified
2025-12-02
Generated
2026-05-27
AI Q&A
2025-09-15
EPSS Evaluated
2026-05-25
NVD
CVE-2023-53178
Affected Vendors & Products
Showing 4 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 3.11 (inc) to 6.1.30 (exc)
linux linux_kernel From 6.2 (inc) to 6.3.4 (exc)
linux linux_kernel 6.4
linux linux_kernel 6.4
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-362 The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a race condition in the Linux kernel's zswap writeback mechanism. It can cause memory corruption by swapping in a page with data that belongs to a different page. The issue occurs when a page (A) is stored in zswap and then removed for writeback, but before the writeback completes, the swap offset is reused for another page (B). The writeback then incorrectly writes back stale data from page A to the swap slot, causing page A to be swapped in instead of page B, leading to corrupted memory data. The fix involves checking if the local zswap entry is still valid before proceeding with writeback, aborting if the entry has been replaced or invalidated.


How can this vulnerability impact me? :

This vulnerability can lead to memory corruption where data from one swapped-out page is incorrectly swapped back in place of another. This can cause applications or the system to read incorrect or stale data, potentially leading to crashes, data integrity issues, or unpredictable behavior in the affected Linux system.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring zswap writebacks and memory corruption symptoms. Running the 'stress' tool with specific parameters can help reproduce the issue for detection. For example, use the command: stress --vm 1 --vm-bytes 300000000 --vm-stride 4000 to trigger the race condition. Additionally, monitoring /sys/kernel/debug/zswap/written_back_pages can indicate zswap writeback activity related to the vulnerability.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves applying the fix that checks the local zswap_entry reference against the tree entry before writeback, aborting if stale. Practically, this means updating the Linux kernel to a version that includes the patch for this zswap writeback race condition. Until then, reducing zswap writeback activity or disabling zswap might reduce exposure, but the recommended step is to upgrade the kernel.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart