Metrics
Affected Vendors & Products
Tue, 04 Aug 2026 09:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
cvssV3_1
|
cvssV3_1
|
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:
Updated: 2026-08-04T09:05:48.820Z
Reserved: 2025-02-26T02:08:31.590Z
Link: CVE-2022-49554
No data.
Status : Analyzed
Published: 2025-02-26T07:01:31.223
Modified: 2026-06-17T05:18:26.120
Link: CVE-2022-49554
OpenCVE Enrichment
Updated: 2025-07-12T22:16:24Z