CVE-2026-53185: Linux zram Use-After-Free in Writeback Path

Technical summary

CVE-2026-53185 is a use-after-free bug in zram_bvec_write_partial() within the Linux kernel's zram memory compression driver. The vulnerability occurs in the interaction between partial writes and backing device I/O. When zram_bvec_write_partial() invokes zram_read_page() for ZRAM_WB (write-back) slots while passing a parent bio pointer, the read operation is dispatched asynchronously and returns immediately with a zero status code while the bio remains in flight. The caller then proceeds to execute memcpy_from_bvec(), zram_write_page(), and __free_page() on the buffer before the asynchronous read completes, resulting in the async operation writing into freed memory. A nearly identical issue was fixed in zram_bvec_read_partial() via commit 4e3c87b9421d, but the write_partial counterpart was overlooked. The root cause is improper synchronization assumptions: passing a non-NULL parent bio forces async I/O behavior, but the caller expects synchronous completion.

Business impact

This vulnerability affects Linux systems using zram for memory compression, particularly in containerized, embedded, or memory-constrained deployments. An unprivileged local attacker can trigger the use-after-free by creating conditions that force writes through the backing device path, leading to kernel memory corruption. Exploitation can result in denial of service through kernel crashes, information disclosure via heap inspection, or local privilege escalation. Organizations running zram-enabled kernels in multi-tenant or untrusted-user environments face elevated risk. The issue is subtle and may be triggered by specific workload patterns (e.g., rapid compression/decompression of large data sets), making detection and reproducibility challenging.

Affected systems

The Linux kernel zram driver is affected. Vulnerable systems include any Linux distribution or kernel build with CONFIG_ZRAM enabled and backing device support (CONFIG_ZRAM_WRITEBACK). This is common in resource-constrained environments: embedded Linux systems, cloud container hosts, live-boot distributions, and systems using zram for swap acceleration. The vulnerability is not present in kernels compiled without zram or with writeback disabled, but such configurations are increasingly rare in modern deployments.

Exploitability

Exploitation requires local access with unprivileged user permissions (CWE-364: Exposure of Sensitive Information to an Unauthorized Actor; CWE-416: Use-After-Free). No network vector exists. The attack is deterministic but requires specific timing and workload conditions to reliably trigger the race condition. A motivated attacker with shell access can craft I/O patterns (e.g., via fio or custom I/O generators) to force the vulnerable code path. The absence of ASLR or other protections on kernel heap memory increases the reliability of exploiting the resulting memory corruption. Proof-of-concept development is feasible but requires deep kernel-level understanding.

Remediation

Apply the kernel patch that fixes zram_bvec_write_partial() by passing NULL as the parent bio parameter to zram_read_page(), matching the synchronous fix applied to zram_bvec_read_partial() in commit 4e3c87b9421d. This ensures that reads block until completion before the caller frees the buffer. The fix is a minimal one-line or few-line change. Verify the patch version against your kernel's release notes or vendor advisory. As an interim mitigation, disable CONFIG_ZRAM_WRITEBACK if zram is used only for in-memory compression without backing device persistence.

Patch guidance

Obtain the kernel update from your Linux distribution's package repository or from kernel.org. For enterprise distributions (Red Hat, Canonical, SUSE), security updates are typically released as kernel-devel or linux-image packages with CVE references in the advisory. Verify the patched kernel version against your vendor's security bulletin. Test the updated kernel in a staging environment to confirm writeback functionality still operates correctly before deploying to production. Reboot systems after patching; zram is typically mounted early in the boot sequence.

Detection guidance

Monitor system logs for kernel Oops, segmentation faults, or BUG_ON() messages in zram or block I/O subsystem code paths. Use kernel debug symbols (CONFIG_DEBUG_INFO) and tools like crash or kdump to analyze memory dumps. In production, inspect dmesg for unexpected page allocation failures or memory poisoning markers. Workload-based detection: log unusual patterns of rapid zram writeback + memory pressure spikes. Security monitoring tools may flag privilege escalation attempts by unprivileged processes accessing kernel memory. No user-space signatures exist; detection is primarily post-exploitation via crash forensics.

Why prioritize this

HIGH severity (CVSS 7.8) with local attack vector and unprivileged user requirement. While not as critical as network-facing vulnerabilities, the confluence of exploitability (AC:L), high integrity and availability impact (I:H/A:H), and widespread deployment of zram in cloud and container infrastructure warrants priority remediation. The subtlety of the race condition and difficulty in reproducing it in testing labs mean the vulnerability may persist unpatched longer than expected. Organizations should prioritize kernel updates for systems with untrusted user access or multi-tenant workloads.

Risk score, explained

CVSS 7.8 (HIGH) reflects: Attack Vector (Local) — requires shell access but no special privileges; Attack Complexity (Low) — no unusual conditions needed, though timing is required; Privileges Required (Low) — unprivileged user can exploit; User Interaction (None) — no user action needed to trigger; Scope (Unchanged) — impact limited to the affected system; Confidentiality (High) — kernel memory disclosure possible; Integrity (High) — heap corruption enables arbitrary writes; Availability (High) — kernel crashes or DoS guaranteed. The score appropriately penalizes the local-only vector but recognizes the severity of kernel-level memory corruption.

Frequently asked questions