From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by kanga.kvack.org (Postfix) with ESMTP id ACF4F6B0033 for ; Wed, 1 Nov 2017 06:17:48 -0400 (EDT) Received: by mail-oi0-f69.google.com with SMTP id v9so2002865oif.15 for ; Wed, 01 Nov 2017 03:17:48 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id v18si167823oif.108.2017.11.01.03.17.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Nov 2017 03:17:47 -0700 (PDT) Date: Wed, 1 Nov 2017 11:17:44 +0100 From: Andrea Arcangeli Subject: Re: KASAN: use-after-free Read in __do_page_fault Message-ID: <20171101101744.GA1846@redhat.com> References: <94eb2c0433c8f42cac055cc86991@google.com> <8e92c891-a9e0-efed-f0b9-9bf567d8fbcd@suse.cz> <4bc852be-7ef3-0b60-6dbb-81139d25a817@suse.cz> <20171031141152.tzx47fy26pvx7xug@node.shutemov.name> <20171031191506.GB2799@redhat.com> <94aa563c-14da-7892-51a0-e1799cdad050@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94aa563c-14da-7892-51a0-e1799cdad050@suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Vlastimil Babka Cc: "Kirill A. Shutemov" , Dmitry Vyukov , syzbot , Jan Beulich , "H. Peter Anvin" , Josh Poimboeuf , "Kirill A. Shutemov" , ldufour@linux.vnet.ibm.com, LKML , Andy Lutomirski , Ingo Molnar , syzkaller-bugs@googlegroups.com, Thomas Gleixner , the arch/x86 maintainers , Andrew Morton , Michal Hocko , Hugh Dickins , David Rientjes , linux-mm@kvack.org, Linus Torvalds , Thorsten Leemhuis On Wed, Nov 01, 2017 at 08:42:57AM +0100, Vlastimil Babka wrote: > The vma should be pinned by mmap_sem, but handle_userfault() will in some > scenarios release it and then acquire again, so when we return to In the above message and especially in the below comment, I would suggest to take the opportunity to more accurately document the specific scenario instead of "some scenario" which is only "A return to userland to repeat the page fault later with a VM_FAULT_NOPAGE retval (potentially after handling any pending signal during the return to userland). The return to userland is identified whenever FAULT_FLAG_USER|FAULT_FLAG_KILLABLE are both set in vmf->flags". > + * in some scenario (and not return VM_FAULT_RETRY), we have to be Thanks, Andrea -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org