CVE-2026-45943

What it actually does

This is a Linux kernel memory-safety flaw in the EROFS filesystem decompression path. When reading compressed EROFS data that uses ztailpacking pclusters, the kernel can add a pcluster to an I/O chain before its inline compressed folio has been validated. Under certain timing conditions, such as interruption by a fatal signal during read_mapping_folio(), z_erofs_decompress_pcluster() may incorrectly assume the data is valid and dereference a NULL pointer. The most direct technical impact is a local kernel crash and denial of service. Because the issue occurs in kernel filesystem handling, any successful trigger affects the stability of the entire host, not just the calling process.

Why it matters to the business

Systems that mount and read affected compressed EROFS images can be crashed by a local user or by software that can cause vulnerable EROFS reads, resulting in service interruption, node reboots, failed workloads, and potential availability loss for appliances, embedded systems, container hosts, Android-derived systems, or Linux distributions that rely on EROFS images. The CVSS score indicates high availability impact, but exploitation currently appears immature, EPSS is low, and it is not listed in CISA KEV, so remediation should be prioritized for systems where untrusted users, workloads, or images can interact with mounted EROFS filesystems.

How an attack unfolds

An attacker first needs local execution or another way to influence file reads against a mounted EROFS filesystem that uses the affected compressed ztailpacking layout. The attacker then causes reads of specially arranged inline compressed data and attempts to hit the vulnerable timing window where inline data retrieval is interrupted before the pcluster is fully valid but after it has been queued for decompression. When the kernel later processes the decompression queue, it may treat the pcluster as valid and dereference a NULL pointer in the z_erofs_decompress_queue/z_erofs_decompress_pcluster path. The expected result is a kernel oops or panic, which can terminate workloads, force a reboot depending on panic policy, or leave the system unstable. There is no public indication from the provided data that reliable in-the-wild exploitation or ransomware use is occurring.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the EROFS fix for validating/reading inline data before allocating and adding ztailpacking pclusters to I/O chains. No exact fixed kernel versions were provided, so track the vendor advisory for the affected distribution, appliance, Android-derived platform, or embedded Linux build. Where immediate patching is not possible, reduce exposure by avoiding untrusted EROFS images, disabling or restricting EROFS mounts where feasible, preventing unprivileged users or containers from mounting filesystem images, limiting access to mounted EROFS content from untrusted workloads, and using kernel panic/reboot policies appropriate for service availability. Systems that do not mount EROFS filesystems or do not include EROFS support are unlikely to be practically exposed.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or image includes the vendor backport for this EROFS inline data pcluster validation fix. Check the active kernel version with uname -a and compare it against the vendor’s fixed build, not only the upstream version number, because distributions commonly backport fixes. Validate exposure by checking whether EROFS support is present and in use, for example by reviewing loaded modules, kernel configuration, and mounted filesystems. Look for erofs in /proc/filesystems, lsmod output, mount output, /proc/mounts, or container/appliance image documentation. After patching, systems should no longer log EROFS NULL pointer dereferences in z_erofs_decompress_queue when reading compressed EROFS content.

Typical attack path

1. Obtain local code execution or access to a workload that can read from a mounted EROFS filesystem.
2. Ensure the target reads compressed EROFS content using ztailpacking pclusters, potentially from a crafted or attacker-controlled EROFS image if mounting such images is permitted.
3. Repeatedly trigger reads against the affected inline data while inducing interruption or signal timing conditions that cause inline folio validation to fail.
4. Cause the vulnerable decompression path to process an invalid pcluster as though it were valid.
5. Trigger a kernel NULL pointer dereference, resulting in a kernel oops, panic, service disruption, or host reboot.

How to detect it

To determine whether this was already triggered, review kernel logs and crash artifacts rather than application logs. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, pstore/ramoops records, kdump/vmcore metadata, crash dump analysis, and host monitoring events for kernel oops, panic, or unexpected reboot. Search for EROFS messages followed by a NULL pointer dereference and call traces containing z_erofs_decompress_queue, z_erofs_runqueue, z_erofs_read_folio, or related filemap read functions. Also correlate events with reads from mounted EROFS filesystems, recent mounting of EROFS images, container or workload activity that accessed read-only compressed images, and local processes receiving fatal signals around the time of the crash. Repeated similar crashes on the same host or immediately after accessing a specific EROFS image are stronger indicators than a single isolated kernel fault. There are no known network indicators because exploitation is local and filesystem-triggered.

• erofs: (device
• z_erofs_pcluster_begin: failed to get inline data
• failed to get inline data -4
• Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
• z_erofs_decompress_queue
• z_erofs_decompress_pcluster
• z_erofs_runqueue
• z_erofs_read_folio
• filemap_read_folio
• Call trace:
• /proc/filesystems
• /proc/mounts
• type erofs

What your security team should do

• Prioritize patching Linux systems that mount EROFS filesystems, especially multi-user servers, container hosts, embedded/appliance platforms, mobile/Android-derived systems, and environments that process untrusted filesystem images.
• Inventory EROFS usage by searching for mounted erofs filesystems and enabled EROFS kernel support across Linux fleets.
• Restrict unprivileged filesystem mounting and block untrusted EROFS image mounting through container runtime policy, user namespace restrictions, AppArmor/SELinux policy, or mount controls where applicable.
• Review kernel logs for historical crashes involving z_erofs_decompress_queue, z_erofs_runqueue, or EROFS inline data read failures to identify possible prior triggering.
• Tune alerting for repeated kernel oops/panic events involving EROFS decompression, as repeated crashes may indicate attempted exploitation or a malformed image in production.
• Because EPSS is currently low and there is no KEV listing, prioritize based on actual EROFS exposure and local-user/untrusted-workload risk rather than treating all Linux hosts as equally urgent.