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 92EE8C54F30 for ; Tue, 27 May 2025 13:21:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DC32D6B0095; Tue, 27 May 2025 09:21:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D73D06B0096; Tue, 27 May 2025 09:21:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C896D6B0098; Tue, 27 May 2025 09:21:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A5B806B0096 for ; Tue, 27 May 2025 09:21:44 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B80D7BDE71 for ; Tue, 27 May 2025 13:21:43 +0000 (UTC) X-FDA: 83488750086.13.255C83D Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) by imf14.hostedemail.com (Postfix) with ESMTP id D5626100004 for ; Tue, 27 May 2025 13:21:39 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; spf=pass (imf14.hostedemail.com: domain of pulehui@huaweicloud.com designates 45.249.212.51 as permitted sender) smtp.mailfrom=pulehui@huaweicloud.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748352102; a=rsa-sha256; cv=none; b=CYudqzlzBumomsy374jG+b2LYIctbLR7DhP2SxusyfU9AN/HQttfkaLHoIFV4ogMk3Pr0B beB9KJbz0Ifi/N4/w4Q7JbCm4MlYy2mwJJq8ujg3KTMD64E1qmioP9qR1ttCDmwob2n5ZD fvfVkb+4IwSfmX3DLQSYUclnMaOku2E= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; spf=pass (imf14.hostedemail.com: domain of pulehui@huaweicloud.com designates 45.249.212.51 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=1748352102; 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=z5Xf4wC/5NssuD852+heAdeS/oXmDI/QAMZG/iiV+RM=; b=cOzKjHfro6tVVQQhwaGVuXCEb6ABPUIvEDXJJOg1QoIQXqxvzz3SdRX9KqeGBztAhuZYvF kSJie1c6Cvo5OWJ2m1hpbiF9rQOpEc7Kf+gME+4/tmuxxSwPYmxoGtU3drdCaav13Uo5e6 cGKsVyNSYD2WtghGgwLVKbM6u2wdFJc= Received: from mail.maildlp.com (unknown [172.19.163.235]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4b6Cv70cb0z4f3kvp for ; Tue, 27 May 2025 21:21:07 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.252]) by mail.maildlp.com (Postfix) with ESMTP id D730F1A08F7 for ; Tue, 27 May 2025 21:21:33 +0800 (CST) Received: from ultra.huawei.com (unknown [10.90.53.71]) by APP3 (Coremail) with SMTP id _Ch0CgBX98FavDVoK9fhNQ--.12329S3; Tue, 27 May 2025 21:21:33 +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, pulehui@huawei.com Subject: [RFC PATCH v2 1/2] mm/mremap: Fix uprobe anon page be overwritten when expanding vma during mremap Date: Tue, 27 May 2025 13:23:50 +0000 Message-Id: <20250527132351.2050820-2-pulehui@huaweicloud.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20250527132351.2050820-1-pulehui@huaweicloud.com> References: <20250527132351.2050820-1-pulehui@huaweicloud.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:_Ch0CgBX98FavDVoK9fhNQ--.12329S3 X-Coremail-Antispam: 1UD129KBjvJXoWxCw15WrWfZFy3Xr4DJF1xAFb_yoWrAF18pF s2v3Z8KFs7JFsYkry7Zryqvry3KwnakFWUCry5X34Y9ryagrsIqFWfAF47Cry5GFZ29a4S qr48tryftay2qaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPFb4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28IrcIa0xkI8VA2jI8067AKxVWUGw A2048vs2IY020Ec7CjxVAFwI0_Gr0_Xr1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxS w2x7M28EF7xvwVC0I7IYx2IY67AKxVW7JVWDJwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxV W8Jr0_Cr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v2 6rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMc Ij6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_ Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFIxGxcIEc7CjxVA2Y2ka0xkIwI1lc7CjxVAaw2AFwI 0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG 67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q6r43MI IYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E 14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJV W8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxU2uyI UUUUU X-CM-SenderInfo: psxovxtxl6x35dzhxuhorxvhhfrp/ X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: D5626100004 X-Stat-Signature: kursabx6a7uybestn3w5mk1p9e8uqpcg X-Rspam-User: X-HE-Tag: 1748352099-602611 X-HE-Meta: U2FsdGVkX18dDL+nCnOAiLDR0g1j1suREix9le0gkb8Goy8MBtvmxXBV8oZrNiFd9C+Jaxsc2/h930y6yl4BBGBDkGcZmv+5IGuAa739aSFdLMEj+/UK4DwI54epDYaogiuMwg4GP29mg2OecQyY1EPulQSopufqFdLYjLVC6BfhXCaYVomwNdUOaa68YfzIkX/p/6siORijoFRrAvoRk7Eugk9Ozil5KJHr7cc6F7YfCoi+dc7fkWa1euep7f1SMH3+PYQYTqGifd1WzilLDAaaDP9pAlDTcy9t4uQJ0jMsDmbk/7MSkOAzha2HjJxU4O8DeCdSyF99GhVE+QQcYQJ42pwUa8oJeDBbeeeLzBNl1zfnkdjL/NQw9/63WPt9yGf0e4e74Lrfz/rKDX9dldbDWj0rwwVjjnXSCXUwcvmAsqGGshByLtsFyMIuuctr4YUfkYw6wtBOVrawPYiZKqnn680Bt74J4fUImc6qx7HUmGTHv0R7AKkMSaN8shbPeRirWFja22rJVEMXV7YO8DuvtwS/kcnpD+FGLTHmZaIyEkpDHbhOKlXMnSn8geFHndo/GCZzgvGhTaQgQqy/neIyg8VVJdACJ50okSs4Yv4FaCDkwavIGPatwm1xuwH6HySYceeaKAytej1m/8gsfuo81Ip9NJ3AT4essJBvESGUhEQLwPTv70mu9UZyd1xlHkTJP542EUaAwrvR4a/ZquzgNbS2I/A//sZwwQjcpQ5nzNycco292KwejkLL4RZjRRlEmFKTRdFKpR1NWfTwzdwjKFY7cIa2t4FJOnpU3jtDV5ZtLm5xJSCjWrwhY+rYr2IQW0yy9oU64FH+l1AAhoeTN/VYSLYb4kt9Wo4EeJw= 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 merge these two addr ranges, 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 anon page to the merged vma, will over map the old uprobe anon page in the merged vma, and lead the old uprobe anon page to be orphan. Since the uprobe anon page will be remapped to the merged vma, we can remove the unnecessary uprobe_mmap on merged vma, that is, do not perform uprobe_mmap on expanded 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/ The complete Syzkaller C reproduction program is as follows: #define _GNU_SOURCE #include #include #include #include #include int main(int argc, char *argv[]) { int fd = open(FNAME, O_RDWR|O_CREAT, 0600); struct perf_event_attr attr = { .type = 9, .uprobe_path = (long) FNAME, .probe_offset = 0x0, }; void *addr1, *addr2; write(fd, "x", 1); mmap(NULL, 4096, PROT_EXEC, MAP_PRIVATE, fd, 0); syscall(__NR_perf_event_open, &attr, 0, 0, -1, 0); addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0); addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE); mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1); return 0; } Fixes: 78a320542e6c ("uprobes: Change valid_vma() to demand VM_MAYEXEC rather than VM_EXEC") Signed-off-by: Pu Lehui --- mm/vma.c | 7 ++++++- mm/vma.h | 7 +++++++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/mm/vma.c b/mm/vma.c index 1c6595f282e5..6445f515c7f2 100644 --- a/mm/vma.c +++ b/mm/vma.c @@ -358,7 +358,8 @@ 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->skip_vma_uprobe) + uprobe_mmap(vp->vma); if (vp->adj_next) uprobe_mmap(vp->adj_next); @@ -737,6 +738,7 @@ static int commit_merge(struct vma_merge_struct *vmg) if (vma_iter_prealloc(vmg->vmi, vma)) return -ENOMEM; + vp.skip_vma_uprobe = vmg->skip_vma_uprobe; vma_prepare(&vp); /* * THP pages may need to do additional splits if we increase @@ -1151,6 +1153,9 @@ int vma_expand(struct vma_merge_struct *vmg) if (remove_next) vmg->__remove_next = true; + /* skip uprobe_mmap on expanded vma */ + vmg->skip_vma_uprobe = true; + if (commit_merge(vmg)) goto nomem; diff --git a/mm/vma.h b/mm/vma.h index 9a8af9be29a8..56cc0364d239 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; + /* Whether to skip uprobe_mmap on vma */ + bool skip_vma_uprobe; }; struct unlink_vma_file_batch { @@ -120,6 +122,11 @@ struct vma_merge_struct { */ bool give_up_on_oom :1; + /* + * Whether to skip uprobe_mmap on merged vma. + */ + bool skip_vma_uprobe :1; + /* Internal flags set during merge process: */ /* -- 2.34.1