CVE-2026-53165

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iomap: avoid potential null folio-&gt;mapping deref during error reporting<br /> <br /> When a buffered read fails, iomap_finish_folio_read() reports the error<br /> with fserror_report_io(folio-&gt;mapping-&gt;host, ...). This is called after<br /> ifs-&gt;read_bytes_pending has been decremented by the bytes attempted to<br /> be read.<br /> <br /> For a folio split across multiple read completions, the folio is only<br /> guaranteed to stay locked while read_bytes_pending &gt; 0. Once<br /> iomap_finish_folio_read() decrements read_bytes_pending, another<br /> in-flight read can complete and end the read on the folio, which unlocks<br /> it. This allows truncate logic to run and detach the folio (set<br /> folio-&gt;mapping to NULL). The error reporting path then can dereference a<br /> NULL folio-&gt;mapping. As reported by Sam Sun, this is the race that can<br /> occur:<br /> <br /> CPU0: failed completion CPU1: final completion CPU2: truncate<br /> ----------------------- ---------------------- --------------<br /> read_bytes_pending -= len<br /> finished = false<br /> /* preempted before<br /> fserror_report_io() */<br /> read_bytes_pending -= len<br /> finished = true<br /> folio_end_read()<br /> truncate clears<br /> folio-&gt;mapping<br /> fserror_report_io(<br /> folio-&gt;mapping-&gt;host, ...)<br /> ^ NULL deref<br /> <br /> Fix this by reporting the error first before decrementing<br /> ifs-&gt;read_bytes_pending.