Look up another CVE · open CVE-2026-63951 in the interactive tracker

CVE-2026-63951

zram: fix use-after-free in zram_writeback_endio

7.8 EPSS 0.2% AV:L

Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem drivers/block. Debian urgency: unimportant.

What to do, per Debian release

Debian's own status for CVE-2026-63951 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	not affected	6.1.190-1	Nothing to do. bookworm never shipped the vulnerable code.
Debian 13trixie	not affected	6.12.113-1	Nothing to do. trixie never shipped the vulnerable code.
Debian 14forky	fixed	7.0.12-1	Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.0.12-1	Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

A crash was observed in zram_writeback_endio due to a NULL pointer dereference in wake_up. The root cause is a race condition between the bio completion handler (zram_writeback_endio) and the writeback task. In zram_writeback_endio, wake_up() is called on &wb_ctl->done_wait after releasing wb_ctl->done_lock. This creates a race window where the writeback task can see num_inflight become 0, return, and free wb_ctl before zram_writeback_endio calls wake_up(). CPU 0 (zram_writeback_endio) CPU 1 (writeback_store) ============================ ============================ zram_writeback_slots zram_submit_wb_request zram_submit_wb_request wait_event(wb_ctl->done_wait) spin_lock(&wb_ctl->done_lock); list_add(&req->entry, &wb_ctl->done_reqs); spin_unlock(&wb_ctl->done_lock); wake_up(&wb_ctl->done_wait); zram_complete_done_reqs spin_lock(&wb_ctl->done_lock); list_add(&req->entry, &wb_ctl->done_reqs); spin_unlock(&wb_ctl->done_lock); while (num_inflight) > 0) spin_lock(&wb_ctl->done_lock); list_del(&req->entry); spin_unlock(&wb_ctl->done_lock); // num_inflight becomes 0 atomic_dec(num_inflight); // Leave zram_writeback_slots // Free wb_ctl release_wb_ctl(wb_ctl); // UAF crash! wake_up(&wb_ctl->done_wait); This patch fixes this race by using RCU. By protecting wb_ctl with rcu_read_lock() in zram_writeback_endio and using kfree_rcu() to free it, we ensure that wb_ctl remains valid during the execution of zram_writeback_endio.

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 zram

Prints 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

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-07-19 (3 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.18%, higher than 6.8% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: unimportantsource
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
6.19	7.0.12	ebe2cbefc862
6.19	7.1	bf62f69574b1

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: The vulnerable code runs only in the zram writeback path (`writeback_store` → `zram_writeback_slots` → `zram_submit_wb_request` → `zram_writeback_endio`), reachable via local sysfs writes or system daemons that invoke the same sysfs interface; there is no network, Bluetooth, or physical-device entry point.
AC:LAttack complexity, low: This is a use-after-free race between batched bio completion handlers and writeback teardown; with default `writeback_batch_size` of 32 the attacker can drive concurrent inflight bios and repeatedly trigger writeback (directly as root or indirectly on Android via memory-pressure-driven `mmd` maintenance), controlling both sides of the race.
PR:LPrivileges required, low: On Android phones—the highest-impact deployment—an unprivileged app can induce memory pressure that causes the memory management daemon to invoke `/sys/block/zram0/writeback` without attacker root; alternatively a local admin can write the sysfs attribute directly, but no capability beyond a basic local user is required in the primary mobile scenario.
UI:NUser interaction, none: Exploitation requires no victim interaction beyond normal system operation; automated writeback on memory pressure or attacker-initiated sysfs writeback proceeds without the user mounting filesystems, opening files, or taking deliberate action.
S:UScope, unchanged: Successful exploitation corrupts kernel heap memory and can lead to privilege escalation or kernel crash, but does not cross a VM, IOMMU, or sandbox security boundary beyond standard kernel compromise.
C:HConfidentiality impact, high: The bug is a slab use-after-free on `struct zram_wb_ctl`; `wake_up()` operates on a freed `wait_queue_head_t`, enabling arbitrary kernel memory reads through heap reuse and controlled corruption of wait-queue state.
I:HIntegrity impact, high: Use-after-free on a kmalloc'd control structure allows heap spraying and corruption of `wait_queue_head_t` and adjacent slab objects, providing a plausible path to arbitrary kernel writes and code execution.
A:HAvailability impact, high: A production crash was already observed as a NULL pointer dereference in `wake_up()` during the race, and the underlying use-after-free can reliably cause kernel oops/panic even when not fully weaponized for code execution.