CVE-2025-39941
published 2025-10-04CVE-2025-39941: In the Linux kernel, the following vulnerability has been resolved: zram: fix slot write race condition Parallel concurrent writes to the same zram index…
PriorityP415medium4.7CVSS 3.1
AVLACHPRLUINSUCNINAH
EPSS
0.09%
0.6th percentile
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
12 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.16.9-1 (forky) | linux 6.16.9-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= 71268035f5d734ad6373d953298bd5779985497a < ff750e9f2c4d63854c33967d1646b5e89a9a19a2 | ff750e9f2c4d63854c33967d1646b5e89a9a19a2 |
| linux | linux | >= 71268035f5d734ad6373d953298bd5779985497a < ce4be9e4307c5a60701ff6e0cafa74caffdc54ce | ce4be9e4307c5a60701ff6e0cafa74caffdc54ce |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.16.9-1 | 6.16.9-1 |
| linux | linux_kernel | >= 6.14 < 6.16.9 | 6.16.9 |
CVSS provenance
nvdv3.14.7MEDIUMCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
osv4.7MEDIUM
vendor_debian4.7LOW
vendor_redhat4.7MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: zram: fix slot write race condition
vendor_redhat·2025-10-04·CVSS 4.7
CVE-2025-39941 [MEDIUM] kernel: zram: fix slot write race condition
kernel: zram: fix slot write race condition
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()
compresscompress
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.
Package: kernel (Red Hat Enterprise Linux 10) - No
Debian
CVE-2025-39941: linux - In the Linux kernel, the following vulnerability has been resolved: zram: fix s...
vendor_debian·2025·CVSS 4.7
CVE-2025-39941 [MEDIUM] CVE-2025-39941: linux - In the Linux kernel, the following vulnerability has been resolved: zram: fix s...
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.
Scope: local
bookworm: resolved
bullseye: resolved
forky: resolved (fixed in 6.16.9-1)
sid: re
OSV
CVE-2025-39941: In the Linux kernel, the following vulnerability has been resolved: zram: fix slot write race condition Parallel concurrent writes to the same zram in
osv·2025-10-04·CVSS 4.7
CVE-2025-39941 [MEDIUM] CVE-2025-39941: In the Linux kernel, the following vulnerability has been resolved: zram: fix slot write race condition Parallel concurrent writes to the same zram in
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.
GHSA
GHSA-mjg7-65xv-hcjw: In the Linux kernel, the following vulnerability has been resolved:
zram: fix slot write race condition
Parallel concurrent writes to the same zram
ghsa_unreviewed·2025-10-04
CVE-2025-39941 [MEDIUM] CWE-362 GHSA-mjg7-65xv-hcjw: In the Linux kernel, the following vulnerability has been resolved:
zram: fix slot write race condition
Parallel concurrent writes to the same zram
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.
No detection rules found.
No public exploits indexed.
2025-10-04
Published