CVE-2026-53165

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, iomapfinishfolioread() reports the error with fserrorreportio(folio->mapping->host, ...). This is called after ifs->readbytes_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 readbytespending > 0. Once iomapfinishfolioread() decrements readbytes_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 ----------------------- ---------------------- -------------- readbytespending -= len finished = false /* preempted before fserrorreportio() */ readbytespending -= len finished = true folioendread() truncate clears folio->mapping fserrorreportio( folio->mapping->host, ...) ^ NULL deref

Fix this by reporting the error first before decrementing ifs->readbytespending.