CVE-2026-53174

What it actually does

This is a Linux kernel overlayfs logic error in directory iteration for nested overlay mounts. In ovl_iterate_merged(), the kernel stores PTR_ERR(cache) before confirming whether cache is actually an error pointer. When ovl_cache_get() succeeds, the pointer value can be truncated and later returned as a bogus non-zero error from readdir/getdents64 processing. The practical impact is incorrect error propagation during overlay-on-overlay directory reads, potentially causing directory listings and applications that rely on them to fail unexpectedly. Based on the available description and current exploit maturity, this is primarily an availability and reliability issue, not a known privilege-escalation or code-execution vulnerability.

Why it matters to the business

Systems using Linux overlayfs, especially container hosts, build systems, CI runners, image builders, or environments with nested overlay mounts, may experience failed directory reads, application errors, job failures, or degraded service reliability. The issue is not listed in CISA KEV, is not associated with ransomware use, and has a very low EPSS score, so broad active exploitation is unlikely; however, organizations that rely heavily on overlayfs should still remediate through normal kernel update cycles to avoid operational instability.

How an attack unfolds

An attacker, unprivileged user, test workload, or containerized process that can trigger directory enumeration over nested overlayfs mounts can exercise the vulnerable path. The sequence begins with a directory read operation such as getdents64 against an outer overlay mount. The kernel enters iterate_dir(), reaches ovl_iterate_merged(), and obtains a valid cache from ovl_cache_get(). Because the code calculates PTR_ERR(cache) before confirming IS_ERR(cache), a successful pointer value may be interpreted later as a non-zero error. In overlay-on-overlay scenarios, recursive directory iteration through an inner overlay mount increases the likelihood of reaching the vulnerable logic. The result is an incorrect error returned to userspace, causing directory traversal or listing operations to fail. There is no public indication from the provided data that this enables arbitrary code execution, data theft, or privilege escalation.

How to fix it

Apply a Linux kernel update that includes the overlayfs fix to compute PTR_ERR(cache) only on the actual error path after IS_ERR(cache) is true. Because no affected product list or exact fixed versions were provided, use the fixed kernel package supplied by the relevant Linux distribution, appliance vendor, cloud image provider, or upstream stable kernel branch. Prioritize systems that use overlayfs heavily, including container hosts, Kubernetes nodes, Docker/Podman hosts, CI/CD runners, build farms, image builders, and nested container environments. If immediate patching is not possible, reduce exposure by avoiding nested overlayfs configurations where feasible, limiting untrusted local/container workloads that can create or exercise overlay mounts, and scheduling restarts into patched kernels as soon as operationally possible.

How to confirm the fix worked

Confirm the running kernel includes the vendor patch for this vulnerability, not merely that the package is installed; Linux systems usually require a reboot or live-patch activation before the fixed kernel is in use. Validate with vendor advisories, kernel changelogs, package metadata, and the active kernel version reported by uname -r. In overlayfs-heavy environments, perform functional testing by enumerating directories through representative overlay mounts, including nested overlay-on-overlay cases, and confirm getdents64/readdir operations complete without unexpected errors. For container platforms, verify all worker nodes, base images that include kernels, and custom host images have been updated or rebuilt as appropriate.

Typical attack path

1. Gain the ability to run code or trigger file enumeration on a Linux system that uses overlayfs.
2. Create or interact with an overlay-on-overlay mount arrangement, commonly seen in container, build, or layered filesystem workflows.
3. Trigger directory enumeration using readdir/getdents64 through the outer overlay mount.
4. Cause the kernel to enter ovl_iterate_merged() and successfully obtain an overlay directory cache via ovl_cache_get().
5. Reach the faulty error-handling path where a valid cache pointer may be treated as a bogus non-zero error.
6. Observe failed directory listing, application errors, or workload disruption rather than normal directory contents.

How to detect it

This issue is not expected to leave strong compromise artifacts because exploitation primarily results in incorrect error returns during overlayfs directory reads rather than code execution or persistence. To assess whether it was exercised, review kernel logs, audit logs, container runtime logs, CI/build logs, and application logs for repeated directory listing failures involving overlayfs or nested overlay mounts. Useful sources include dmesg, journald, /var/log/kern.log, /var/log/messages, container runtime logs from Docker/containerd/Podman, Kubernetes node events, and build-system job logs. Look for failures around getdents64, readdir, overlayfs directory reads, or stack traces containing overlayfs functions such as ovl_iterate_merged(), ovl_cache_get(), ovl_dir_read_merged(), or ovl_dir_read(). Correlate these events with workloads that create nested overlays or perform intensive directory traversal. Because these indicators can also occur during benign bugs or testing, treat them as exposure/exercise signals rather than proof of malicious compromise.

• ovl_iterate_merged
• ovl_cache_get
• ovl_dir_read_merged
• ovl_dir_read
• getdents64
• overlayfs
• overlay-on-overlay
• iterate_dir

What your security team should do

• Track the issue as a kernel reliability vulnerability and remediate through the standard Linux kernel patch process, with higher priority for systems using overlayfs or nested container/build workflows.
• Inventory container hosts, CI runners, build servers, developer workstations, and appliances that rely on overlayfs.
• Confirm whether distribution or cloud-provider kernel updates include the overlayfs fix; deploy them and reboot into the fixed kernel where required.
• If patching must be delayed, avoid nested overlayfs configurations and restrict untrusted workloads that can exercise overlay mounts.
• Monitor for unusual spikes in directory enumeration failures, container runtime errors, or kernel logs referencing overlayfs directory iteration.
• Because there is no KEV listing, no ransomware association, low EPSS, and no known mature exploit, do not prioritize above actively exploited remote code execution or privilege escalation issues unless overlayfs-related outages are occurring.