PT-2026-52261 · Linux · Linux
Published
2026-06-25
·
Updated
2026-06-25
·
CVE-2026-53165
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux