[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yo5uI9w7lll5B93r@casper.infradead.org>
Date: Wed, 25 May 2022 18:57:55 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: syzbot <syzbot+5b96d55e5b54924c77ad@...kaller.appspotmail.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] KASAN: use-after-free Read in do_sync_mmap_readahead
On Wed, May 25, 2022 at 09:58:42AM -0700, Andrew Morton wrote:
> On Wed, 25 May 2022 07:26:22 -0700 syzbot <syzbot+5b96d55e5b54924c77ad@...kaller.appspotmail.com> wrote:
> > BUG: KASAN: use-after-free in do_sync_mmap_readahead+0x465/0x9f0 mm/filemap.c:3006
> > Read of size 8 at addr ffff88801fedb050 by task syz-executor.5/1755
>
> A race?
>
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> /* Use the readahead code, even if readahead is disabled */
> if (vmf->vma->vm_flags & VM_HUGEPAGE) {
> fpin = maybe_unlock_mmap_for_io(vmf, fpin);
> ractl._index &= ~((unsigned long)HPAGE_PMD_NR - 1);
> ra->size = HPAGE_PMD_NR;
> /*
> * Fetch two PMD folios, so we get the chance to actually
> * readahead, unless we've been told not to.
> */
> --> if (!(vmf->vma->vm_flags & VM_RAND_READ))
> ra->size *= 2;
> ra->async_size = HPAGE_PMD_NR;
> page_cache_ra_order(&ractl, ra, HPAGE_PMD_ORDER);
> return fpin;
> }
> #endif
>
> Reading from vmf->vma->vm_flags was OK, then it suddenly wasn't.
Ohh, that makes sense. We unlocked the mmap_sem, so the file is
pinned, but the VMA isn't. I'll whip up a patch.
Powered by blists - more mailing lists