CVE-2026-31467

What it actually does

This is a Linux kernel denial-of-service flaw in the EROFS decompression/bio completion path. In certain block I/O completion contexts, such as dm-verity or storage recovery paths, EROFS can perform decompression directly in process context and call vm_map_ram() with GFP_KERNEL allocation semantics. Under memory pressure, that allocation can trigger reclaim and swapping I/O while a bio submission path is already active, leading to submit_bio_wait() deadlock. The practical technical impact is a kernel hang or storage I/O stall that can render the affected system unresponsive and require reboot or recovery.

Why it matters to the business

Successful exploitation or accidental triggering can cause Linux systems using affected kernel versions and EROFS-related storage paths to hang, disrupting services, appliances, embedded devices, mobile/edge platforms, or container hosts that depend on kernel availability. The CVSS availability impact is high, but current exploitation signals are low: EPSS is 0.00378 and flat over 30 days, it is not listed in CISA KEV, and no public exploit maturity is reported. Organizations should still prioritize remediation where EROFS, dm-verity, constrained memory, or read-only compressed filesystem images are used in production because the outcome is service outage rather than data theft.

How an attack unfolds

An attacker would need to cause the vulnerable kernel to enter the affected EROFS read/decompression path while the system is under memory pressure and while the bio completion path is executing in a context such as dm-verity or block device recovery. By repeatedly triggering reads from compressed EROFS content and simultaneously inducing memory pressure, the attacker may cause vm_map_ram() to allocate with GFP_KERNEL, enter direct reclaim, initiate swap writeback, and call submit_bio_wait() while the bio list is already active. This can deadlock the kernel I/O path, causing a hang or severe service unavailability. In practice, exploitation depends heavily on whether EROFS is in use, whether an attacker can influence file reads or memory pressure, and whether the underlying storage stack reaches the vulnerable completion path.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the EROFS bio completion allocation context, specifically the change that wraps the affected decompression path with memalloc_noio_save() and memalloc_noio_restore() so memory reclaim does not initiate unsafe I/O. No exact fixed package versions were provided in the input, so use the fixed kernel version from the relevant Linux distribution or vendor advisory. Where immediate patching is not possible, reduce exposure by disabling or avoiding EROFS where feasible, avoiding compressed EROFS images on untrusted workloads, limiting attacker ability to induce memory pressure, ensuring adequate memory/swap configuration, and applying operational safeguards such as watchdog-based recovery for systems where availability is critical. Mitigations should be treated as temporary because the durable fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel package includes the EROFS GFP_NOIO/memalloc_noio fix from the distribution or upstream stable branch. Validate by checking vendor kernel changelogs, package advisory metadata, or source patches for references to EROFS, z_erofs_endio, GFP_NOIO, memalloc_noio_save(), or memalloc_noio_restore(). Inventory systems for EROFS usage by checking loaded modules, filesystem support, mounted filesystems, boot images, appliance images, or verified read-only partitions. After patching, reboot into the fixed kernel and verify the active kernel version, not only the installed package. In test environments only, reproduce representative EROFS read/decompression workloads under memory pressure and confirm the system no longer hangs or reports storage deadlocks.

Typical attack path

1. Identify or target a Linux system running an affected kernel with EROFS support and compressed EROFS content in use.
2. Find an execution path that causes repeated reads from EROFS-backed files, images, or partitions, especially through dm-verity or similar verified block-device stacks.
3. Create or amplify memory pressure so kernel allocations in the decompression path may enter reclaim or swapping I/O.
4. Trigger the EROFS bio completion/decompression path repeatedly until vm_map_ram() attempts GFP_KERNEL allocation in the wrong I/O context.
5. Cause submit_bio_wait() re-entry/deadlock in the storage path, resulting in kernel hang, I/O stall, or system unavailability.

How to detect it

This issue is primarily a denial-of-service condition and may leave few attacker-specific artifacts. Detection should focus on evidence of kernel deadlock, hung I/O, EROFS decompression activity, memory reclaim pressure, and abrupt system recovery or watchdog reset. Review kernel logs from journald, syslog, dmesg persistence, crash dumps, kdump/vmcore, hypervisor console logs, BMC/IPMI event logs, and monitoring telemetry for hangs around EROFS, z_erofs, vm_map_ram, direct reclaim, swap writeback, submit_bio_wait, dm-verity, mmc block recovery, soft lockups, or hung tasks. Correlate these events with spikes in file reads from EROFS-backed paths, abnormal memory pressure, swap activity, container or user workloads consuming memory, and unexplained service outages. There are no known public threat actors or ransomware campaigns associated with this CVE in the provided data, so absence of malware indicators does not rule out exploitation or accidental triggering.

• z_erofs_endio
• vm_map_ram
• submit_bio_wait
• __swap_writepage
• shrink_folio_list
• __alloc_pages_direct_reclaim
• __pte_alloc_kernel
• mmc_blk_mq_recovery
• f2fs_submit_read_io
• erofs
• EROFS
• dm-verity
• task blocked for more than
• INFO: task
• hung task
• BUG: soft lockup
• watchdog: BUG: soft lockup
• kernel: hung_task
• blocked for more than 120 seconds
• Out of memory
• direct reclaim
• swap_writepage

What your security team should do

• Prioritize patching Linux systems that use EROFS, dm-verity, compressed read-only images, embedded/appliance-style deployments, or memory-constrained environments.
• Track distribution advisories for the exact fixed kernel package versions and confirm systems are rebooted into the fixed kernel after installation.
• Inventory EROFS exposure across servers, endpoints, containers hosts, mobile/edge devices, and appliance images rather than relying only on generic Linux package presence.
• Monitor for kernel hangs, storage I/O stalls, soft lockups, hung tasks, and EROFS-related errors, especially on systems under memory pressure.
• If patching is delayed, reduce untrusted access to workloads that can force EROFS reads or create memory pressure, and consider disabling EROFS where operationally feasible.
• Because EPSS is low, flat, not KEV-listed, and no mature exploit is reported, handle through normal kernel patch SLAs unless the affected systems provide critical availability or run EROFS-heavy workloads.