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 C9277C54FB3 for ; Mon, 26 May 2025 14:52:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 58DBC6B0096; Mon, 26 May 2025 10:52:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 565676B0098; Mon, 26 May 2025 10:52:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47A1A6B0099; Mon, 26 May 2025 10:52:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 21CD46B0096 for ; Mon, 26 May 2025 10:52:50 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D68E55A67B for ; Mon, 26 May 2025 14:52:49 +0000 (UTC) X-FDA: 83485350858.08.E11EA61 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) by imf13.hostedemail.com (Postfix) with ESMTP id 690022000B for ; Mon, 26 May 2025 14:52:44 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.hostedemail.com: domain of pulehui@huaweicloud.com designates 45.249.212.51 as permitted sender) smtp.mailfrom=pulehui@huaweicloud.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748271168; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pnOdNJQuH5nAURJkO8r2b6SRkRuF2v2WkfyOkvVOYxE=; b=c0PS7IEI3KYMvFkUQzy2ioLKGE2UJzosunYRG0EjlgCOV0kbngncPg5Syj4o6enMkTnutT k9PxFWQJk1TjbdJAC68vne3MtGPQ549u29BegJ6A+5mZuXfaXDtB1hjqq+vIL2ChobtFWK Cv/WbfdMZaoK+VzoZ8Dpnj9hbdQzGa4= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.hostedemail.com: domain of pulehui@huaweicloud.com designates 45.249.212.51 as permitted sender) smtp.mailfrom=pulehui@huaweicloud.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748271168; a=rsa-sha256; cv=none; b=YEzZ497Ae2Y+FYJJCv2fen6kbuLLY5mmcXxZVPQcTn8FV+nVxH3/o7khu8TM2m99f3BLDz fdy6Qfb49ZYBSRaG5warcdLbjG2Tu016+o77d+1e6lyVeYbu1Or+4etCFD/4eGf4pdw3RT Hak6GbsOLJ4p8x+kjU4exshZQgj+KlA= Received: from mail.maildlp.com (unknown [172.19.163.235]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4b5dyg4Gbhz4f3lCf for ; Mon, 26 May 2025 22:52:11 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.252]) by mail.maildlp.com (Postfix) with ESMTP id 5763E1A0A11 for ; Mon, 26 May 2025 22:52:38 +0800 (CST) Received: from [10.67.109.184] (unknown [10.67.109.184]) by APP3 (Coremail) with SMTP id _Ch0CgD3lsE0gDRoZo2CNQ--.12408S2; Mon, 26 May 2025 22:52:38 +0800 (CST) Message-ID: <4cbc1e43-ea46-44de-9e2b-1c62dcd2b6d5@huaweicloud.com> Date: Mon, 26 May 2025 22:52:36 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] mm/mmap: Fix uprobe anon page be overwritten when expanding vma during mremap Content-Language: en-US To: David Hildenbrand , lorenzo.stoakes@oracle.com, oleg@redhat.com Cc: mhiramat@kernel.org, peterz@infradead.org, Liam.Howlett@oracle.com, akpm@linux-foundation.org, vbabka@suse.cz, jannh@google.com, pfalcato@suse.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, pulehui@huawei.com References: <20250521092503.3116340-1-pulehui@huaweicloud.com> <62b5ccf5-f1cd-43c2-b0bc-f542f40c5bdf@redhat.com> <13c5fe73-9e11-4465-b401-fc96a22dc5d1@redhat.com> From: Pu Lehui In-Reply-To: <13c5fe73-9e11-4465-b401-fc96a22dc5d1@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:_Ch0CgD3lsE0gDRoZo2CNQ--.12408S2 X-Coremail-Antispam: 1UD129KBjvJXoWxur4Duw13KrWxJw47AF1UKFg_yoWrGr4xpa yxJas8KF1DJFWFyryqv34DtFyrtw4Ut3yUXrn8JFya93s8Kr1aqFW7ZFWjkFy3XrZ3tF4U tr4Ut343Xa47JaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b4IE77IF4wAFF20E14v26r4j6ryUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxkF7I0En4kS 14v26r1q6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I 8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUtVW8 ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x 0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_ Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IU1 7KsUUUUUU== X-CM-SenderInfo: psxovxtxl6x35dzhxuhorxvhhfrp/ X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 690022000B X-Stat-Signature: 7d6nxd3s9xfwzds3sb517i5uiyan5ku9 X-Rspam-User: X-HE-Tag: 1748271164-651068 X-HE-Meta: U2FsdGVkX1/u5zJ3dBX66zs2DQUVJhiwxkrigEUfPSFO6fowADHmKafy2jP5CyxVlLy6P4JCNNvUO7Qr3VqpTQlPiGt9sI6DdxpbM+nPM09NK2G/uOoMpH9616F4kqvw7+ukCKbfLJI+UroWnIT4ojwB6NTbfzsztIyrneNwBg7K2MzS3PwtyYXtRmSq98NRovSz0waCS2cT7TQH+CrtXpo6tUJxV8QEOCgUfPlLclzjFa9KYjfof3iJEOYS06B+o6mnchLd+Iiw7YBysetsL3+UWcBr0wnqFagVqKysiBWJkBsZo7bssTwhso/CFJ8SRYrLkK0uvNDU05S/fifl7vkDkUYmyHRL/ATkLKrKNkJi0okBYVLTrGXkIanehkPCOVaKNtUTw2+imcjawooZrW9v7utM8Rpi/w5ZYEN6oUzXlztNaA15jvI6V83F3cXlsiYj7Laz1Uj83mOETn7/+yC7IVd6fOnwx59uw7FBltC8/6x7jtj99tHOWc4DKGuxRpicq2c5476WH18APFdekfLNFJ517QQnURxrdz5yS/wSeTXkAhNGkZ2bWkofgZRbFbZyhyAJ4mN4nVmDI4gjaRfIr7a0eghMEEBHt3Oj9fxBKhRb8Rb810CQ11ZTsi/J1kee/gwYwpRWUvQNwb0i+MrREG3sZEnP8UFeN9CsjH9ateAKGUy6RbZ52WTC4vWcCkM2bCPyl+fCKXmOOyJy47HcKV/AsnqkewfoEjBlRkYtdjy/4LPmZIzcwelNH9QDd2Y2K9Tm9Glw61mF+YCQdVlEZLdSq38mJ76bT2e12nFZUATN+MDlf3Z4EuyicpYtYpBTlueyxfPOrbndV7l0WXiMJYtpd9BqcK2+1CR7fTMu4P0n+17YzhrfIkhvZFDPZ0kODb2wOVjk1nP43YbB2irrSywIEDelkE/FcyziDy15FtjxLnU/01ypNur9Cgj2YU2FzB5eYG/u7pjuAIF xZBfHOyQ DfhCks8AYcuX9KbZMQGTpMErHcBAqZ8+8rwiv59Ye19cDZD88nQa2r1vmDTGNxw51pi+5RgDG7EIeph1DGmdF1+HS4mQF0qbQl1lT0YFkrgOC/d/P5DYekXnjUGgPKK81Cu3luPYfUsHg/LTuphJVOn3HGmqn1jmlX76MZj1mUM7rVYh1GeqIRg2wsnrdAm5a/kODBvR7zpHwSdo= 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: On 2025/5/22 23:14, David Hildenbrand wrote: > On 22.05.25 16:37, Pu Lehui wrote: >> >> >> On 2025/5/21 18:25, David Hildenbrand wrote: >>> On 21.05.25 11:25, Pu Lehui wrote: >>>> 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); >>> >>> So, here we will install a uprobe. >>> >>>> 3. mremap part of vma1 to new vma2: >>>>      addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE); >>> >>> Okay, so we'll essentially move the uprobe as we mremap. >>> >>> >>>> 4. mremap back to orig addr1: >>>>      mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1); >>> >>> And here, we would expect to move the uprobe again. >>> >>>> >>>> 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. >>> >>> Oh, so we're installing the uprobe into the extended VMA before moving >>> the page tables. >> Yep! >>> >>> Gah. >>> >>>> 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. >>> >>> Right, when moving page tables we don't expect there to already be >>> something from the uprobe code. >>> >>>> >>>> Since the uprobe anon page will be remapped to the merged vma, we can >>>> remove the unnecessary uprobe_mmap at merged vma, that is, do not >>>> perform uprobe_mmap when there is no vma in the addr range to be >>>> expaned. >>> >>> Hmmm, I'll have to think about other corner cases .... >>> >> looking forward to it > > I think, the rule is that we must not install a uprobe for the range > that we will be actually moving the page tables for. > > So, for the range we're effectively moving (not the one we're extending). > > Because logically, the uprobe will be already handled by the existing > page tables that we're moving. > > For the range we're extending, we must call uprobe handling code ... > > > Alternatively, maybe we could call uprobe handling code after moving the > page tables. We'd probably find that the uprobe is already installed and > do nothing (so the theory :) ). ... if that would simplify anything. > Hi David, Lorenzo, Oleg, My apologies for the delay. Thanks for your reply. To make things simpler, perhaps we could try post-processing, that is: diff --git a/mm/mremap.c b/mm/mremap.c index 83e359754961..46a757fd26dc 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -240,6 +240,11 @@ static int move_ptes(struct pagetable_move_control *pmc, if (pte_none(ptep_get(old_pte))) continue; + /* skip move pte when expanded range has uprobe */ + if (unlikely(pte_present(*new_pte) && + vma_has_uprobes(pmc->new, new_addr, new_addr + PAGE_SIZE))) + continue; + pte = ptep_get_and_clear(mm, old_addr, old_pte); /* * If we are remapping a valid PTE, make sure What do you think? Thanks, Lehui