linux-kernel - Re: [syzbot] [fs?] [mm?] KCSAN: data-race in __filemap_remove_folio / folio

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+YeV8zU2x+3dpJJFez5_33ic3q7B2_+KYrcNOQxooRWpw@mail.gmail.com>
Date:   Mon, 24 Apr 2023 15:49:04 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     syzbot <syzbot+606f94dfeaaa45124c90@...kaller.appspotmail.com>,
        djwong@...nel.org, hch@...radead.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, linux-xfs@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [fs?] [mm?] KCSAN: data-race in __filemap_remove_folio /
 folio_mapping (2)

On Mon, 24 Apr 2023 at 15:21, Matthew Wilcox <willy@...radead.org> wrote:
>
> On Mon, Apr 24, 2023 at 09:38:43AM +0200, Dmitry Vyukov wrote:
> > On Mon, 24 Apr 2023 at 09:19, syzbot
> > <syzbot+606f94dfeaaa45124c90@...kaller.appspotmail.com> wrote:
> > If I am reading this correctly, it can lead to NULL derefs in
> > folio_mapping() if folio->mapping is read twice. I think
> > folio->mapping reads/writes need to use READ/WRITE_ONCE if racy.
>
> You aren't reading it correctly.
>
>         mapping = folio->mapping;
>         if ((unsigned long)mapping & PAGE_MAPPING_FLAGS)
>                 return NULL;
>
>         return mapping;
>
> The racing write is storing NULL.  So it might return NULL or it might
> return the old mapping, or it might return NULL.  Either way, the caller
> has to be prepared for NULL to be returned.
>
> It's a false posiive, but probably worth silencing with a READ_ONCE().

Yes, but the end of the function does not limit effects of races. I
think this can still crash on NULL deref.

The simplest example would be to compile this:

struct address_space *folio_mapping(struct folio *folio)
{
        ...
        mapping = folio->mapping;
        if ((unsigned long)mapping & PAGE_MAPPING_FLAGS)
                return NULL;

        return mapping;
}

ret = !mapping_unevictable(folio_mapping(folio)) &&
        !folio_test_mlocked(folio);

static inline bool mapping_unevictable(struct address_space *mapping)
{
        return mapping && test_bit(AS_UNEVICTABLE, &mapping->flags);
}

to this:

if (!((unsigned long)folio->mapping & PAGE_MAPPING_FLAGS) && folio->mapping)
   if (test_bit(AS_UNEVICTABLE, &folio->mapping->flags))

which does crash.