From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8560C4363D for ; Wed, 7 Oct 2020 00:46:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 26C722078E for ; Wed, 7 Oct 2020 00:46:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ofS3M+Bg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 26C722078E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5AD0C6B005C; Tue, 6 Oct 2020 20:46:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 55CB56B0062; Tue, 6 Oct 2020 20:46:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 44AE66B0068; Tue, 6 Oct 2020 20:46:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0095.hostedemail.com [216.40.44.95]) by kanga.kvack.org (Postfix) with ESMTP id 162206B005C for ; Tue, 6 Oct 2020 20:46:08 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 8ECB68249980 for ; Wed, 7 Oct 2020 00:46:07 +0000 (UTC) X-FDA: 77343287574.08.sun21_530cbfb271cb Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 74B541819E769 for ; Wed, 7 Oct 2020 00:46:07 +0000 (UTC) X-HE-Tag: sun21_530cbfb271cb X-Filterd-Recvd-Size: 5461 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Wed, 7 Oct 2020 00:46:06 +0000 (UTC) Received: by mail-ed1-f51.google.com with SMTP id dn5so341530edb.10 for ; Tue, 06 Oct 2020 17:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GiHfqX5YBUl0yySo1pL2gGGbrA6tqlyBkCWwTPB5NN8=; b=ofS3M+BgpBlCmdVu4ulyprSoSciUUGb1Uf38zSGa+0ILdvizmFWWzsTQAB9ztvK/7E YVzD43CP0Fiq2tbj1+zAgUQozJZhOCmkUTYQlJObiymbX86JuMePRskDSHTnXPLOQ8F9 3SbYx306F2TUg/7fAXSL/ZgAfvnJdz+2hE0N95rM8OKtJ0HtrnDTZ6fnr7x5kUmHxQPd T7KLcORg/n5aQK7+9/SvtoieJHtgKqjo29sgvBOwG+nzKCuA6PafVOJrP6VFRmYl5yx/ APyxPH9Pajz+uAJiUhACa5PojVG5H4tHHL3kOWQN7tniv1pNUBkuPK2G+405SozTbYTp xIMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GiHfqX5YBUl0yySo1pL2gGGbrA6tqlyBkCWwTPB5NN8=; b=MHXOn5QOUAuHKG86iiR67yfgSmcdF0xBd3IKPR/jeYZbKizJF9zVPe30Yvj4d/l1Ui 8jeUfg2UYD2nylOEU0HQ+5oV9nFQ9RW2un5kBBEMLSFGKgViVuWcgFlPhqZbY3NQdqud TsaFbkizL+ko1QNy0K4l66nEIeSen1xsYmK3UWNvMmrqo5+VLevbBAP11+fs4eX8shVe SQmpATkeen6y+CvYszU+m9UwWW26+ayqdDFnH2Dk8q92ibHq3fN5wcZX0NSWwNW2Enns ExPiBLppz57MQDWQUh1EaDJNN+pyuiTnA6wXCkPt4Z/7cxtNyViY4JdV8wTG9/Z/ubLh io/g== X-Gm-Message-State: AOAM530WCoHIQZF1rWyWvetLFTZKwP7YVtq3TfNKbX4xLP0rJ5Pto18y ims5wthh65Cqa04PqNLi6x5olkVgdI/cvSjtrbLC7Q== X-Google-Smtp-Source: ABdhPJw3Ia9wju01JmgISNWBKagZYXjISvhNQOdV/iIymh+EUW2r++j7k5Cc0Cwtmcva+LirzNcPmHpvt/PM0Hj0Jnw= X-Received: by 2002:a05:6402:b0e:: with SMTP id bm14mr828322edb.259.1602031565578; Tue, 06 Oct 2020 17:46:05 -0700 (PDT) MIME-Version: 1.0 References: <0fb905cc-77a2-4beb-dc9c-0c2849a6f0ae@oracle.com> In-Reply-To: <0fb905cc-77a2-4beb-dc9c-0c2849a6f0ae@oracle.com> From: Jann Horn Date: Wed, 7 Oct 2020 02:45:39 +0200 Message-ID: Subject: Re: SPARC version of arch_validate_prot() looks broken (UAF read) To: Khalid Aziz Cc: "David S. Miller" , sparclinux@vger.kernel.org, Linux-MM , Khalid Aziz , kernel list , Anthony Yznaga , Andrew Morton Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Sep 29, 2020 at 7:30 PM Khalid Aziz wrote: > On 9/28/20 6:14 AM, Jann Horn wrote: > > From what I can tell from looking at the code: > > > > SPARC's arch_validate_prot() looks up the VMA and peeks at it; that's > > not permitted though. do_mprotect_pkey() calls arch_validate_prot() > > before taking the mmap lock, so we can hit use-after-free reads if > > someone concurrently deletes a VMA we're looking at. > > That makes sense. It will be a good idea to encapsulate vma access > inside sparc_validate_prot() between mmap_read_lock() and > mmap_read_unlock(). > > > > > Additionally, arch_validate_prot() currently only accepts the start > > address as a parameter, but the SPARC code probably should be checking > > the entire given range, which might consist of multiple VMAs? > > > > I'm not sure what the best fix is here; it kinda seems like what SPARC > > really wants is a separate hook that is called from inside the loop in > > do_mprotect_pkey() that iterates over the VMAs? So maybe commit > > 9035cf9a97e4 ("mm: Add address parameter to arch_validate_prot()") > > should be reverted, and a separate hook should be created? > > > > (Luckily the ordering of the vmacache operations works out suIch that > > AFAICS, despite calling find_vma() without holding the mmap_sem, we > > can never end up establishing a vmacache entry with a dangling pointer > > that might be considered valid on a subsequent call. So this should be > > limited to a rather boring UAF data read, and not be exploitable for a > > UAF write or UAF function pointer read.) > > > > I think arch_validate_prot() is still the right hook to validate the > protection bits. sparc_validate_prot() can iterate over VMAs with read > lock. This will, of course, require range as well to be passed to > arch_validate_prot(). In that case, do you want to implement this? When I try to figure out how to implement this based on your suggestion, it ends up a bit ugly because either mprotect has to do some extra checks before calling the hook or the hook has to deal with potentially (partly) unmapped userspace ranges in the supplied range and then figure out what to do about those. (And for extra fun, it also has to be safe against concurrent find_extend_vma() but should probably also not change what happens when the first half of the given address range is mapped and the second half is not mapped? Or does the latter not matter?) It'd also be annoying for me to test since I don't have any setup for testing SPARC stuff (let alone SPARC ADI).