CVE-2022-49554 in Linux
Summary
by MITRE • 02/26/2025
In the Linux kernel, the following vulnerability has been resolved:
zsmalloc: fix races between asynchronous zspage free and page migration
The asynchronous zspage free worker tries to lock a zspage's entire page list without defending against page migration. Since pages which haven't yet been locked can concurrently migrate off the zspage page list while lock_zspage() churns away, lock_zspage() can suffer from a few different lethal races.
It can lock a page which no longer belongs to the zspage and unsafely dereference page_private(), it can unsafely dereference a torn pointer to the next page (since there's a data race), and it can observe a spurious NULL pointer to the next page and thus not lock all of the zspage's pages (since a single page migration will reconstruct the entire page list, and create_page_chain() unconditionally zeroes out each list pointer in the process).
Fix the races by using migrate_read_lock() in lock_zspage() to synchronize with page migration.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2025
The vulnerability identified as CVE-2022-49554 resides within the Linux kernel's zsmalloc memory management subsystem, specifically addressing race conditions that occur during asynchronous zspage free operations and page migration processes. This issue represents a critical concurrency flaw that undermines the integrity of memory management operations within the kernel's virtual memory subsystem. The zsmalloc subsystem is designed to provide efficient memory allocation for compressed pages, particularly in scenarios involving memory compression and virtual memory management. The vulnerability manifests when the asynchronous zspage free worker attempts to acquire locks on zspage page lists without proper synchronization against concurrent page migration activities. This fundamental flaw creates a dangerous scenario where the locking mechanism becomes ineffective due to the dynamic nature of page migration operations.
The technical implementation of this vulnerability stems from the lock_zspage() function's failure to account for page migration events that can occur while the function is processing page lists. During asynchronous zspage free operations, the worker thread traverses page lists to acquire locks on individual pages before performing cleanup operations. However, since page migration can occur concurrently, pages that were initially part of the zspage list may have been moved to different locations in memory. This creates several distinct race conditions that can lead to system instability or security implications. The most severe outcomes include attempting to lock pages that no longer belong to the target zspage, resulting in unsafe dereferencing of page_private() function calls, and encountering torn pointers to subsequent pages in the list. Additionally, the vulnerability allows for spurious NULL pointer observations that prevent complete locking of all zspage pages, as single page migration events can reconstruct entire page lists while the lock_zspage() function is in progress.
The operational impact of this vulnerability extends beyond simple memory management failures, potentially affecting system stability and security posture. When the race conditions occur, they can lead to memory corruption, kernel panics, or unpredictable behavior in memory management subsystems that rely on zsmalloc. This vulnerability is particularly concerning because it operates at the kernel level where memory management directly affects system performance and reliability. The race conditions can be exploited to cause denial of service conditions or potentially enable privilege escalation attacks by manipulating memory structures during concurrent operations. The vulnerability affects systems using zsmalloc for memory compression, which is commonly implemented in various memory management scenarios including virtual memory systems, compressed swap spaces, and memory-efficient data structures. From a cybersecurity perspective, this vulnerability represents a classic example of a race condition in kernel memory management, classified under CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and may align with ATT&CK techniques involving system memory manipulation and kernel exploitation.
The resolution for CVE-2022-49554 involves implementing proper synchronization mechanisms within the lock_zspage() function by utilizing migrate_read_lock() to coordinate with page migration activities. This fix ensures that the locking mechanism properly accounts for concurrent page migration events by acquiring appropriate read locks before processing page lists. The solution addresses all identified race conditions by preventing the locking function from operating on pages that may have been migrated, thereby eliminating the unsafe dereference scenarios and torn pointer issues. The implementation of migrate_read_lock() creates a proper synchronization barrier that prevents the race conditions from occurring while maintaining the necessary functionality of the zsmalloc subsystem. This fix demonstrates a proper approach to concurrent programming in kernel space where shared resources require careful synchronization to prevent race conditions that could compromise system integrity. The mitigation strategy ensures that page migration operations and memory locking operations occur in a coordinated manner, preventing the scenarios where pages are moved while being processed for cleanup. This represents a standard best practice for kernel memory management where concurrent access patterns must be carefully considered to maintain system stability and security.