CVE-2026-64146

What it actually does

This Linux kernel flaw is a reference-count leak in the EROFS filesystem extended-attribute initialization path. When malformed or unexpected EROFS metadata causes certain error paths after erofs_read_metabuf(), the kernel may exit without releasing the associated metabuf/folio reference. Repeated triggering can consume kernel memory or keep filesystem metadata pages pinned, potentially causing resource exhaustion, degraded performance, or denial of service. There is no public evidence from the provided data that this enables code execution or privilege escalation.

Why it matters to the business

Systems that mount untrusted or attacker-supplied EROFS images could be forced into memory pressure, instability, or service disruption. The highest-risk environments are those that automatically mount container, embedded, appliance, mobile, or firmware images, or that process filesystem images from external sources. EPSS is very low and it is not listed in CISA KEV, so broad active exploitation is not currently indicated, but kernel-level denial-of-service issues can still have high operational impact where untrusted images are handled.

How an attack unfolds

An attacker would need a way to cause a vulnerable Linux kernel to parse crafted EROFS filesystem metadata, typically by convincing a system, sandbox, analysis pipeline, container runtime workflow, or privileged user to mount or inspect a malicious EROFS image. The crafted image would target inline extended-attribute metadata so that erofs_init_inode_xattrs() obtains a metabuf and then takes an error path that fails to drop the folio reference. By repeating the operation across many crafted images, mounts, or inode lookups, the attacker may gradually leak kernel references and drive memory pressure or instability. Practical exploitation depends heavily on whether an attacker can get EROFS images mounted or parsed by the target system.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the EROFS metabuf cleanup in inode xattr initialization. Because no exact affected products or fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution, device vendor, or kernel branch once available. As interim mitigations, avoid mounting untrusted EROFS images, restrict mount privileges, disable or avoid EROFS support where not required, ensure automated image-processing pipelines run in isolated environments, and apply least privilege to services that handle filesystem images.

How to confirm the fix worked

Confirm that the running kernel package includes the EROFS fix by checking the distribution security advisory, kernel changelog, or source tree for the cleanup that calls erofs_put_metabuf() on the out_unlock path in erofs_init_inode_xattrs(). Verify exposure by checking whether EROFS support is enabled or loaded, whether EROFS filesystems are mounted, and whether automated workflows process untrusted EROFS images. After patching, reboot into the fixed kernel and confirm the running kernel version, not only the installed package version.

Typical attack path

1. Identify a target system or workflow that supports the Linux EROFS filesystem.
2. Create or obtain a malformed EROFS image with extended-attribute metadata designed to trigger the vulnerable error path.
3. Deliver the image to a component or user that will mount, scan, unpack, or otherwise cause the kernel to parse the EROFS metadata.
4. Trigger repeated inode extended-attribute initialization failures so the metabuf/folio reference is not released.
5. Repeat the trigger until kernel memory pressure, degraded performance, mount failures, or denial of service occurs.

How to detect it

There are no known public exploitation indicators in the provided data, and this issue is not listed as known exploited. To assess possible prior abuse, review kernel logs, system journals, audit logs, mount activity, and image-processing service logs for repeated EROFS mount or metadata errors followed by rising memory pressure, page-cache anomalies, OOM killer activity, or host instability. Focus on systems that handled externally supplied EROFS images. Correlate suspicious events with file ingestion records, container/image build jobs, firmware unpacking jobs, or user mount attempts. Look for bursts of failed EROFS operations rather than a single failure, because the likely impact requires repeated triggering.

What your security team should do

• Prioritize patching systems that mount or process untrusted filesystem images, especially container, firmware, embedded Linux, appliance, and image-analysis environments.
• Inventory hosts with EROFS support enabled or EROFS mounts in use.
• Restrict who can mount filesystems and prevent unprivileged or automated workflows from mounting untrusted EROFS images without sandboxing.
• Monitor for repeated EROFS mount failures, kernel memory pressure, OOM events, or abnormal filesystem-image processing activity.
• If EROFS is not operationally required, consider disabling the module or removing support from custom kernel builds.
• Track vendor advisories for exact fixed kernel package versions because fixed_versions were not provided in the input.