From patchwork Fri Apr 17 17:25:56 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Geffon X-Patchwork-Id: 11495809 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 2EF44912 for ; Fri, 17 Apr 2020 17:26:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F02282220A for ; Fri, 17 Apr 2020 17:26:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="m4bHE2uu" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F02282220A 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 241A08E003C; Fri, 17 Apr 2020 13:26:43 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 1F2578E0023; Fri, 17 Apr 2020 13:26:43 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 106D28E003C; Fri, 17 Apr 2020 13:26:43 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0203.hostedemail.com [216.40.44.203]) by kanga.kvack.org (Postfix) with ESMTP id EB3568E0023 for ; Fri, 17 Apr 2020 13:26:42 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A3E8E52CC for ; Fri, 17 Apr 2020 17:26:42 +0000 (UTC) X-FDA: 76718026644.30.fish55_3a89a8d4b3130 X-Spam-Summary: 2,0,0,f7b3e6cbd6b722ad,d41d8cd98f00b204,30eazxgckcaidighhqpiqqing.eqonkpwz-oomxcem.qti@flex--bgeffon.bounces.google.com,,RULES_HIT:41:152:355:379:541:800:960:967:973:988:989:1260:1277:1313:1314:1345:1437:1516:1518:1535:1542:1593:1594:1711:1730:1747:1777:1792:2393:2525:2559:2563:2682:2685:2693:2859:2890:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3152:3354:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4042:4250:4321:5007:6261:6653:6742:9025:9036:9969:10004:10400:10450:10455:11026:11473:11658:11914:12043:12296:12297:12438:12555:12679:12895:13161:13221:13229:13845:14181:14394:14659:14721:19904:19999:21080:21220:21365:21444:21450:21451:21627:30001:30025:30034:30054,0,RBL:209.85.214.201:@flex--bgeffon.bounces.google.com:.lbl8.mailshell.net-62.18.0.100 66.100.201.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:24, LUA_SUMM X-HE-Tag: fish55_3a89a8d4b3130 X-Filterd-Recvd-Size: 5371 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Fri, 17 Apr 2020 17:26:42 +0000 (UTC) Received: by mail-pl1-f201.google.com with SMTP id d4so2305889plr.18 for ; Fri, 17 Apr 2020 10:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=ILn9zjMFZixAua0cC92upDzTyUw6GVgLI4zpVX2kQYA=; b=m4bHE2uu45HdfP0Wgg1WKeRftDLvdgoru1dUCnwI5N5ZcXIEqAw44ycGeigdhBGqgs 4gLATlk+W9zI2KZK1Lt/toGa/OCNvjBCx2ZTGALAgAXL+RhHcCPn8vR7s5mVd+9vGY69 CQ+pEPqimKZwRh8X8sBLe004QRZ4TNCTWpD6qV4Yq9QjjGHJ7rGYCHre7qM0KjOdNOeR N5b1Kq84Oa3zmlOGYY5p6Y8ClibEmKG2OJ1oFR3EtapNtR+nxZKKo9mLtDkcBFqMMFlC bBNlZwjQ6WwPXp9WTZfdsbV3Y/mil/EBs+SJQkKKWL/1l3XZfMlDpSLCvShvXrO/e1xJ eNQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=ILn9zjMFZixAua0cC92upDzTyUw6GVgLI4zpVX2kQYA=; b=OC6Lsd8QL9XOo3qt2HRvz3KF9/CBeSXw2BjzdPLQhdx9zmDIGUCHQvIwZTg34GOZxs TIGxoDhJE3bM2cVTt3XnV/8ktTZ1Qe+aS1nE6I0uKOwFJWp0bDUNh5EwBfiwB8OpMPmc EOrOwTaGnpxgd8YSMWolzrnWtJEGV6iRAPZcXJu6CcnEB1obwztUNEwN6ZxO2x143X+7 WErk2YyJDOjMVKbcM/SaclqmuWshL9XCNuFNs8SSsxiBtEdxFy+nqAQXOusbWFkouqqp nMLDD63O+L2qaqKlaRpZqgsybt/9B1cfEBEFFv9yR5ax+ZHk/elsuRWIHkS6qbdkkPcz JV3g== X-Gm-Message-State: AGi0PuZNrGd8oxQx1EQP5/M0e2OZySeD+ocoUTG39qvdoQVYkPUpN01O nSTBdGmqx6hUd7q0KVd4DLDGC2FguSD1 X-Google-Smtp-Source: APiQypIAfGVzmJZtnCGtNP6az31imBNTuf/QQ7pvHVtqHvvNRVRWycJ+wYPmL/y8uQCLRUrkdLYKhaN81O0s X-Received: by 2002:a17:90b:3443:: with SMTP id lj3mr5713388pjb.38.1587144401004; Fri, 17 Apr 2020 10:26:41 -0700 (PDT) Date: Fri, 17 Apr 2020 10:25:56 -0700 Message-Id: <20200417172556.217480-1-bgeffon@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.26.1.301.g55bc3eb7cb9-goog Subject: [PATCH] mm: Fix MREMAP_DONTUNMAP accounting on VMA merge From: Brian Geffon To: Linus Torvalds Cc: Andrew Morton , Andy Lutomirski , Sonny Rao , Jesse Barnes , Dmitry Vyukov , Minchan Kim , "Kirill A . Shutemov" , Vlastimil Babka , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-api@vger.kernel.org, Brian Geffon , syzbot 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: When remapping a mapping where a portion of a VMA is remapped into another portion of the VMA it can cause the VMA to become split. During the copy_vma operation the VMA can actually be remerged if it's an anonymous VMA whose pages have not yet been faulted. This isn't normally a problem because at the end of the remap the original portion is unmapped causing it to become split again. However, MREMAP_DONTUNMAP leaves that original portion in place which means that the VMA which was split and then remerged is not actually split at the end of the mremap. This patch fixes a bug where we don't detect that the VMAs got remerged and we end up putting back VM_ACCOUNT on the next mapping which is completely unreleated. When that next mapping is unmapped it results in incorrectly unaccounting for the memory which was never accounted, and eventually we will underflow on the memory comittment. There is also another issue which is similar, we're currently accouting for the number of pages in the new_vma but that's wrong. We need to account for the length of the remap operation as that's all that is being added. If there was a mapping already at that location its comittment would have been adjusted as part of the munmap at the start of the mremap. A really simple repro can be seen in: https://gist.github.com/bgaff/e101ce99da7d9a8c60acc641d07f312c Fixes: e346b3813067 ("mm/mremap: add MREMAP_DONTUNMAP to mremap()") Reported-by: syzbot Signed-off-by: Brian Geffon --- mm/mremap.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/mm/mremap.c b/mm/mremap.c index a7e282ead438..c881abeba0bf 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -413,9 +413,20 @@ static unsigned long move_vma(struct vm_area_struct *vma, /* Always put back VM_ACCOUNT since we won't unmap */ vma->vm_flags |= VM_ACCOUNT; - vm_acct_memory(vma_pages(new_vma)); + vm_acct_memory(new_len >> PAGE_SHIFT); } + /* + * VMAs can actually be merged back together in copy_vma + * calling merge_vma. This can happen with anonymous vmas + * which have not yet been faulted, so if we were to consider + * this VMA split we'll end up adding VM_ACCOUNT on the + * next VMA, which is completely unrelated if this VMA + * was re-merged. + */ + if (split && new_vma == vma) + split = 0; + /* We always clear VM_LOCKED[ONFAULT] on the old vma */ vma->vm_flags &= VM_LOCKED_CLEAR_MASK;