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: <ZEaN7PP794H2vbe/@casper.infradead.org>
Date:   Mon, 24 Apr 2023 15:10:52 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Dmitry Vyukov <dvyukov@...gle.com>
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, Apr 24, 2023 at 03:49:04PM +0200, Dmitry Vyukov wrote:
> 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

I thought it did.  I was under the impression that the compiler was not
allowed to extract loads from within the function and move them outside.
Maybe that changed since C99.

> to this:
> 
> if (!((unsigned long)folio->mapping & PAGE_MAPPING_FLAGS) && folio->mapping)
>    if (test_bit(AS_UNEVICTABLE, &folio->mapping->flags))
> 
> which does crash.

Yes, if the compiler is allowed to do that, then that's a possibility.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ