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.
                
            Metrics
Affected Vendors & Products
References
        History
                    Wed, 22 Oct 2025 17:45:00 +0000
| Type | Values Removed | Values Added | 
|---|---|---|
| Weaknesses | CWE-362 | |
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Metrics | 
        
        
        cvssV3_1
         
  | 
    
        
        
        cvssV3_1
         
  | 
Thu, 27 Feb 2025 01:45:00 +0000
| Type | Values Removed | Values Added | 
|---|---|---|
| References | 
         | |
| Metrics | 
        
        
        threat_severity
         
  | 
    
        
        cvssV3_1
         
 
  | 
Wed, 26 Feb 2025 02:45:00 +0000
| Type | Values Removed | Values Added | 
|---|---|---|
| Description | 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. | |
| Title | zsmalloc: fix races between asynchronous zspage free and page migration | |
| References | 
         | 
        
  | 
Status: PUBLISHED
Assigner: Linux
Published: 2025-02-26T02:14:02.649Z
Updated: 2025-05-04T08:40:26.141Z
Reserved: 2025-02-26T02:08:31.590Z
Link: CVE-2022-49554
No data.
Status : Analyzed
Published: 2025-02-26T07:01:31.223
Modified: 2025-10-22T17:33:36.960
Link: CVE-2022-49554