CVE-2026-53165: Linux Kernel Race Condition Vulnerability

CVE-2026-53165 Overview

CVE-2026-53165 is a race condition in the Linux kernel iomap subsystem that can lead to a null pointer dereference during buffered read error reporting. The flaw resides in iomap_finish_folio_read(), which reports I/O errors using fserror_report_io(folio->mapping->host, ...) after decrementing ifs->read_bytes_pending. When a folio spans multiple read completions, the early decrement releases the folio lock and allows concurrent truncate logic to clear folio->mapping, leading to a dereference of a NULL pointer.

Critical Impact
A concurrent truncate racing with a failed buffered read can crash the kernel via a NULL folio->mapping dereference, resulting in denial of service.

Affected Products

Linux kernel versions containing the iomap buffered read error reporting path in iomap_finish_folio_read()
Filesystems using the iomap infrastructure for buffered reads (such as XFS, ext4 with iomap, GFS2, Btrfs where applicable)
Stable kernel branches referenced in the upstream commits 1ad453817a40 and 2eea7f44b9c8

Discovery Timeline

2026-06-25 - CVE CVE-2026-53165 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-53165

Vulnerability Analysis

The vulnerability is a race condition [CWE-362] combined with a NULL pointer dereference in the Linux kernel iomap buffered read completion path. When a buffered read fails, iomap_finish_folio_read() is responsible for reporting the I/O error through fserror_report_io(folio->mapping->host, ...).

The function decrements ifs->read_bytes_pending by the number of bytes attempted before calling the error reporter. For folios split across multiple in-flight read completions, the folio is guaranteed to remain locked only while read_bytes_pending > 0. The early decrement violates this invariant during error reporting.

Once the counter reaches zero on another CPU, folio_end_read() unlocks the folio. Truncate logic can then detach the folio and set folio->mapping to NULL before the failing path resumes. The original CPU subsequently dereferences folio->mapping->host, triggering a kernel oops.

Root Cause

The root cause is incorrect ordering of state updates in iomap_finish_folio_read(). The error reporting call depends on folio->mapping remaining valid, but the function releases its implicit lifetime guarantee (non-zero read_bytes_pending) before performing the report. This creates a TOCTOU-style window between decrementing the counter and dereferencing the mapping pointer.

Attack Vector

Exploitation requires concurrent local activity: a failing buffered read on a folio split across multiple completions and a racing truncate on the same file. The condition is reachable through normal filesystem workloads that experience read errors during truncation, such as those involving unreliable storage, thin-provisioned volumes, or storage hot-removal. The race window is narrow but reproducible under load and was reported by Sam Sun.

No verified public exploit code is available. The upstream fix reorders the operation so that fserror_report_io() is invoked before ifs->read_bytes_pending is decremented, preserving the folio lock across the error reporting call. See the kernel commits 1ad453817a40 and 2eea7f44b9c8 for the patch.

Detection Methods for CVE-2026-53165

Indicators of Compromise

Kernel oops or panic referencing iomap_finish_folio_read in the call trace
NULL pointer dereference faults with faulting address near offset 0 inside fserror_report_io frames
System crashes correlated with storage I/O errors during file truncation operations

Detection Strategies

Monitor dmesg and /var/log/kern.log for kernel BUG, oops, or general protection fault entries pointing to iomap read completion functions
Inspect kernel crash dumps with crash or gdb to confirm the faulting instruction dereferences folio->mapping inside iomap_finish_folio_read()
Correlate filesystem error counters (/proc/fs/, XFS errortag) and SMART/storage events with kernel crashes to identify the failed-read race

Monitoring Recommendations

Enable kdump on production Linux hosts to capture vmcore files for post-mortem analysis of suspected race-condition crashes
Forward kernel logs to a centralized log platform and alert on stack traces containing iomap_finish_folio_read or fserror_report_io
Track host uptime and unplanned reboots across filesystem-heavy workloads to detect repeating crash patterns

How to Mitigate CVE-2026-53165

Immediate Actions Required

Identify hosts running affected Linux kernel versions that use the iomap buffered read path, especially XFS and ext4 deployments
Apply the upstream stable kernel updates containing commits 1ad453817a40 and 2eea7f44b9c8 as soon as they are available from your distribution
Prioritize patching on systems exposed to storage instability, multi-tenant truncation workloads, or untrusted local users who can trigger reads and truncates concurrently

Patch Information

The fix reorders iomap_finish_folio_read() so that fserror_report_io(folio->mapping->host, ...) runs before ifs->read_bytes_pending is decremented. This preserves the folio lock guarantee during error reporting and prevents truncate from clearing folio->mapping mid-call. Reference the upstream commits 1ad453817a40 and 2eea7f44b9c8 and consult your distribution's security advisories for backported kernel packages.

Workarounds

No supported workaround exists at the source level; the issue must be addressed by applying the kernel patch
Reduce exposure by limiting workloads that combine high truncate rates with unreliable storage until patched kernels are deployed
Ensure storage subsystems are healthy to minimize buffered read failures that can trigger the race condition

bash

# Verify current kernel version and check for the patched build from your distribution
uname -r

# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade linux-image-$(uname -r | sed 's/-generic//')-generic

# RHEL/CentOS/Rocky/Alma
sudo dnf update kernel

# Reboot to activate the patched kernel
sudo systemctl reboot