CVE-2026-53185: Linux Kernel Use-After-Free Vulnerability

CVE-2026-53185 Overview

CVE-2026-53185 is a use-after-free vulnerability in the Linux kernel's zram compressed block device driver. The flaw resides in zram_bvec_write_partial(), where the function passes a non-NULL parent bio to zram_read_page(). This selection triggers the asynchronous backing device read path for ZRAM_WB slots. The caller proceeds to invoke memcpy_from_bvec(), zram_write_page(), and __free_page() on the buffer while the asynchronous read is still in flight. The in-flight read then writes into a freed page, corrupting kernel memory.

Critical Impact
An asynchronous backing device read can write into freed kernel memory, leading to memory corruption, kernel instability, or potential local privilege escalation on systems using zram with a writeback backing device.

Affected Products

Linux kernel versions containing the zram driver prior to the fix commits listed in the kernel.org stable tree
Distributions shipping affected kernels with zram writeback (ZRAM_WB) functionality enabled
Systems leveraging zram with a configured backing device for swap or compressed storage

Discovery Timeline

2026-06-25 - CVE-2026-53185 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-53185

Vulnerability Analysis

The zram driver provides compressed RAM-backed block devices and supports a writeback feature that offloads cold pages to a backing block device. The function zram_read_page() chooses between synchronous and asynchronous read paths based on whether the parent bio argument is NULL. A NULL parent forces synchronous completion, while a non-NULL parent dispatches the read asynchronously.

In zram_bvec_write_partial(), the parent bio is passed down unchanged. For slots marked ZRAM_WB (residing on the backing device), the read is dispatched asynchronously. zram_read_page() returns 0 immediately while the I/O remains in flight. The caller then executes memcpy_from_bvec(), zram_write_page(), and finally __free_page() on the staging buffer. The async read subsequently completes and writes data into the freed page.

A related fix in commit 4e3c87b9421d ("zram: fix synchronous reads") corrected the same pattern in zram_bvec_read_partial() by passing NULL, but the write-partial counterpart was overlooked. CVE-2026-53185 addresses that omission.

Root Cause

The root cause is incorrect lifetime management of a page buffer used during a partial write operation. By forwarding a non-NULL parent bio, the code selects an asynchronous I/O path whose completion outlives the buffer's allocation scope. This results in a classic use-after-free where freed memory is mutated by a delayed kernel I/O completion callback.

Attack Vector

Exploitation requires the ability to issue partial writes to a zram device configured with a writeback backing device. A local user with access to a mounted zram-backed filesystem or swap device can trigger the code path. The corruption window depends on backing device latency, so timing pressure may be required to land the freed page on a useful target. Successful exploitation can yield kernel memory corruption, denial of service through kernel panics, or potential elevation of privilege.

No public proof-of-concept exploit is currently associated with this CVE. The EPSS data places the probability of exploitation in the wild at a low percentile.

Detection Methods for CVE-2026-53185

Indicators of Compromise

Unexpected kernel panics or Oops messages referencing zram, zram_read_page, zram_bvec_write_partial, or __free_page
KASAN (Kernel Address Sanitizer) reports flagging use-after-free in zram code paths on instrumented kernels
Slab corruption warnings or page-poisoning detection events in dmesg on hosts running zram with writeback

Detection Strategies

Audit running kernel versions across the fleet against the fixed commits in the kernel.org stable tree
Enable KASAN in test or staging kernels to surface use-after-free conditions in zram before production deployment
Monitor kernel ring buffers for repeated zram-related faults that may indicate exploitation attempts or unstable workloads

Monitoring Recommendations

Collect and centralize dmesg and journald kernel logs to detect anomalous zram errors at scale
Track which systems have zram writeback enabled by inspecting /sys/block/zram*/backing_dev across hosts
Alert on unexpected reboot loops or kernel crash dumps on systems with zram-backed swap

How to Mitigate CVE-2026-53185

Immediate Actions Required

Apply the upstream kernel patches referenced in the kernel.org stable tree as soon as they are available through your distribution
Inventory systems with zram writeback enabled and prioritize them for patching
Restrict local access on multi-tenant systems until patched kernels are deployed

Patch Information

Fixes were merged through multiple stable branches. Review and apply the relevant patches: Kernel commit 0c2821665ff7, commit 198b5a14cca2, commit 732fd9f0b9c1, commit 77a602b505ce, and commit c96786d6ff1a. The fix aligns zram_bvec_write_partial() with the earlier correction applied to zram_bvec_read_partial() in commit 4e3c87b9421d, ensuring the read path used during partial writes completes synchronously.

Workarounds

Disable zram writeback by not configuring a backing_dev for zram devices, which avoids the ZRAM_WB code path
Where zram is non-essential, unload the zram module (modprobe -r zram) until patched kernels are deployed
Limit local user access and harden container boundaries on shared hosts that rely on zram-backed swap

bash

# Check whether zram writeback is configured on the host
for dev in /sys/block/zram*/backing_dev; do
    echo "$dev: $(cat $dev 2>/dev/null)"
done

# Temporarily disable zram writeback by removing the backing device (requires empty zram)
# swapoff /dev/zram0
# echo 1 > /sys/block/zram0/reset