Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp6555668rwb; Mon, 5 Dec 2022 14:12:28 -0800 (PST) X-Google-Smtp-Source: AA0mqf4i6UoqZdugZ3N5dhw4LB/nglb337NMqJU4zReLkcKTPoSjBdxiWAbXhdZTxAPerU/9sNyb X-Received: by 2002:a17:902:cad3:b0:189:8b52:cee7 with SMTP id y19-20020a170902cad300b001898b52cee7mr40465795pld.62.1670278348584; Mon, 05 Dec 2022 14:12:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670278348; cv=none; d=google.com; s=arc-20160816; b=tbpcTxSjxjmWd7oAkS2TO2NNpImMd3Bmtm/e2BVgns//I3u7/GD7IksMmvyIwLXrd3 VOVLq1+lAS+umwmwg2e1UE1SNC3vWPUie39RWtXH+Hdk6TY3/rwg7LyrEUj2tzzYsXMZ GzBcCCZHJDd9rDsbAscXVLyakT0iH/qev/DC81E7rsRxHRJsVhgaXrJAe5lXeVHmURJf gDAgTCHZ+MYDSvApbQe37CcVjgR0O0s8yl+AC3mvBpwQssCB6wCiJUViZWTMiylYBR1M vccwkkLQJT1Q2kUCE3AyEVufcQLsYMcEcpEK9l2rZTX0n5m4QxpMyvFBwHGx6v1sBH+e Eg4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=cC7ZM3itu4XmclOIPc55YEuaARhUE6mDokgemZhoJX0=; b=ZFq2Q2gRnIcrnmBb+76Wrx+/qgEWkhVXQJSExqn7pioMbWLt4YuCaax/gJxXskRWrQ vgWuAp83c43wba1adgli2fBQVDnagY7sddRsljAKVaR1SWRtCrsbka8S0r0NI1KObtOv 2PhqfK9bxrkP+WD3UmT1b+wKKn3gGa8JMzwkFnt1V/YI9iVwJnOlCXeNbwLL5zG7Lwfq UrYX2H7an1Yf/4socjzrzMFa3L/5KF/4yE0XaabzeNq99V/8pnKLXnyJoW88e0jbchLo 22MkrAbOWGqNY9Xi5BI68gTgvASpHsKS88ga/JDtCy8/nW2xjbPYyuI+ajXSOe0dlb7p RCoQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=lWURtoNP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ik7-20020a170902ab0700b001897bfe1ec1si15233656plb.345.2022.12.05.14.12.18; Mon, 05 Dec 2022 14:12:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=lWURtoNP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233529AbiLEV4v (ORCPT + 80 others); Mon, 5 Dec 2022 16:56:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57638 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230295AbiLEV4Q (ORCPT ); Mon, 5 Dec 2022 16:56:16 -0500 Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29551218F for ; Mon, 5 Dec 2022 13:56:05 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id h6so2756853iof.9 for ; Mon, 05 Dec 2022 13:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cC7ZM3itu4XmclOIPc55YEuaARhUE6mDokgemZhoJX0=; b=lWURtoNPamkBoYDP9BONRNGIovt6ceE8B2EGn0FtEdxaUCMnG7dKEAW1xkk0xUqc23 H+yhnD6JpqpkOcI/JoPyCjHDb9dBnWorQH/ftN/ORMIQ6KAD0UgOBV27pC+JyAGrcfTt ctAvCCzw57ioKz6+p/XGoPhYMFzKOIaHjDIrJYdCdUWMKe0U8rtDNFJyawq8v4SF0ol5 LnBYmPJdaieEkGewpJHXJqR7rQOK/9M2w/uvtlL6tpPM1cW2dW9yPqBplhygPvmiGfj0 FM27OkM+pneyo0bc9AwFZnxFuPDe5PaJwoj47I5jr6NdXjpl5bLthKlIjaIDrkUrwBtk ljnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cC7ZM3itu4XmclOIPc55YEuaARhUE6mDokgemZhoJX0=; b=yHpP8wxZl5g4rXhLP35ofSsYSnWEBDDxdQOglrqFJwB0LmI8ALHDMCbzcDiK6w38vq r1rKFlFthHUjNSDmlJr4wh6nJH51Tw3HZv1ltII8xAJ2qf4BBq1mTz73i3/9HRAtkFDB 1ixvD01gwiDU/o7V/hO8wuS0TwdNVEXbMyk45uD0i4dcqMeHjYW6cx84mVWJvJ6S4kaJ b/zU3omOLnoGhJ/AJWj8FuDH2bD9Ned8DTpp6zoAdGxw39AVHMJHm0oT7TU8T9n8flsq 4Ljn2jpGyjwLniqsmfkJ6uXVrAdSORPRPwOZd0+EZYClChHt0zvyCC5I4JQfPPk9dl1u opzg== X-Gm-Message-State: ANoB5pmT6Ry6akFdisWcAQuY0Ak8Fdm2C2waXONR3GLwdJQg/eXGCADR yntCUo3zaUMpvbgiyJtCWjqWhaHrrrJlkgDIXaGXbg== X-Received: by 2002:a5d:8f84:0:b0:6d9:56fc:ef25 with SMTP id l4-20020a5d8f84000000b006d956fcef25mr29317501iol.56.1670277364483; Mon, 05 Dec 2022 13:56:04 -0800 (PST) MIME-Version: 1.0 References: <20221205192304.1957418-1-Liam.Howlett@oracle.com> <20221205123250.3fc552d96fcca5dc58be8443@linux-foundation.org> In-Reply-To: <20221205123250.3fc552d96fcca5dc58be8443@linux-foundation.org> From: Jann Horn Date: Mon, 5 Dec 2022 22:55:28 +0100 Message-ID: Subject: Re: [PATCH v2] mmap: Fix do_brk_flags() modifying obviously incorrect VMAs To: Andrew Morton Cc: Liam Howlett , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Yu Zhao , Jason Donenfeld , Matthew Wilcox , SeongJae Park , Vlastimil Babka Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 5, 2022 at 9:32 PM Andrew Morton wrote: > On Mon, 5 Dec 2022 19:23:17 +0000 Liam Howlett wrote: > > Add more sanity checks to the VMA that do_brk_flags() will expand. > > Ensure the VMA matches basic merge requirements within the function > > before calling can_vma_merge_after(). > > I't unclear what's actually being fixed here. > > Why do you feel we need the above changes? > > > Drop the duplicate checks from vm_brk_flags() since they will be > > enforced later. > > > > Fixes: 2e7ce7d354f2 ("mm/mmap: change do_brk_flags() to expand existing VMA and add do_brk_munmap()") > > Fixes in what way? Removing the duplicate checks? The old code would expand file VMAs on brk(), which is functionally wrong and also dangerous in terms of locking because the brk() path isn't designed for file VMAs and therefore doesn't lock the file mapping. Checking can_vma_merge_after() ensures that new anonymous VMAs can't be merged into file VMAs. See https://lore.kernel.org/linux-mm/CAG48ez1tJZTOjS_FjRZhvtDA-STFmdw8PEizPDwMGFd_ui0Nrw@mail.gmail.com/ .