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,URIBL_BLOCKED,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 AEEB2C41604 for ; Wed, 7 Oct 2020 06:31:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0330120797 for ; Wed, 7 Oct 2020 06:31:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="bQ9SYdOa" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0330120797 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 EA6A16B005C; Wed, 7 Oct 2020 02:31:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E3010900002; Wed, 7 Oct 2020 02:31:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA82B6B0068; Wed, 7 Oct 2020 02:31:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0088.hostedemail.com [216.40.44.88]) by kanga.kvack.org (Postfix) with ESMTP id 99A2E6B005C for ; Wed, 7 Oct 2020 02:31:38 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 67198181AE86F for ; Wed, 7 Oct 2020 06:31:37 +0000 (UTC) X-FDA: 77344158234.08.deer67_4f03801271cd Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 3FED21819E76B for ; Wed, 7 Oct 2020 06:31:37 +0000 (UTC) X-HE-Tag: deer67_4f03801271cd X-Filterd-Recvd-Size: 4928 Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Wed, 7 Oct 2020 06:31:36 +0000 (UTC) Received: by mail-ed1-f66.google.com with SMTP id b12so917987edz.11 for ; Tue, 06 Oct 2020 23:31:36 -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=dC3PZSlkcJ0dFT0SKLSrvJ3nzCII9YDRrt3iNoXhzDA=; b=bQ9SYdOa3CZxR358nnaIyBpVeWAq8dWQLwY8bXMYb+QLUXbn4Z+cq1/NJgj87h8XlM Ppe8gPbnxBrkC3e9QcCZSmSbmsbDfszXvx7hlupUzv8ejtCe50yXx1hKUHKyo3OTAWjr +rWx0luG6oWF0Sq2iYtOA8ktsKXEm5NczU1PuEoh9e6cF8z2XBKOdB1F2cw3oywjHDpH aqh0S4HYqswYIL5q3EDrcWxYBITzMVtzP/ZLpBChw1+ZexMwjMdmXZLAJKoWfr45sM8c H9Xxs3j2Mm+lkLzcHZxP+LNJpm/jObhXnnZSuP0ShAc2hMMeTmrHrvDTJVO23/zbIKcK gmJw== 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=dC3PZSlkcJ0dFT0SKLSrvJ3nzCII9YDRrt3iNoXhzDA=; b=crQNvU0I4P4/W+4ISgjQGuNaUwz1lFcFW+D5olDX6tgWlNcAPCDRYfccwXg1W/31Re z7TeUHymABameku+MdNuoRmzDCo3kpcnxzh6Ffr92ZTvRpF0hJrm7rKaWGsW8fP8n51q JVjVGfVIJA3m/XErlbAZSVpw2Hiaxm7GIdiCGXsfk34f4jNAG1HsFa8tvBtzEtHD1CtH 7Asl+knjmPhbQ30BFaWAUNze3yCVaXXiE2kcdpNstENEJ1PCA43J1hbnIjHleNws/pNK drz19uw1bN3owTmE+viycDPCJOqAYkFvZVMOrEJe41Q/A1RXyAK0CRAcK9axtm/RIu9Q vakw== X-Gm-Message-State: AOAM5307JlLP4VHp12UiAQLzOZsJIJEkZmp5CT/mlNdibPssOD9ljP+S nauSNt5//fc27IBcgVUys3DHEdqIfusT8ldqa9cgqA== X-Google-Smtp-Source: ABdhPJyF8NfAjL1Cbi5pv/Pd1HHkioaL79QB5pL7lyeQNrVFB2Xx456ps1w6Z7PK3swGrITqTcVQRGonfrViPF0gjS8= X-Received: by 2002:a05:6402:7d2:: with SMTP id u18mr1914452edy.69.1602052295019; Tue, 06 Oct 2020 23:31:35 -0700 (PDT) MIME-Version: 1.0 References: <0fb905cc-77a2-4beb-dc9c-0c2849a6f0ae@oracle.com> <20201007061659.GA21685@infradead.org> In-Reply-To: <20201007061659.GA21685@infradead.org> From: Jann Horn Date: Wed, 7 Oct 2020 08:31:08 +0200 Message-ID: Subject: Re: SPARC version of arch_validate_prot() looks broken (UAF read) To: Christoph Hellwig Cc: Khalid Aziz , "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.000152, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Oct 7, 2020 at 8:17 AM Christoph Hellwig wrote: > On Wed, Oct 07, 2020 at 02:45:39AM +0200, Jann Horn wrote: > > > 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? > > Any reason to not just call arch_validate_prot after taking the mmap > lock? Then the next easy steps are: - change the signature of arch_validate_prot() to also accept a length or end parameter (because a start address without an end address is completely useless) - add a loop over the VMAs in that range in SPARC's arch_validate_prot() And then comes the annoying part: figure out what to do in that loop if the range is not fully covered by VMAs. To fully avoid changing the normal mprotect() ABI, you'd have to accept cases where parts of the range are unmapped - but hopefully nobody relies on that particular weirdness, so maybe you can just throw an error in that case? Even so, the normal error code for that is -ENOMEM, but arch_validate_prot() has a boolean return, so for that, you'd have to change the return type, too. I guess the cleanest approach might be to just validate up to the first gap and then return "everything's good" and rely on mprotect() bailing out on its own? Ah - at first I thought that you'd also have to deal with concurrent stack VMA expansion from find_expand_vma() (which we really should get rid of somehow sometime), but luckily that still at least holds the mmap lock in read mode, and here we hold it in write mode, so we don't have to worry about that. So I guess that'd be the way to go for this approach? Alright, I guess I'll send patches after all, hopefully after at least compile-testing them...