CVE-2026-53015

What it actually does

This is an integer-width flaw in the Linux kernel EROFS filesystem implementation on 32-bit platforms. Logical cluster numbers were stored in 32-bit-sized types in some code paths, so calculations such as shifting a logical cluster number by the cluster size could truncate at the 4 GiB boundary. When a 32-bit kernel reads an affected EROFS image with large offsets or crafted cluster metadata, it may calculate the wrong filesystem offset, leading to incorrect reads, I/O errors, kernel warnings, or denial of service. The issue is primarily relevant to 32-bit Linux systems with EROFS support enabled; 64-bit platforms are not the main risk described by the fix.

Why it matters to the business

Systems that rely on 32-bit Linux kernels and EROFS images, such as embedded devices, appliances, mobile-derived platforms, or specialized edge systems, could experience crashes, failed mounts, corrupted reads, or unreliable software/content delivery if they process a malicious or malformed EROFS image. The currently available risk signals indicate low urgency: EPSS is very low, the issue is not in the CISA KEV catalog, it is not known to be used in ransomware campaigns, and no public exploit maturity is reported. Organizations with exposed workflows that ingest untrusted filesystem images should still prioritize patching because kernel filesystem bugs can affect system stability.

How an attack unfolds

An attacker would need a path to cause a vulnerable 32-bit Linux system to mount or otherwise access a maliciously crafted EROFS filesystem image. The attacker prepares an EROFS image containing logical cluster metadata that causes offset calculations to exceed the 32-bit range when shifted by the cluster size. When the vulnerable kernel parses the image and reads affected compressed data or large logical clusters, the truncated calculation points to an incorrect offset. The practical result is expected to be denial of service, mount/read failure, or incorrect data access rather than a confirmed remote code execution path. Exploitation is most plausible where users, update systems, container/image tooling, removable media workflows, or device provisioning processes accept EROFS images from untrusted sources.

How to fix it

Apply a Linux kernel update from the relevant distribution, device vendor, or long-term-support kernel branch that includes the EROFS fix changing logical cluster number handling to use 64-bit types consistently. Where immediate patching is not possible, reduce exposure by disabling EROFS support if it is not required, preventing unprivileged users from mounting filesystem images, blocking ingestion of untrusted EROFS images, and restricting removable media or update-package workflows that cause automatic mounting or inspection. On systems where EROFS is built as a module and not needed, consider blacklisting the module as a temporary mitigation. Because fixed package versions were not provided in the input, use vendor advisories and kernel changelogs to confirm inclusion of the patch titled "erofs: unify lcn as u64 for 32-bit platforms."

How to confirm the fix worked

Confirm whether systems are 32-bit and whether EROFS support is enabled. Check architecture with commands such as `uname -m`; 32-bit targets include i386, i486, i586, i686, armv7, armhf, and other 32-bit architectures. Check EROFS availability using `/proc/filesystems`, loaded modules, or kernel configuration, for example `grep -i erofs /proc/filesystems`, `lsmod | grep erofs`, or `zgrep CONFIG_EROFS_FS /proc/config.gz /boot/config-$(uname -r)`. Validate remediation by confirming the installed kernel package or vendor firmware release includes the EROFS 64-bit logical-cluster fix. If feasible in a lab, test a previously affected 32-bit kernel and the patched kernel against a large or crafted EROFS image that exercises offsets beyond 4 GiB; the patched kernel should not show truncation-related failures. Avoid running untrusted proof-of-concept images on production systems.

Typical attack path

1. Identify a target running a 32-bit Linux kernel with EROFS filesystem support enabled.
2. Create or modify an EROFS filesystem image so that logical cluster calculations cross the 4 GiB truncation boundary.
3. Deliver the image through a channel the target will mount or inspect, such as removable media, firmware/update packages, image-processing pipelines, or local user-controlled files.
4. Trigger kernel parsing by mounting the EROFS image or accessing files within it.
5. Cause incorrect offset calculation in the vulnerable EROFS code path, potentially resulting in I/O errors, kernel warnings, failed reads, or system instability.

How to detect it

There are no public, CVE-specific indicators of compromise for this issue, and exploitation would generally be local or image-delivery based rather than network-signature based. To investigate possible prior exploitation, review kernel logs and system journals on 32-bit systems for EROFS-related mount failures, I/O errors, kernel warnings, oopses, or crashes around the time untrusted images, removable media, firmware packages, or update bundles were processed. Useful log sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, audit logs for mount activity, endpoint telemetry for loop-device setup, and file integrity or update-system logs showing newly introduced `.erofs`, firmware, or filesystem image files. Correlate suspicious EROFS errors with process execution such as `mount`, `losetup`, update agents, firmware unpackers, container/image tools, or automated scanners. Because the underlying bug is a numeric truncation flaw, absence of a crash or log entry does not conclusively prove it was not triggered; focus on whether untrusted EROFS images were mounted or parsed before patching.

• erofs
• EROFS
• mount -t erofs
• losetup
• /proc/filesystems
• CONFIG_EROFS_FS
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Inventory 32-bit Linux systems and embedded devices that have EROFS support enabled, prioritizing systems that process firmware, update, container, or removable-media images.
• Patch affected kernels through the appropriate distribution or device-vendor update channel, confirming the EROFS logical-cluster 64-bit fix is included.
• Restrict mounting or automated scanning of untrusted EROFS images, especially by privileged services or users.
• Disable or blacklist EROFS on systems where it is not operationally required.
• Review image-ingestion, firmware-update, and provisioning pipelines for controls that validate image origin and integrity before mounting.
• Monitor kernel logs on 32-bit systems for EROFS-related errors, failed mounts, I/O anomalies, or crashes after handling filesystem images.
• Treat this as lower immediate priority than actively exploited KEV vulnerabilities, but do not ignore it on embedded or appliance fleets where kernel updates are infrequent.