Look up another CVE · open CVE-2026-53185 in the interactive tracker
CVE-2026-53185
zram: fix use-after-free in zram_bvec_write_partial()
Published 2026-06-25 (4 months ago) by the Linux kernel CNA. Subsystem drivers/block. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-53185 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d ("zram: fix synchronous reads") for the same reason; the write_partial counterpart was missed.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/block/zram/zram_drv.c
- What this is
- ZRAM COMPRESSED RAM BLOCK DEVICE DRVIERMAINTAINERS section matched on drivers/block/zram/ · linux-kernel@vger.kernel.org · Maintained
- Kernel module
- zram
Check it on the machine
grep -w CONFIG_ZRAM /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w zramPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_ZRAM
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-06-25 (4 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.11%, higher than 1.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/block
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.14 | 6.6.143 | 0c2821665ff7 |
| 4.14 | 6.12.94 | 77a602b505ce |
| 4.14 | 6.18.36 | c96786d6ff1a |
| 4.14 | 7.0.13 | 198b5a14cca2 |
| 4.14 | 7.1 | 732fd9f0b9c1 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- Reachability is through local block-device or filesystem I/O that submits writes to a zram device. There is no network, adjacent, or physical transport path into this driver code.
- AC:LAttack complexity, low
- On affected non-4K-page zram writeback deployments, the attacker can create partial bio_vec writes and target ZRAM_WB slots without winning a race. The bug is a deterministic asynchronous lifetime error once that normal writeback state exists.
- PR:LPrivileges required, low
- zram_submit_bio() and zram_open() add no kernel capability check; access is governed by the device node or a mounted zram-backed filesystem. A normal local user with write access to such storage can trigger the vulnerable I/O path, while admin-only setup is an environmental prerequisite.
- UI:NUser interaction, none
- No victim action is needed after the attacker has local write access to the zram-backed storage. The attacker directly submits or induces the partial write.
- S:UScope, unchanged
- The corruption occurs in kernel memory within the same host security authority. It is not a VM escape, IOMMU bypass, or cross-scope boundary violation.
- C:HConfidentiality impact, high
- This is a kernel use-after-free of a page later written by asynchronous backing-device I/O. Under the required overestimation rule, such memory corruption is treated as capable of enabling high-impact information disclosure.
- I:HIntegrity impact, high
- The freed page can be reallocated before the asynchronous I/O completes, causing kernel memory to be overwritten. That supports high integrity impact due to potential arbitrary corruption or code execution primitives.
- A:HAvailability impact, high
- The UAF can corrupt live kernel memory and readily cause an oops, panic, or hang. Repeated local triggering can therefore cause high availability impact.