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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E063C5AD49 for ; Thu, 29 May 2025 15:54:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 378046B0085; Thu, 29 May 2025 11:54:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B2856B008A; Thu, 29 May 2025 11:54:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B7AD6B0088; Thu, 29 May 2025 11:54:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E0DC86B0085 for ; Thu, 29 May 2025 11:54:41 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7CCAE1A0ABC for ; Thu, 29 May 2025 15:54:41 +0000 (UTC) X-FDA: 83496393162.20.483188C Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) by imf05.hostedemail.com (Postfix) with ESMTP id 93862100006 for ; Thu, 29 May 2025 15:54:36 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of pulehui@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=pulehui@huaweicloud.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748534079; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WLPDrIY3WiRkdIUpZ03ks7xYBuCxPxbfG/ufM35/3nI=; b=0s9cC6Lg+P33ICgFq8gDX9+FAy++YPwqNSSnYQTweR6Vu/xVRO8VROeKU+prDQGf2/Hv6R Lc6JghSp1VRgmqMki6aX7N3PTUBcjPS0Hga0/VdL/MIy9/f1OgSReqZbV3KeMsiqU0Yvx/ 76tiHpG/TtBYaaKvjPtKfFw6VQAEgVM= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of pulehui@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=pulehui@huaweicloud.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748534079; a=rsa-sha256; cv=none; b=DGKh5zwliejF5xlfyBPjtp6DtuBua+/UTsDDBZkGJBLjKQgvIu4iuSIMsTt6lrvmr3uMaz EOU36rUju73a3nMdeb5dDkg98o8vQXp/1TdMHBLN2dnLevGcjFgzljrswOJaSQu4F6XrkR ihLYkxc4aSmdeTzOuRUd3UADxmTT4IM= Received: from mail.maildlp.com (unknown [172.19.163.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4b7WCF1CvjzKHMmP for ; Thu, 29 May 2025 23:54:33 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.252]) by mail.maildlp.com (Postfix) with ESMTP id 8AC481A0A63 for ; Thu, 29 May 2025 23:54:31 +0800 (CST) Received: from ultra.huawei.com (unknown [10.90.53.71]) by APP3 (Coremail) with SMTP id _Ch0CgBX98EzgzhooMK5Ng--.57784S3; Thu, 29 May 2025 23:54:31 +0800 (CST) From: Pu Lehui To: mhiramat@kernel.org, oleg@redhat.com, peterz@infradead.org, akpm@linux-foundation.org, Liam.Howlett@oracle.com, lorenzo.stoakes@oracle.com, vbabka@suse.cz, jannh@google.com, pfalcato@suse.de Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, pulehui@huawei.com Subject: [PATCH v1 1/4] mm: Fix uprobe pte be overwritten when expanding vma Date: Thu, 29 May 2025 15:56:47 +0000 Message-Id: <20250529155650.4017699-2-pulehui@huaweicloud.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20250529155650.4017699-1-pulehui@huaweicloud.com> References: <20250529155650.4017699-1-pulehui@huaweicloud.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:_Ch0CgBX98EzgzhooMK5Ng--.57784S3 X-Coremail-Antispam: 1UD129KBjvJXoWxCw15WrWfZFy3Xr4DJF1xAFb_yoWrGr1rpF n3Jwn8Krs7JFsakryDZr1DWr93Kw1I9a1UCr1fJ34Y9r15Kr4a9FW3AF45CFy5JFZ2gF1S qr40q34fKay7ta7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPFb4IE77IF4wAFF20E14v26rWj6s0DM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28IrcIa0xkI8VA2jI8067AKxVWUGw A2048vs2IY020Ec7CjxVAFwI0_Gr0_Xr1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxS w2x7M28EF7xvwVC0I7IYx2IY67AKxVW7JVWDJwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxV W8Jr0_Cr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v2 6rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMc Ij6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_ Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFIxGxcIEc7CjxVA2Y2ka0xkIwI1lc7CjxVAaw2AFwI 0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG 67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q6r43MI IYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E 14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJV W8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxU2HGQ DUUUU X-CM-SenderInfo: psxovxtxl6x35dzhxuhorxvhhfrp/ X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 93862100006 X-Stat-Signature: q33nnmbutuyp7ytgci344be7a9pnu374 X-Rspam-User: X-HE-Tag: 1748534076-553503 X-HE-Meta: U2FsdGVkX18OGbzU+xA868E+f7l7yNv//Zou0ckSj4SFW68jAJZANWwc+MaxrFPaAHN306JHoS8WZlehBL6muUTQB4K8jJbF1vbVFKUpYBJqU0caX2m1agFNwXOdpNk/s0j8+M5D2jHHYt3pB9tF8YwH/J+hpnw69NCtWb3OJxJp0g7ROPVZga6vxmDH7kvSluxr6MlvGwFiThYduqnnChp+ecNALUJNvqgg3MjiURfDgcZOp32yxfiVEQYOmrsWAb9Ks4msQWPOcOiXZpBiEcacJZjdTST8PoBIRTpfwKRhSmPLzz2lrfOuYWgE+eFQo12W0AZtoWMHjnzSmaUcyE/XTwzApvQr1CAfbuztqmiJgYcdKUd6umms/rhOBYtpDmpU2msbkjSs9kzoXBgIcsUiyK6xdZM7v3faXph+bYLCleDVS7DwanEIAIJMeH1eVZ3fKUYoMLwcviEIzDQoC7h12cJUP9iQef6dP0vP8pziHhCMhD/YA7zh2DzB7Um14l9takD/d22cbRTaAAXdIgTgMja2w/wiTspjeyeADDUYlLJ3G9OFO6vSVh+PQYNtYKQTP8hVYuBPG1DSFCS06M53BpbaE8mXyaapH2UAHrPSgw/WrFhmLJEvAdC1ALWqyRS0RAdmEJ6Jn4/rrI/5RDyo12zW2PdP0/Z7INkGhCZhzpnJITUpc11NPQ0ZLfgiinreJO+hvEjcohR1TBs0THy0PcqqPFAaskPjw9v+KlTJSeYrPKh1WLqX3z4XwnFaBWI2rwgshlxwVBFrFa6T7mBNdFA3kHwtvPIbAmVDekrKlL+4/gCOAVJ8eDxlAcnzcC8mhP6DdDnlpl+0Dw6RzCfdv9HNAvWRl8pRz83eTrjo48MHR31aK0QlcI/zYQr22w9PtA6J6IwCCIZtAejl36LXZ+pbElejXUDf8VX8URYmvl7+rdcL9J3E9rm1e3hdzEjec6C1/BZGJI1vQ46 mklEOBPz uqxP301Vr+L10szr3kNK/yWfTeKp0Pdaj5ROzTFuI0yOT/4MXSknPJzfd+mpQlO0f0mDRbQqbJYOk6pG5xe1B4KHHPxTNTkWHyeD7ahjr3ueAifqZRf+oe+Uk+VSwg6HLkP9bT1hdfFtYD2nexgHU5SgNNdBycT/q9kBq6KHAJJM9VYWBexIlg2qn7Q/yhoWAvpJjbZ01Gr/Li+w= 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: List-Subscribe: List-Unsubscribe: From: Pu Lehui We encountered a BUG alert triggered by Syzkaller as follows: BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1 And we can reproduce it with the following steps: 1. register uprobe on file at zero offset 2. mmap the file at zero offset: addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0); 3. mremap part of vma1 to new vma2: addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE); 4. mremap back to orig addr1: mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1); In the step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2 with range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1 to vma2, then unmap the vma1 range [addr1, addr1 + 4096]. In tht step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the addr range [addr1, addr1 + 4096]. Since the addr range [addr1 + 4096, addr1 + 8192] still maps the file, it will take vma_merge_new_range to expand the range, and then do uprobe_mmap in vma_complete. Since the merged vma pgoff is also zero offset, it will install uprobe anon page to the merged vma. However, the upcomming move_page_tables step, which use set_pte_at to remap the vma2 uprobe pte to the merged vma, will overwrite the newly uprobe pte in the merged vma, and lead that pte to be orphan. Since the uprobe pte will be remapped to the merged vma, we can remove the unnecessary uprobe_mmap upon merged vma. This problem was first find in linux-6.6.y and also exists in the community syzkaller: https://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/ CC: stable@vger.kernel.org Fixes: 2b1444983508 ("uprobes, mm, x86: Add the ability to install and remove uprobes breakpoints") Suggested-by: Lorenzo Stoakes Signed-off-by: Pu Lehui --- mm/vma.c | 20 +++++++++++++++++--- mm/vma.h | 7 +++++++ 2 files changed, 24 insertions(+), 3 deletions(-) diff --git a/mm/vma.c b/mm/vma.c index 1c6595f282e5..b2d7c03d8aa4 100644 --- a/mm/vma.c +++ b/mm/vma.c @@ -169,6 +169,9 @@ static void init_multi_vma_prep(struct vma_prepare *vp, vp->file = vma->vm_file; if (vp->file) vp->mapping = vma->vm_file->f_mapping; + + if (vmg && vmg->skip_vma_uprobe) + vp->skip_vma_uprobe = true; } /* @@ -358,10 +361,13 @@ static void vma_complete(struct vma_prepare *vp, struct vma_iterator *vmi, if (vp->file) { i_mmap_unlock_write(vp->mapping); - uprobe_mmap(vp->vma); - if (vp->adj_next) - uprobe_mmap(vp->adj_next); + if (!vp->skip_vma_uprobe) { + uprobe_mmap(vp->vma); + + if (vp->adj_next) + uprobe_mmap(vp->adj_next); + } } if (vp->remove) { @@ -1823,6 +1829,14 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap, faulted_in_anon_vma = false; } + /* + * If the VMA we are copying might contain a uprobe PTE, ensure + * that we do not establish one upon merge. Otherwise, when mremap() + * moves page tables, it will orphan the newly created PTE. + */ + if (vma->vm_file) + vmg.skip_vma_uprobe = true; + new_vma = find_vma_prev(mm, addr, &vmg.prev); if (new_vma && new_vma->vm_start < addr + len) return NULL; /* should never get here */ diff --git a/mm/vma.h b/mm/vma.h index 9a8af9be29a8..0db066e7a45d 100644 --- a/mm/vma.h +++ b/mm/vma.h @@ -19,6 +19,8 @@ struct vma_prepare { struct vm_area_struct *insert; struct vm_area_struct *remove; struct vm_area_struct *remove2; + + bool skip_vma_uprobe :1; }; struct unlink_vma_file_batch { @@ -120,6 +122,11 @@ struct vma_merge_struct { */ bool give_up_on_oom :1; + /* + * If set, skip uprobe_mmap upon merged vma. + */ + bool skip_vma_uprobe :1; + /* Internal flags set during merge process: */ /* -- 2.34.1