CVE-2026-46089

What it actually does

This is a local denial-of-service flaw in the Linux kernel zram block device driver. When zram receives a discard/TRIM request that is smaller than the system page size or otherwise not aligned to zram's supported discard granularity, the driver exits the partial-discard path without completing the submitted bio via bio_endio(). The calling process can then remain blocked indefinitely in submit_bio_wait(), causing operations such as blkdiscard against /dev/zram* to hang. The flaw does not provide confidentiality or integrity impact, code execution, or privilege escalation by itself, but it can degrade availability by tying up processes and potentially disrupting systems that rely on zram-backed swap or compressed block devices.

Why it matters to the business

An authenticated local user or process can cause zram discard operations to hang indefinitely, which may disrupt maintenance jobs, storage-management workflows, swap-related operations, or automation that interacts with zram devices. On systems that depend heavily on zram for memory pressure handling, repeated or automated triggering could contribute to operational instability and service degradation. The issue is not known to be exploited in the wild, is not listed in CISA KEV, and has a low EPSS score, so remediation should be handled through normal kernel patch management unless zram is widely enabled on critical Linux fleets or exposed to untrusted local workloads.

How an attack unfolds

An attacker first needs local access with sufficient permission to issue discard operations against a zram block device, or they need to influence a privileged local service or maintenance script that performs such operations. They identify an active zram device such as /dev/zram0 and a system page size larger than the discard granularity being requested, for example a 64 KiB page-size system receiving 4 KiB discard requests. They then submit a partial discard using a tool such as blkdiscard with a small step or range. Because the vulnerable zram path returns without completing the bio, the issuing process remains asleep waiting for I/O completion. Repeating this against zram-backed devices can leave administrative commands, scripts, or services stuck, creating a local availability impact.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the zram fix ensuring partial discard requests complete with bio_endio(). Because no product-specific fixed versions were provided, use the latest stable kernel available for the relevant distribution and confirm the vendor advisory references the zram partial discard endio fix or this vulnerability. Where immediate patching is not possible, reduce exposure by disabling unused zram devices, preventing untrusted local users or workloads from accessing /dev/zram* block devices, restricting execution of blkdiscard/fstrim-like operations to trusted administrators, and reviewing automation that performs discard operations on zram-backed devices. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel is the patched version recommended by the Linux distribution or vendor, not just that a patched package is installed. Verify whether zram is active by checking /sys/block/zram* or /dev/zram*. On a non-production test system only, reproduce the previously problematic behavior with a controlled partial discard operation and confirm the command returns rather than hanging indefinitely. Review kernel changelogs or vendor advisories for the zram fix that routes partial discard handling to the end_bio path. Also validate that access permissions and operational procedures prevent untrusted users or workloads from issuing discard commands against zram devices.

Typical attack path

1. Gain local shell access or execute code through an existing local account, container escape condition, compromised service account, or scheduled job context.
2. Confirm that zram is available and active by checking for /dev/zram* devices or zram entries under /sys/block/.
3. Determine that the system can issue partial discard requests to zram, such as a discard size smaller than the system page size or not aligned to the supported discard granularity.
4. Run a discard operation against a zram device, for example using blkdiscard with a small step size.
5. The vulnerable kernel path returns without calling bio_endio(), causing the caller to block indefinitely in submit_bio_wait().
6. Optionally repeat or trigger the behavior through automation to accumulate hung processes or disrupt maintenance and memory/storage operations.

How to detect it

Look for evidence of attempted or successful triggering through process accounting, audit logs, EDR telemetry, shell history, sudo logs, and kernel logs. Useful sources include auditd execve events for blkdiscard or fstrim, sudo/auth logs showing privileged discard commands, process telemetry showing commands targeting /dev/zram*, and dmesg/journalctl messages for hung tasks, blocked processes, or zram-related warnings. A successful trigger is likely to leave a blkdiscard or related maintenance process stuck in uninterruptible sleep rather than producing a clean application error. Investigate repeated discard commands with small step sizes or ranges against /dev/zram devices, especially when run by unexpected users or from unusual automation paths. There are no public reports of active exploitation, no KEV listing, and no named threat actors associated with this issue, so detection should focus on local misuse, accidental triggering, and operational impact rather than known campaign infrastructure.

• blkdiscard -p 4k /dev/zram0
• blkdiscard -p 4096 /dev/zram0
• blkdiscard /dev/zram0
• /dev/zram0
• /dev/zram1
• /sys/block/zram0
• /sys/block/zram1
• submit_bio_wait
• bio_endio
• zram
• INFO: task blkdiscard
• blocked for more than
• hung_task_timeout_secs
• D state
• fstrim
• blkdiscard

What your security team should do

• Inventory Linux systems with active zram devices, especially servers, appliances, developer workstations, and container hosts using zram-backed swap.
• Prioritize patching systems where untrusted local users, shared shell access, multi-tenant workloads, or untrusted containers can reach host block devices.
• Deploy the latest vendor-supported kernel containing the zram partial discard fix and reboot systems into the updated kernel.
• If patching is delayed, disable zram where it is not required or restrict access to /dev/zram* devices to trusted administrative contexts only.
• Search telemetry for hung blkdiscard, fstrim, or storage-maintenance processes involving /dev/zram* and investigate repeated attempts by non-administrative users.
• Add monitoring for kernel hung-task messages and processes stuck in uninterruptible sleep while executing discard operations against zram.
• Review scheduled jobs, configuration-management tasks, and maintenance scripts to ensure they do not issue unsupported partial discard operations to zram devices.