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=-1.0 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 AC623C3A5A0 for ; Mon, 20 Apr 2020 12:06:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7AFCE206DD for ; Mon, 20 Apr 2020 12:06:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7AFCE206DD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 160528E0005; Mon, 20 Apr 2020 08:06:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 111058E0003; Mon, 20 Apr 2020 08:06:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F40788E0005; Mon, 20 Apr 2020 08:06:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0137.hostedemail.com [216.40.44.137]) by kanga.kvack.org (Postfix) with ESMTP id D9A368E0003 for ; Mon, 20 Apr 2020 08:06:49 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 933463A9E for ; Mon, 20 Apr 2020 12:06:49 +0000 (UTC) X-FDA: 76728106938.12.pan44_3b90c3d80812b X-HE-Tag: pan44_3b90c3d80812b X-Filterd-Recvd-Size: 3882 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Apr 2020 12:06:49 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id s10so2671428wrr.0 for ; Mon, 20 Apr 2020 05:06:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=edF3jTKJCmwBXP24QW+hs4+eK0ZIK1QhOCmJr2BmLVk=; b=XboYbqfix7IjAmPAvedMg0fFFVBEQX3TVxsTLxZHe6bjuPLzYgN8q2qgtSwm3yl7pT sZ+5d+oBQOTK3Q6dQrs6gj7j2Rvp+fWr6kXPqNriXAsiwn4hQ0I1yqXlXYCd2pM8H9m4 j6tnz+t8vgg3CCNwtBfuitu1K9rJGG1yo1K21uaCaOuOlGv0f6dOHsDCKRRFUqRdT0ER ZwWHuKOaBB8S+sAEGXL7bac/tk7ZFU2MNrM0SsmcAYp79OjgPR5fsGISkjNTEBtB1XJl amTFswMyp4qTho9USaf7dHwdU/W0OX3wEMXhLM+SMPGFQiM0VESei5TCoKfvgNTMPHp/ 0/Cw== X-Gm-Message-State: AGi0PuaVGgdiqnGcYj13FlV2huW0faREGuxCZkf4QagAXg9T+XI3EbrS Q6OMlHrLA9u0BvUTfsZEEf4= X-Google-Smtp-Source: APiQypLwP8gHt05mogHBT49NZs8LnbShmxI7hMM4zSbtJRJJ8AyBjw5j1m8lHSy26Ee5TGGur+16WA== X-Received: by 2002:adf:b1c8:: with SMTP id r8mr18202154wra.218.1587384408127; Mon, 20 Apr 2020 05:06:48 -0700 (PDT) Received: from localhost (ip-37-188-130-62.eurotel.cz. [37.188.130.62]) by smtp.gmail.com with ESMTPSA id t16sm1127958wrb.8.2020.04.20.05.06.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Apr 2020 05:06:47 -0700 (PDT) Date: Mon, 20 Apr 2020 14:06:45 +0200 From: Michal Hocko To: Li Xinhai Cc: akpm , "linux-mm@kvack.org" Subject: Re: [PATCH 0/3] mm: Fix misuse of parent anon_vma in dup_mmap path Message-ID: <20200420120628.GN27314@dhcp22.suse.cz> References: <1581150928-3214-1-git-send-email-lixinhai.lxh@gmail.com> <20200209165204.73197330d083095e0ad18d6c@linux-foundation.org> <2020021010155155113445@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <2020021010155155113445@gmail.com> Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 10-02-20 10:15:53, Li Xinhai wrote: [...] > >What are the runtime effects of this bug?=A0 How is the bug triggered?= =20 >=20 > Effects of the first one is that causes ramp code to check both parent = and > child's page table, although=A0a page couldn't be mapped by both parent > and child, because child vma has WIPEONFORK so all pages mapped by chil= d > are 'new' and not relevant to parent. >=20 > Effects of the second one is that the relationship of anon_vma of paren= t and > child are totally=A0convoluted. It would cause 'son', 'grandson', ..., = etc, to share > 'parent' anon_vma, which disobey the design rule of =A0reusing anon_vma= (the > rule to be followed is that reusing should among vma of same process, a= nd > vma should not gone through fork). >=20 > So, both issues should cause unnecessary rmap walking and have unexpect= ed > complexity. >=20 > These two issues would not be directly visible, I used debugging code t= o check > the anon_vma pointers of parent and child when inspecting the suspiciou= s > implementation of issue #2, then find the problem. I am still not completely clear on the user effect. Does this allow an adversary to generate too long anon_vma chains that wouldn't normally happen or some other nasties that would make backporting to older kernels really necessary? Because from my current understanding it would only make WIPEONFORK vmas rmap walks less efficient. Or is there any other functional issue? --=20 Michal Hocko SUSE Labs