linux-kernel - Re: [PATCH] mm/filemap: fix NULL pointer dereference in do_read_cache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CANNWa07Y_GPKuYNQ0ncWHGa4KX91QFosz6WGJ9P6-AJQniD3zw@mail.gmail.com>
Date: Sun, 16 Nov 2025 11:13:42 +0530
From: SHAURYA RANE <ssrane_b23@...vjti.ac.in>
To: Matthew Wilcox <willy@...radead.org>
Cc: akpm@...ux-foundation.org, shakeel.butt@...ux.dev, eddyz87@...il.com, 
	andrii@...nel.org, ast@...nel.org, linux-fsdevel@...r.kernel.org, 
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, 
	linux-kernel-mentees@...ts.linux.dev, skhan@...uxfoundation.org, 
	david.hunter.linux@...il.com, khalid@...nel.org, 
	syzbot+09b7d050e4806540153d@...kaller.appspotmail.com
Subject: Re: [PATCH] mm/filemap: fix NULL pointer dereference in do_read_cache_folio()

On Sat, Nov 15, 2025 at 2:14 AM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Sat, Nov 15, 2025 at 01:07:29AM +0530, ssrane_b23@...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.