Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐧
🐧 Linux
Not in CISA KEV
HIGH severity

CVE-2026-53185 — Kernel

HIGH

CVE-2026-53185 is a high-severity (CVSS 7.8) Use After Free vulnerability in Kernel. A fix is available for Kernel — see the affected versions and patch details below.

zram: fix use-after-free in zram_bvec_write_partial()

Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 9, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
0.1%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs1th percentile — riskier than 1% of all scored CVEsHighest risk
0.00%0.20%0.40%0.61%0.1%0.1%0.1%0.1%0.1%Jul 26Sep 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-53185 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 385,386 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐧Kernel

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Linux packages — download data is not available via public APIs for these ecosystems.

Description

In the Linux kernel, the following vulnerability has been resolved:

zram: fix use-after-free in zram_bvec_write_partial()

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.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐧LinuxKernel≥ 4.14.0&&< 6.6.1436.6.143

Affected Products

1 product · 11 configurations
OS
linux kernellinux
≥ 6.19 && < 7.0.13
1 version
7.1

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for Kernel, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update Kernel to 6.6.143 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-53185 is resolved across your whole dependency graph.

  3. Workarounds

    Constrain what reaches the vulnerable code: limit the size and shape of untrusted input, isolate the affected component in a sandboxed or least-privileged process, and enable the platform's memory-safety mitigations (ASLR, stack protector, hardened allocator) so an out-of-bounds access is more likely to fail closed than to be exploitable.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate

A use-after-free write can occur in zram_bvec_write_partial() when zram_read_page() is called with a parent bio and selects the asynchronous backing device read path for ZRAM_WB slots. The function can return while the read bio is still in flight, after which the caller updates the temporary page, writes it back, and…

Workaround published by Red Hat
To mitigate this issue, prevent module zram from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.
Source: Red Hat security advisory for CVE-2026-53185 (CC BY 4.0)
ProductFixed inAdvisory
Red Hat Enterprise Linux 10kernel-0:6.12.0-211.50.1.el10_2RHSA-2026:61887
Red Hat Enterprise Linux 10.0 Extended Update Supportkernel-0:6.12.0-55.105.1.el10_0RHSA-2026:69089
Red Hat Enterprise Linux 8kernel-rt-0:4.18.0-553.159.1.rt7.500.el8_10RHSA-2026:63013
Red Hat Enterprise Linux 8kernel-0:4.18.0-553.159.1.el8_10RHSA-2026:63014
Red Hat Enterprise Linux 8.8 Telecommunications Update Servicekernel-0:4.18.0-477.168.1.el8_8RHSA-2026:69837
Red Hat Enterprise Linux 9kernel-0:5.14.0-687.42.1.el9_8RHSA-2026:59723
Red Hat Enterprise Linux 9.2 Update Services for SAP Solutionskernel-0:5.14.0-284.195.1.el9_2RHSA-2026:77215
Red Hat Enterprise Linux 9.2 Update Services for SAP Solutionskernel-rt-0:5.14.0-284.195.1.rt14.480.el9_2RHSA-2026:77214
UbuntuHIGH
USN-8726-1UbuntuUSN-8727-1UbuntuUSN-8728-1UbuntuUSN-8760-1UbuntuUSN-8781-1UbuntuUSN-8726-2UbuntuUSN-8726-3UbuntuUSN-8800-1Ubuntu

Frequently Asked Questions

In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() 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
O3 Security · Impact-Aware SCA

Is CVE-2026-53185 in your dependencies?

Find it across Linux, including transitive dependencies.

Scan my dependencies How O3 SCA works
CVE-2026-53185: Kernel — Fixed in 6.6.143