CVE-2026-53165: Linux Kernel iomap Null Pointer Dereference Denial of Service
A race condition in the Linux kernel's I/O mapping layer can cause a null pointer dereference when the system attempts to report a buffered read error. The vulnerability occurs when multiple read operations complete out of order on the same memory page, and truncate operations simultaneously clear the page's metadata. An attacker with network access could exploit this to crash the system or cause a denial of service, though no active exploitation is currently known.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 7.5 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Weaknesses (CWE)
- CWE-476
- Affected products
- 7 configuration(s)
- Published / Modified
- 2026-06-25 / 2026-07-07
NVD description (verbatim)
In the Linux kernel, the following vulnerability has been resolved: iomap: avoid potential null folio->mapping deref during error reporting When a buffered read fails, iomap_finish_folio_read() reports the error with fserror_report_io(folio->mapping->host, ...). This is called after ifs->read_bytes_pending has been decremented by the bytes attempted to be read. For a folio split across multiple read completions, the folio is only guaranteed to stay locked while read_bytes_pending > 0. Once iomap_finish_folio_read() decrements read_bytes_pending, another in-flight read can complete and end the read on the folio, which unlocks it. This allows truncate logic to run and detach the folio (set folio->mapping to NULL). The error reporting path then can dereference a NULL folio->mapping. As reported by Sam Sun, this is the race that can occur: CPU0: failed completion CPU1: final completion CPU2: truncate ----------------------- ---------------------- -------------- read_bytes_pending -= len finished = false /* preempted before fserror_report_io() */ read_bytes_pending -= len finished = true folio_end_read() truncate clears folio->mapping fserror_report_io( folio->mapping->host, ...) ^ NULL deref Fix this by reporting the error first before decrementing ifs->read_bytes_pending.
2 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
CVE-2026-53165 is a null pointer dereference vulnerability in the Linux kernel's iomap subsystem, specifically in iomap_finish_folio_read(). The issue arises from a race condition where error reporting on folio->mapping->host occurs after decrementing ifs->read_bytes_pending. For folios spanning multiple read completions, the folio remains locked only while read_bytes_pending > 0. Once this counter is decremented, concurrent read completions may unlock the folio, allowing truncate logic to execute and set folio->mapping to NULL before the error reporting code dereferences it. The fix involves reporting the error before decrementing the pending bytes counter, ensuring the folio mapping remains valid during the critical section.
Business impact
Exploitation of this vulnerability can cause kernel panic and system downtime, affecting all services dependent on the compromised system. For organizations running database servers, file servers, or other I/O-intensive workloads on Linux, this crash can result in service interruptions and potential data access delays. Cloud providers and hosting platforms are particularly exposed, as workload density increases the likelihood of triggering the race condition.
Affected systems
The Linux kernel is affected. Organizations running Linux distributions across servers, cloud instances, containers, and embedded systems should assess their kernel versions. While the specific patch version is not provided in vendor advisories cited here, the vulnerability affects the iomap buffered read path, which is present across all modern Linux kernel distributions. Verify your kernel version against official Linux vendor security advisories and the upstream kernel.org advisory.
Exploitability
The vulnerability requires network access and leverages a timing-dependent race condition. An attacker cannot guarantee reproduction on a single attempt but can increase likelihood through crafted I/O patterns that trigger concurrent reads on the same folio followed by truncate operations. No known public exploit code exists, and the CVSS score of 7.5 (HIGH) reflects the availability impact despite requiring specific conditions. Exploitation does not grant code execution or privilege escalation—it causes denial of service through kernel crash.
Remediation
Apply the upstream Linux kernel patch that addresses iomap error reporting sequencing. The fix ensures error reporting occurs before read_bytes_pending is decremented, eliminating the window for folio->mapping to be cleared. Affected systems should prioritize kernel updates released after the publication date of June 25, 2026. Organizations should coordinate patching with change management procedures, accounting for system restart requirements.
Patch guidance
Obtain kernel updates from your Linux distribution's official security repository (Red Hat, Canonical, SUSE, etc.) or from kernel.org. The patch involves reordering the error reporting logic in iomap_finish_folio_read() to execute before the read_bytes_pending decrement. Verify against the vendor's published advisory for specific kernel versions and patch levels. Test patches in a staging environment before production deployment, particularly for systems with high I/O concurrency.
Detection guidance
Monitor system logs for kernel panic messages or oops dumps referencing iomap_finish_folio_read() or null pointer dereferences in the I/O mapping subsystem. Unexpected system restarts or hung I/O processes may indicate exploitation. Systems under sustained network I/O load with concurrent reads on large files are at higher risk. Use kernel crash dump analysis tools (kdump, kexec) to capture and review panic details if incidents occur.
Why prioritize this
This vulnerability rates HIGH severity (CVSS 7.5) and should be prioritized for patch deployment within 30 days, particularly for production systems serving I/O-intensive workloads (databases, file servers, NFS). While not currently exploited in the wild, the low complexity of exploitation via network-accessible I/O patterns and the guaranteed availability impact of kernel panic justify rapid remediation. Systems in high-concurrency environments face increased risk.
Risk score, explained
The CVSS 7.5 score reflects: (1) Network-accessible attack vector requiring no user interaction or privileges; (2) High availability impact from guaranteed denial of service via kernel crash; (3) No confidentiality or integrity impact; (4) Attack complexity is low due to timing-dependent nature being reliably triggered under typical I/O workloads. The vulnerability is not listed in the Known Exploited Vulnerabilities catalog, reducing urgency slightly but not eliminating the need for timely patching.
Frequently asked questions
Can this vulnerability lead to data loss or corruption?
No. The vulnerability causes a kernel crash (denial of service) through a null pointer dereference. It does not corrupt data on disk or enable unauthorized access. However, uncontrolled system restarts may interrupt ongoing transactions, so proper shutdown and backup procedures should be maintained.
Do I need to restart my system after applying the patch?
Yes. Linux kernel patches require a system restart to take effect. Plan patching during maintenance windows and use live kernel patching tools (kpatch, livepatch) if your distribution and use case support them, to minimize downtime.
How likely is this vulnerability to be exploited in the wild?
Currently, there are no known public exploits or active exploitation campaigns. However, the vulnerability is straightforward to trigger through normal high-concurrency I/O workloads, so proactive patching is still strongly recommended rather than waiting for in-the-wild evidence.
Which systems are most at risk?
Systems running high-concurrency I/O workloads are at elevated risk: database servers (PostgreSQL, MySQL, MongoDB), NFS servers, container hosts with persistent volume mounts, and cloud virtual machines hosting storage-intensive applications. Single-purpose or lightly-loaded systems face lower practical risk of triggering the race condition, but should still be patched.
This analysis is based on disclosed vulnerability information as of the publication date and vendor advisories. Specific patch version numbers and affected kernel release versions should be verified against official advisories from your Linux distribution and kernel.org. This vulnerability does not enable remote code execution, privilege escalation, or data exfiltration. Organizations should test patches in non-production environments before deployment. SEC.co does not provide guaranteed protection or liability for any use of this analysis. Consult your security team and vendors for deployment decisions. Source: NVD (public-domain), retrieved 2026-08-03. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2026-46110HIGHLinux stmmac NULL Dereference DoS Vulnerability
- CVE-2026-46114HIGHLinux Kernel RDMA RXE Remote Memory Leak via Malformed ATOMIC_WRITE
- CVE-2026-52922HIGHLinux batman-adv NULL Pointer Dereference DoS
- CVE-2026-52929HIGHLinux SCTP Null-Pointer Dereference in Stream Rollback
- CVE-2026-52951HIGHLinux Xe DRM DMA-buf Race Condition – Local DoS via GPU Memory Import
- CVE-2026-52957HIGHLinux Kernel Ceph Null Pointer Dereference Denial of Service
- CVE-2026-52998HIGHLinux Kernel Netfilter NULL Pointer Dereference – Denial of Service
- CVE-2026-53069HIGHLinux Kernel XDP Null Pointer Dereference in Bond Redirect