CVE-2026-53185

What it actually does

This is a Linux kernel use-after-free flaw in the zram driver. During a partial write to a zram slot that uses writeback storage, the kernel can dispatch a backing-device read asynchronously while the caller continues processing and frees the memory page used as the read buffer. The in-flight I/O can later write into that freed page, causing kernel memory corruption. Depending on timing, allocator reuse, kernel hardening, and workload, the likely outcomes are kernel crash, data corruption, or potentially local privilege escalation through controlled kernel memory corruption.

Why it matters to the business

Systems using vulnerable Linux kernels with zram, especially zram writeback/backing-device configurations, may be exposed to local denial-of-service risk and possible privilege escalation. The current public exploitation signal is low: EPSS is 0.00095, the vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and no mature public exploit is indicated. However, because this affects kernel memory safety, organizations should still prioritize remediation on multi-user Linux systems, container hosts, virtualization platforms, developer workstations, and production servers where local users or workloads may be able to trigger zram I/O paths.

How an attack unfolds

An attacker first needs local code execution or another way to cause controlled I/O through a vulnerable zram device. They then create conditions where zram slots are backed by a writeback device and issue partial writes that require the kernel to read existing slot contents before completing the write. In the vulnerable path, zram_bvec_write_partial() passes a parent bio to zram_read_page(), causing the read to be handled asynchronously. The caller assumes the read is complete, copies data, writes the page, and frees the buffer while the backing-device read may still be active. If the freed page is reallocated before the asynchronous I/O completes, the late write can corrupt whatever kernel object now occupies that memory. A basic exploit attempt may simply crash the kernel; a more advanced exploit would try to shape heap reuse so the corruption targets security-sensitive kernel structures. There is currently no indication of known exploitation in the wild.

How to fix it

Apply the Linux kernel update or vendor backport that includes the zram_bvec_write_partial() fix. Because no exact fixed package versions were provided, use the relevant distribution, appliance, or kernel vendor advisory to identify the corrected kernel build for each supported release. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by disabling zram writeback/backing-device functionality, disabling zram entirely if it is not required, or preventing untrusted local workloads from running on affected systems. Kernel hardening, module restrictions, and limiting local shell/container access can reduce exploitability but should not be treated as complete mitigations.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, contains the vendor fix for this zram use-after-free. Validate that systems have rebooted into the corrected kernel after patching. Inventory zram usage by checking whether zram block devices are present and whether any are configured with a backing device/writeback. For unpatched systems requiring temporary mitigation, verify that zram writeback is not configured or that zram is disabled. Review vendor changelogs or kernel source for the zram_bvec_write_partial() change that forces the relevant read path to complete synchronously rather than allowing an asynchronous read to outlive the page buffer.

Typical attack path

1. Obtain local execution on a Linux system running a vulnerable kernel with zram enabled.
2. Identify or influence a zram configuration that uses writeback/backing storage.
3. Generate zram I/O patterns involving partial writes to slots requiring read-before-write behavior.
4. Trigger the vulnerable zram_bvec_write_partial() path so the backing-device read is dispatched asynchronously.
5. Cause the original page buffer to be freed while the asynchronous read remains in flight.
6. Attempt to reclaim the freed page with attacker-influenced kernel allocations before the I/O completion writes into it.
7. Use the resulting memory corruption to crash the system or, if reliably controllable, attempt privilege escalation.

How to detect it

Retrospective exploitation detection is difficult because successful abuse may leave only kernel crash artifacts or no durable application-level logs. Review kernel logs, persistent journal data, crash dumps, kdump/vmcore output, and hypervisor or out-of-band management reset records for zram-related kernel oops, panic, KASAN, KFENCE, or general-protection-fault messages. Search for stack traces containing zram_bvec_write_partial(), zram_read_page(), zram_write_page(), memcpy_from_bvec(), or backing-device I/O completion paths near the time of a crash. Also review audit or EDR telemetry for local users or workloads repeatedly reconfiguring /sys/block/zram*/backing_dev, generating unusual memory-pressure workloads, or exercising zram writeback immediately before system instability. Absence of these artifacts does not prove non-exploitation, especially on systems without persistent kernel logging or crash dump collection.

• BUG: KASAN: use-after-free
• KASAN: use-after-free
• KFENCE: use-after-free
• zram_bvec_write_partial
• zram_read_page
• zram_write_page
• memcpy_from_bvec
• zram:
• /sys/block/zram
• /sys/block/zram*/backing_dev
• /sys/block/zram*/writeback
• general protection fault
• kernel NULL pointer dereference
• Unable to handle kernel paging request
• Oops:
• Kernel panic - not syncing

What your security team should do

• Prioritize patching Linux systems that enable zram writeback, host untrusted local users, run containers, or support shared workloads.
• Reboot systems after applying the fixed kernel and verify the active kernel version is the corrected build.
• Inventory zram usage across Linux fleets, including appliances and custom kernel deployments, rather than assuming default distribution settings are uniform.
• If patching must be delayed, disable zram writeback/backing-device use or disable zram where operationally acceptable.
• Monitor kernel logs for crashes, KASAN reports, and zram-related I/O anomalies that may indicate attempted triggering or instability.
• Treat unexplained kernel oops/panic events involving zram functions as security-relevant until ruled out.
• Track distribution advisories for exact fixed package versions and any follow-up hardening or regression fixes.