CVE-2025-39941
N/A
Summary
In the Linux kernel, the following vulnerability has been resolved:
zram: fix slot write race condition
Parallel concurrent writes to the same zram index result in leaked zsmalloc handles. Schematically we can have something like this:
CPU0 CPU1 zram_slot_lock() zs_free(handle) zram_slot_lock() zram_slot_lock() zs_free(handle) zram_slot_lock()
compress compress handle = zs_malloc() handle = zs_malloc() zram_slot_lock zram_set_handle(handle) zram_slot_lock zram_slot_lock zram_set_handle(handle) zram_slot_lock
Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done too early. In fact, we need to reset zram entry right before we set its new handle, all under the same slot lock scope.
Affected Software
| Vendor | Product | Version Range | Status |
|---|---|---|---|
| Linux | Linux | 71268035f5d734ad6373d953298bd5779985497a < ff750e9f2c4d63854c33967d1646b5e89a9a19a2 | affected |
| Linux | Linux | 71268035f5d734ad6373d953298bd5779985497a < ce4be9e4307c5a60701ff6e0cafa74caffdc54ce | affected |
| Linux | Linux | 6.14 | affected |
| Linux | Linux | 0 < 6.14 | unaffected |
| Linux | Linux | 6.16.9 <= 6.16.* | unaffected |
| Linux | Linux | 6.17 <= * | unaffected |
Weaknesses
References
- https://git.kernel.org/stable/c/ff750e9f2c4d63854c33967d1646b5e89a9a19a2
- https://git.kernel.org/stable/c/ce4be9e4307c5a60701ff6e0cafa74caffdc54ce
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.