CVE-2026-45999

What it actually does

This vulnerability is a Linux kernel memory-corruption flaw in the EROFS filesystem LZ4 decompression path. A specially crafted EROFS image can contain illegal compressed extents where the decompressed output page count is smaller than the input page count. In the affected path, an unsigned subtraction involving outpages and inpages can underflow, producing a very large value and causing the kernel to read past the decompressed_pages array. Successful exploitation can trigger an out-of-bounds kernel memory read, potentially exposing sensitive kernel memory or causing a kernel crash and denial of service.

Why it matters to the business

Systems that allow users, services, containers, removable media workflows, image-processing pipelines, or automation to mount or inspect untrusted EROFS filesystem images could be exposed to kernel crashes or possible sensitive data disclosure. Because this affects the kernel, successful exploitation can impact system stability and availability, especially on hosts that process filesystem images at scale. The issue is not currently listed in CISA KEV, has no known mature public exploitation, and has a low EPSS score, so urgency is lower than actively exploited kernel flaws; however, kernel-level memory safety bugs should still be remediated during the next appropriate patch cycle or sooner where untrusted images are handled.

How an attack unfolds

An attacker prepares a malicious EROFS filesystem image with malformed compressed extents that force the kernel into the vulnerable LZ4 in-place decompression logic. The attacker then needs the image to be mounted or otherwise processed by a vulnerable Linux kernel, such as through a user opening a disk image, an automated image scanner, a removable media workflow, or a container/image handling pipeline that supports EROFS. When a file inside the crafted image is read, the kernel attempts to decompress the affected extent. Due to the unsigned underflow, the kernel calculates an invalid page range and reads beyond the expected decompressed_pages array. Depending on memory layout and kernel behavior, this may result in a kernel oops, panic, denial of service, or exposure of adjacent kernel memory.

How to fix it

Upgrade the Linux kernel to a version that includes the upstream EROFS fix for the unsigned underflow in z_erofs_lz4_handle_overlap(). No exact fixed version was provided in the input, so use vendor advisories and distribution package metadata to identify the corrected kernel build for each platform. Where immediate patching is not possible, reduce exposure by blocking untrusted EROFS image mounting, restricting mount privileges, disabling automated processing of untrusted filesystem images, limiting removable-media workflows, and ensuring containers or sandboxed workloads cannot cause the host kernel to mount attacker-supplied EROFS images. Treat mitigation as temporary because the vulnerable code is in kernel filesystem handling.

How to confirm the fix worked

Confirm that each system is running a vendor kernel package that includes the EROFS z_erofs_lz4_handle_overlap() fix. Validate through distribution security advisories, kernel changelogs, package changelogs, or source inspection for the added bounds check preventing the outpages/inpages underflow. On test systems only, controlled reproduction can be attempted by mounting a crafted EROFS image and reading the affected file; a fixed kernel should reject or report the malformed image rather than oopsing or reading out of bounds. Also verify that untrusted users and automated workflows cannot mount EROFS images unless explicitly required.

Typical attack path

1. Create or obtain a crafted EROFS filesystem image containing illegal compressed LZ4 extents.
2. Deliver the image to a target workflow that mounts, scans, or reads EROFS images.
3. Cause the vulnerable system to mount or process the image, potentially requiring user or automated workflow interaction.
4. Trigger a read from the malformed file or extent inside the mounted image.
5. The kernel enters the vulnerable EROFS LZ4 in-place decompression path.
6. The outpages minus inpages calculation underflows, causing an out-of-bounds read past the decompressed_pages array.
7. The system may disclose kernel memory contents, generate a kernel oops, or crash.

How to detect it

Look for evidence that vulnerable systems mounted or read suspicious EROFS images before crashes or kernel errors. Useful sources include kernel logs, system journal, auditd logs, shell history, EDR process telemetry, mount command telemetry, removable media logs, container/runtime logs, CI/CD worker logs, and crash dump directories. Search for EROFS mounts, especially user-initiated or automated mounts of unfamiliar image files, followed by reads from the mounted path and kernel oops, panic, page fault, or general protection fault messages. Correlate timestamps between mount events, file reads, and kernel instability. Because exploitation may only cause a crash or memory exposure without creating persistent artifacts, absence of durable IOCs does not rule out attempted exploitation. Preserve any EROFS images involved in crashes for offline analysis.

• mount -t erofs
• cache_strategy=disabled
• EROFS-fs
• z_erofs_lz4_handle_overlap
• decompressed_pages
• LZ4
• kernel BUG
• kernel oops
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• general protection fault
• Kernel panic - not syncing
• Out of bounds
• corruption report
• /var/crash
• /var/lib/systemd/coredump
• foo.erofs

What your security team should do

• Inventory Linux systems and workflows that mount, scan, or process EROFS filesystem images, including build systems, image-processing services, container platforms, embedded Linux development environments, and removable-media endpoints.
• Prioritize patching systems that handle untrusted disk images or allow local users to trigger filesystem mounts.
• Upgrade to a vendor-supported kernel containing the EROFS LZ4 overlap handling fix.
• Until patched, restrict EROFS mounting to trusted administrators and trusted images only.
• Review sudoers, udev, desktop automount, container runtime, CI/CD, and image-scanning workflows for paths that could mount attacker-controlled filesystem images.
• Monitor kernel logs for EROFS corruption messages, kernel oopses, page faults, or panics associated with EROFS and LZ4 decompression.
• If suspicious crashes are observed after EROFS image handling, preserve the image, kernel logs, crash dump, and timeline for forensic review.