[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170301231334.GO5816@redhat.com>
Date: Thu, 2 Mar 2017 00:13:34 +0100
From: Andrea Arcangeli <aarcange@...hat.com>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: Al Viro <viro@...iv.linux.org.uk>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...e.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Vlastimil Babka <vbabka@...e.cz>,
Konstantin Khlebnikov <koct9i@...il.com>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
syzkaller <syzkaller@...glegroups.com>
Subject: Re: fs: use-after-free in userfaultfd_exit
On Wed, Mar 01, 2017 at 07:48:00PM +0100, Dmitry Vyukov wrote:
> Hello,
>
> I've got the following use-after-free report while running syzkaller
> fuzzer on 86292b33d4b79ee03e2f43ea0381ef85f077c760:
Yes, I posted the fix for this one last Friday, I found it during
stress testing, it triggered the first time post-upstream merging
despite I was running the same stress testing with SLUB poisoning
enabled before.
This affects all apps, also the ones that don't use userfaultfd, it's
a locking issue. Furthermore the cost of userfaultfd_exit was not
acceptable, if something it had to be activated by a flag in mm->flags
(such an optimization would have been absolutely trivial though).
Thankfully I realized another feature (UFFDIO_COPY -ENOSPC retval) can
provide the same information at zero cost so I could drop
userfaultfd_exit as a whole.
https://marc.info/?l=linux-mm&m=148796041217814&w=2
The fix is already included in -mm along with the other fix for
VM_FAULT_NOPAGE.
Thanks,
Andrea
Powered by blists - more mailing lists