Back

HIGH

zsmalloc: fix races between asynchronous zspage free and page migration

Published Feb 26, 2025

Description

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.

Affected products

Remediation

No remediation recorded yet.

Metrics

Weaknesses (1)

References (13)

Change history (0)

No recorded changes yet.

Sources
CVE.org / MITRE
Status PUBLISHED
Assigner Linux
Published Feb 26, 2025
Updated Aug 5, 2026
Reserved Feb 26, 2025
NVD
Status Modified
Modified Aug 4, 2026
Red Hat
Severity Low
Public date Feb 26, 2025