CVE-2026-46078

What it actually does

CVE-2026-46078 is a Linux kernel EROFS filesystem parsing flaw caused by insufficient validation of directory entry name offsets. A crafted EROFS filesystem image can set a trailing directory entry nameoff value greater than or equal to the directory block size, causing an unsigned underflow in the maxsize - nameoff calculation and allowing strnlen() to read past the intended directory block. The primary impacts are kernel memory disclosure and possible denial of service through kernel fault or crash during filesystem traversal. The CVSS vector indicates local attack, low complexity, no privileges required, and user interaction required, meaning exploitation typically requires a user or automated process to mount or access attacker-supplied EROFS content.

Why it matters to the business

If vulnerable Linux systems process untrusted EROFS filesystem images, an attacker may be able to crash affected systems or expose sensitive kernel memory. This can disrupt workloads, appliances, container hosts, build systems, forensic sandboxes, kiosks, or desktop environments that automatically mount removable media or inspect disk images. Because this issue is not listed in CISA KEV, has very low EPSS, and has no known public exploit maturity in the provided data, broad internet-scale exploitation is unlikely; however, systems that routinely handle untrusted filesystem images remain at higher operational risk.

How an attack unfolds

An attacker prepares a malformed EROFS filesystem image containing a trailing directory entry with an invalid nameoff value at or beyond the valid directory block boundary, and with alignment or layout values that trigger the vulnerable parsing path. The attacker then delivers the image through a medium likely to be mounted or inspected, such as removable media, a downloaded disk image, a container or firmware artifact, or a file submitted to an analysis pipeline. When a vulnerable Linux kernel parses the crafted EROFS directory, the kernel calculates a name length using strnlen() with an underflowed bound, causing an out-of-bounds read past the directory block. Depending on memory layout and kernel behavior, this can result in sensitive memory exposure to a local context or a kernel crash/denial of service. There is no indication from the provided intelligence that this vulnerability is currently used by named threat actors or ransomware campaigns.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the EROFS directory entry nameoff validation fix. Because no exact fixed versions were provided, use the latest security kernel packages from the relevant Linux distribution or upstream stable kernel branch and confirm that the patch for 'erofs: fix the out-of-bounds nameoff handling for trailing dirents' is included. Where immediate patching is not possible, reduce exposure by disabling or restricting EROFS support if it is not required, preventing automatic mounting of untrusted removable media and disk images, limiting who can mount filesystems, and processing untrusted filesystem images only in isolated sandboxes or virtual machines. On systems using module-based EROFS support, consider blacklisting the erofs kernel module if operationally safe.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix for the EROFS trailing dirent nameoff validation issue. Validate by checking distribution security advisories, kernel changelogs, or source patches for added validation that nameoff values are within bounds and that the first name offset is aligned to sizeof(struct erofs_dirent). Confirm the active runtime kernel is the patched kernel, not only that a patched package is installed, by checking the running kernel version after reboot. Assess exposure by determining whether EROFS support is enabled, built into the kernel, or available as a loadable module; whether automount is enabled; and whether systems process untrusted filesystem images. If EROFS is not required, verify that mounting EROFS images fails or that the erofs module cannot be loaded.

Typical attack path

1. Identify a target workflow that mounts, scans, extracts, or otherwise parses untrusted EROFS filesystem images on a vulnerable Linux kernel.
2. Craft an EROFS image with malformed trailing directory entries where nameoff is greater than or equal to the valid directory block size and related directory entry offset constraints are violated.
3. Deliver the crafted image through removable media, a downloadable artifact, container/firmware supply chain content, or an automated file-analysis workflow.
4. Cause a user, service, scanner, or automount component to access the crafted filesystem directory.
5. Trigger vulnerable EROFS directory parsing in the kernel, causing an out-of-bounds read.
6. Use the resulting behavior to cause denial of service or potentially expose kernel memory, depending on the execution path and system configuration.

How to detect it

Look for evidence that vulnerable systems mounted or attempted to mount EROFS images from untrusted sources, followed by kernel warnings, oopses, panics, unexpected reboots, or process failures in tools that inspect filesystem images. Relevant log sources include kernel logs, system journal, audit logs, mount/automount logs, endpoint telemetry, removable-media events, file download records, and sandbox or build pipeline logs. Search for EROFS-related kernel messages near crashes or hangs, especially messages indicating malformed directory entries, out-of-bounds access, general protection faults, page faults, KASAN reports, UBSAN reports, or kernel oops/panic activity. Investigate recent EROFS images from removable media, email/download locations, artifact repositories, container or firmware pipelines, and malware-analysis submissions. Because the vulnerability is a parsing flaw rather than a remote network vulnerability, network IOCs are not expected from the vulnerability itself; detection should focus on local artifact handling and kernel telemetry. If exploitation is suspected, preserve the crafted filesystem image, dmesg/journal output, crash dumps, and audit records showing which process mounted or accessed the image.

• erofs
• EROFS
• mount -t erofs
• type erofs
• filesystem type 'erofs'
• erofs:
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• general protection fault
• kernel BUG
• Oops:
• Kernel panic
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• UBSAN: array-index-out-of-bounds
• strnlen
• erofs_dirent
• nameoff
• /sys/module/erofs
• /proc/filesystems

What your security team should do

• Prioritize patching Linux systems that mount or inspect untrusted filesystem images, including desktops with automount, build servers, firmware/container analysis systems, malware sandboxes, and shared multi-user Linux hosts.
• Track Linux distribution advisories and upgrade to a kernel build containing the upstream EROFS nameoff bounds-checking fix.
• Disable automount of removable media and disk images where not required, especially on endpoints and analysis systems.
• Restrict filesystem mounting privileges and ensure untrusted filesystem parsing occurs only inside disposable, isolated virtual machines or containers with appropriate host isolation.
• If EROFS is not operationally required, disable or blacklist the erofs kernel module where feasible.
• Monitor for kernel crashes, oops messages, or suspicious EROFS mount activity involving recently downloaded or removable images.
• Treat unexpected kernel memory disclosure or repeated crashes during EROFS parsing as potential exploitation attempts and preserve system logs, kernel logs, and the suspicious image for forensic analysis.