Look up another CVE · open CVE-2026-53165 in the interactive tracker

CVE-2026-53165

iomap: avoid potential null folio->mapping deref during error reporting

7.5 EPSS 0.3% AV:N

Published 2026-06-25 (4 months ago) by the Linux kernel CNA. Subsystem fs/iomap. Debian urgency: unimportant.

What to do, per Debian release

Debian's own status for CVE-2026-53165 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	not affected	6.1.190-1	Nothing to do. bookworm never shipped the vulnerable code.
Debian 13trixie	not affected	6.12.113-1	Nothing to do. trixie never shipped the vulnerable code.
Debian 14forky	fixed	7.0.13-1	Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.0.13-1	Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

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.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

fs/iomap/buffered-io.c

What this is: FILESYSTEMS [IOMAP]MAINTAINERS section matched on fs/iomap/ · linux-xfs@vger.kernel.org · Supported

Check it on the machine

grep -wE 'CONFIG_BLOCK|CONFIG_FS_IOMAP' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

Show whether Debian builds this, per release

Debian builds this code. Every release below compiles the affected file into the kernels it ships.

bookworm, trixie, forky, sidy

y: built into the kernel image on every flavour - only a patch removes it

Build switches: CONFIG_BLOCK, CONFIG_FS_IOMAP
Reads as: all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-06-25 (4 months ago)source
CVSS: 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it
Attack vector: network (AV:N)source
EPSS: 0.34%, higher than 26.3% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: unimportantsource
Subsystem: fs/iomap

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
7.0	7.0.13	1ad453817a40
7.0	7.1	2eea7f44b9c8

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:NAttack vector, network: Remote file-serving paths such as ksmbd and nfsd can drive VFS reads and truncates on iomap-backed filesystems, reaching the vulnerable completion path through network requests. A local syscall path also exists, but the highest reasonable exposure is a writable network share/export.
AC:LAttack complexity, low: The bug is a race, but an attacker can issue concurrent read/readahead and truncate or size-change operations and retry the window. There is no memory-layout prerequisite, and uncertainty is resolved toward the higher-severity AC:L.
PR:NPrivileges required, none: A writable anonymous or guest SMB/NFS export can expose the read and truncate operations without prior authentication. If the export requires credentials this would be PR:L, but the highest reasonable deployment is unauthenticated access.
UI:NUser interaction, none: The attacker can trigger both the read/error-reporting side and the truncate side directly through requests. No separate victim action is required.
S:UScope, unchanged: The fault occurs within the kernel filesystem/page-cache security authority. It does not cross a VM, IOMMU, or sandbox boundary.
C:NConfidentiality impact, none: The vulnerable dereference is a NULL folio->mapping dereference during error reporting. This is a crash condition, not an information disclosure primitive.
I:NIntegrity impact, none: The bug does not corrupt attacker-controlled memory or provide a write primitive. It only dereferences a NULL mapping pointer.
A:HAvailability impact, high: A NULL pointer dereference in kernel context can oops or panic the system. Repeated triggering can deny availability of the affected host.