CVE-2025-39941
Published: October 7, 2025Last modified: October 7, 2025
Description
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.
Severity score breakdown
| Parameter | Value |
|---|---|
| Base score | 4.7 |
| Attack Vector | LOCAL |
| Attack complexity | HIGH |
| Privileges required | LOW |
| User interaction | NONE |
| Scope | UNCHANGED |
| Confidentiality | NONE |
| Integrity impact | NONE |
| Availability impact | HIGH |
| Vector | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H |
Status
| Product | Release | Package | Status |
|---|---|---|---|
| Alpaquita Linux | 23 LTS | linux-lts | Not affected (6.1.33-r0) |
| 25 LTS | linux-lts | Not affected (6.6.89-r0) | |
| Stream | linux-lts | Not affected (6.1.33-r0) |