CVE-2026-53165

What it actually does

This Linux kernel flaw is a race condition in the iomap buffered-read completion path. During an error path in iomap_finish_folio_read(), the kernel may dereference folio->mapping->host after another completion and truncate operation have unlocked and detached the folio, leaving folio->mapping as NULL. The likely result is a kernel NULL pointer dereference, which can trigger a kernel oops or panic depending on kernel configuration and workload. The impact is primarily local denial of service rather than code execution, based on the available description.

Why it matters to the business

Systems running affected Linux kernels may be susceptible to crashes when specific filesystem read-error and truncate timing conditions occur. In production, this could cause service interruption, node reboots, workload failover, data-processing job failures, or degraded availability for systems using filesystems backed by iomap-based buffered I/O. The vulnerability is not currently in CISA KEV, is not reported as used in ransomware campaigns, has low EPSS, and has no public exploit maturity reported, so remediation should be prioritized with normal kernel maintenance unless the environment has high availability requirements or untrusted local users/workloads.

How an attack unfolds

An attacker would need a way to influence local filesystem activity on an affected kernel. They would attempt to create a race where a buffered read on an iomap-backed file fails while the same folio is split across multiple read completions. One completion enters the error-reporting path and is preempted after decrementing the pending byte counter. Another completion finishes the folio read and unlocks the folio. A concurrent truncate then detaches the folio and clears its mapping. When the first path resumes, it reports the I/O error by dereferencing folio->mapping->host, but folio->mapping is NULL, causing a kernel fault. Practically, exploitation would most likely be a local denial-of-service attempt requiring careful timing, filesystem activity, and conditions that produce read errors.

How to fix it

Upgrade to a Linux kernel version that includes the fix for this iomap race condition. The upstream fix changes the ordering in iomap_finish_folio_read() so the filesystem I/O error is reported before read_bytes_pending is decremented, preventing another completion and truncate from clearing folio->mapping before error reporting. If vendor fixed versions are not yet available, apply the relevant distribution kernel security update when released, track vendor advisories for backported patches, and reboot systems into the patched kernel. As interim mitigations, restrict untrusted local shell/container access, limit workloads that can generate aggressive concurrent read/truncate patterns, and prioritize patching systems where local users or untrusted workloads can interact with shared filesystems.

How to confirm the fix worked

Confirm the running kernel includes the vendor or upstream patch for the iomap_finish_folio_read() ordering fix. Validate by checking the installed and booted kernel package version against the distribution advisory once available, not only the installed package list. On source-built kernels, verify that error reporting in iomap_finish_folio_read() occurs before decrementing ifs->read_bytes_pending. After patching, reboot and confirm the active kernel version with uname or equivalent host inventory tooling. Review recent kernel logs for prior NULL pointer dereference traces involving iomap_finish_folio_read(), fserror_report_io(), folio_end_read(), or truncate activity to assess whether similar crashes occurred before remediation.

Typical attack path

1. Obtain the ability to run code or trigger filesystem operations locally on a system using an affected Linux kernel.
2. Create or target files on a filesystem path that uses the iomap buffered-read path.
3. Induce or encounter buffered read failures while reads are split across multiple completions for the same folio.
4. Race another read completion so the folio read is finalized and the folio is unlocked.
5. Concurrently truncate the file so the folio is detached and folio->mapping is cleared.
6. Allow the earlier failed completion path to resume and dereference the now-NULL mapping during error reporting.
7. Cause a kernel oops or panic, resulting in denial of service or node instability.

How to detect it

Look for evidence of kernel crashes or oops events rather than network indicators, because this issue is a local kernel race with no known remote signature. Review journald, syslog, kern.log, dmesg archives, crash dump metadata, and kernel panic reports for NULL pointer dereferences in or near iomap_finish_folio_read(), fserror_report_io(), folio_end_read(), truncate paths, or iomap buffered-read error handling. Correlate crashes with local processes performing high-rate file reads, truncates, file replacement, or filesystem stress activity, especially on storage-heavy workloads. If kdump or vmcore collection is available, inspect stack traces for the affected functions and confirm whether folio->mapping was NULL during fserror_report_io(). Because there are no public reports of exploitation, treat matching crashes as suspicious but not conclusive without workload correlation and kernel crash analysis.

• iomap_finish_folio_read
• fserror_report_io
• folio_end_read
• folio->mapping
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops: 0000
• kernel panic
• unable to handle kernel NULL pointer dereference
• read_bytes_pending
• truncate clears folio->mapping

What your security team should do

• Track Linux distribution advisories for this CVE and schedule kernel updates during the next maintenance window, with higher urgency for multi-user systems, container hosts, storage-heavy servers, and systems with untrusted local workloads.
• Inventory systems by running kernel version and identify hosts using kernels that include the affected iomap code path.
• Prioritize patch validation on systems where a kernel panic would create customer-facing downtime or interrupt critical workloads.
• Restrict unnecessary local execution paths and untrusted filesystem-intensive workloads until patched.
• Monitor kernel logs and crash dump systems for NULL pointer dereferences involving iomap_finish_folio_read(), fserror_report_io(), folio mapping, or folio truncate operations.
• Ensure crash dump collection is enabled on critical Linux systems so suspected exploitation or triggering can be investigated after a kernel fault.