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.
Security readout for executives and security teams
Plain-English summary
A race in Linux zram can leak compressed-memory allocation handles when parallel writes target the same slot. Repeated leakage may consume kernel memory and disrupt systems. The supplied CVSS score is 7.8, but the sources do not document observed attacks or confirmed real-world impact beyond the handle leak.
Executive priority
Treat as a high-priority kernel maintenance issue on zram-enabled systems, especially shared or memory-constrained hosts. Schedule supported updates promptly, but avoid emergency incident declarations without exploitation evidence. Systems not using zram are less likely to encounter the described flaw.
Technical view
Concurrent writes to one zram index can free the previous handle too early, then allocate and replace handles across separate slot-lock scopes. One allocation may become unreachable. The fix resets the zram entry immediately before installing the new handle while holding the same slot lock.
Likely exposure
Exposure is limited to affected Linux kernels using zram and encountering concurrent writes to the same index. The CVSS vector requires local access with low privileges and no user interaction. The supplied version data identifies affected releases but is insufficiently clear for reliable distribution-specific conclusions.
Exploitation context
The bundle marks this CVE as absent from KEV and provides no evidence of active exploitation or a public exploit. Triggerability is described as a local concurrency condition. Whether an unprivileged user can reliably force security-significant resource exhaustion is not established by the supplied sources.
Researcher notes
The primary evidence establishes a same-slot write race and leaked zsmalloc handle. No CWE is assigned. The supplied CVSS claims high confidentiality, integrity, and availability impact, while the description directly substantiates only leakage of allocation handles; downstream consequences require further vendor or maintainer evidence.
Mitigation direction
Apply vendor-supported kernel updates containing the referenced stable fixes.
Check distribution advisories for backports rather than relying only on upstream version numbers.
If updates are delayed, consult vendor guidance; the sources name no alternative mitigation.
Prioritize systems using zram under concurrent or memory-intensive workloads.
Validation and detection
Inventory kernel versions and identify systems where zram is enabled or configured.
Confirm whether distribution kernels include either referenced stable fix through vendor records.
After updating, verify systems booted into the corrected kernel build.
Review monitoring for unexplained kernel-memory growth or zram-related resource pressure.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-39941 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
3Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.