CVE-2026-46089: zram: do not forget to endio for partial discard requests
In the Linux kernel, the following vulnerability has been resolved:
zram: do not forget to endio for partial discard requests
As reported by Qu Wenruo and Avinesh Kumar, the following
getconf PAGESIZE
65536
blkdiscard -p 4k /dev/zram0
takes literally forever to complete. zram doesn't support partial
discards and just returns immediately w/o doing any discard work in such
cases. The problem is that we forget to endio on our way out, so
blkdiscard sleeps forever in submit_bio_wait(). Fix this by jumping to
end_bio label, which does bio_endio().
Security readout for executives and security teams
Plain-English summary
CVE-2026-46089 is a Linux kernel zram bug where certain partial discard requests may never complete. The documented impact is an operation hanging indefinitely, not data theft or code execution. Severity is not published in the provided sources, so urgency depends on whether the environment uses zram and discard operations.
Executive priority
Treat this as a targeted availability concern rather than a confirmed breach risk. Prioritize routine kernel patching for systems that use zram, especially operational platforms where stuck maintenance jobs could affect reliability.
Technical view
The zram driver returns early for unsupported partial discard requests but failed to call bio_endio. As a result, callers such as blkdiscard can sleep indefinitely in submit_bio_wait. Kernel stable commits are referenced as fixes, but the provided version data is incomplete and inconsistent.
Likely exposure
Exposure is most likely on Linux systems using zram block devices where discard operations can be issued. The source example involves a 64 KB page size and 4 KB partial discard. Systems not using zram are unlikely to be affected by this specific path.
Exploitation context
The bundle does not cite active exploitation, KEV listing, remote attackability, privilege requirements, or weaponized exploit evidence. The described trigger is a local discard operation against a zram device that causes the caller to wait indefinitely.
Researcher notes
The key defect is missing completion handling on an unsupported partial discard path. Evidence supports an indefinite wait condition. The bundle lacks CVSS, CWE, precise privilege model, and clean affected-version ranges, so avoid overstating reach or impact.
Mitigation direction
Check vendor kernel advisories for CVE-2026-46089 applicability and fixed packages.
Prioritize updates on systems that use zram with discard-capable workflows.
Apply kernel updates containing one of the referenced stable fixes.
Where patching is delayed, review operational reliance on zram discard behavior.
Validation and detection
Inventory Linux hosts using zram devices.
Compare running kernel builds against vendor guidance for CVE-2026-46089.
Confirm whether kernel packages include the referenced zram endio fix.
Review monitoring for stuck discard or storage maintenance jobs involving zram.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-46089 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
6Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
May 27, 2026, 12:58 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.