PT-2026-52261 · Linux · Linux
Publicado
2026-06-25
·
Atualizado
2026-06-25
·
CVE-2026-53165
Nenhuma
Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
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.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Linux