Re: [PATCH] mm/filemap: fix NULL pointer dereference in do_read_cache_folio()

SHAURYA RANE
2025-11-16T05:43:54Z

On Sat, Nov 15, 2025 at 2:14 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Sat, Nov 15, 2025 at 01:07:29AM +0530, ssrane_b23@ee.vjti.ac.in wrote:
> > When read_cache_folio() is called with a NULL filler function on a
> > mapping that does not implement read_folio, a NULL pointer
> > dereference occurs in filemap_read_folio().
> >
> > The crash occurs when:
> >
> > build_id_parse() is called on a VMA backed by a file from a
> > filesystem that does not implement ->read_folio() (e.g. procfs,
> > sysfs, or other virtual filesystems).
>
> Not a fan of this approach, to be honest. This should be caught at
> a higher level. In __build_id_parse(), there's already a check:
>
> /* only works for page backed storage */
> if (!vma->vm_file)
> return -EINVAL;
>
> which is funny because the comment is correct, but the code is not.
> I suspect the right answer is to add right after it:
>
> + if (vma->vm_file->f_mapping->a_ops == &empty_aops)
> + return -EINVAL;
>
> Want to test that out?
Thanks for the suggestion.
Checking for
a_ops == &empty_aops
is not enough. Certain filesystems for example XFS with DAX use
their own a_ops table (not empty_aops) but still do not implement
->read_folio(). In those cases read_cache_folio() still ends up with
filler = NULL and filemap_read_folio(NULL) crashes.
Since build_id_parse() only works for true page-backed mappings, I think the
most reliable fix is to fail even earlier in _build_id_parse() before
we even reach the filemap path:

if (!vma->vm_file->f_mapping->a_ops->read_folio)
return -EINVAL;

This catches XFS+DAX and any other filesystem that lacks ->read_folio,
and it fails fast at the correct layer rather than deeper in mm/filemap.

I think this is the right approach. I’ll send a v2 shortly.