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 53935C54E90 for ; Thu, 22 May 2025 14:37:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F65D6B007B; Thu, 22 May 2025 10:37:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9CF5B6B0082; Thu, 22 May 2025 10:37:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90CC86B0083; Thu, 22 May 2025 10:37:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 740296B007B for ; Thu, 22 May 2025 10:37:36 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C9EBF1D3F06 for ; Thu, 22 May 2025 14:37:35 +0000 (UTC) X-FDA: 83470797270.21.C23F058 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) by imf29.hostedemail.com (Postfix) with ESMTP id E5154120011 for ; Thu, 22 May 2025 14:37:28 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf29.hostedemail.com: domain of pulehui@huaweicloud.com designates 45.249.212.56 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=1747924654; 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=1FnusG++wwhW6wXF4kM8obDOpHVcmgRDhUZo+OFYPV8=; b=th/w94sDxe2rJGx/xaPUZB0mi/786i+nM3+zOE6Wlx4YPbGe5pooDXwOqo8cO9JdLfi1xa dRSJLwYC6VnS8ey35YkgsXDAUzlc72ETVsp9hun9AVLCPD/eRHwO+6wCUoScvSCdeUNj8o ZTWIG1dmsCfQw4m+FgrQpJ+Si6LrSHo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747924654; a=rsa-sha256; cv=none; b=YtZAq/4vFkFaG+SBuxvIhKF7gFJoC4c0WAA4psIRq4HBTAMjjqnFe2aneoQiHVWDACaJzs 2zfjoZzQQCMQ/87xhMPQ5KVbIG37mszqIOCBIdgAGqTXk6pyFKQC9NuRsU634uR3Tnlgq9 ywl/XKOS5FKFGnhXHbCKxDNJQynJG5g= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf29.hostedemail.com: domain of pulehui@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=pulehui@huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.216]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4b39qT3TGPzKHLvj for ; Thu, 22 May 2025 22:37:25 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 030C61A18BA for ; Thu, 22 May 2025 22:37:24 +0800 (CST) Received: from [10.67.109.184] (unknown [10.67.109.184]) by APP4 (Coremail) with SMTP id gCh0CgAniFyiNi9osPK7NA--.57898S2; Thu, 22 May 2025 22:37:23 +0800 (CST) Message-ID: Date: Thu, 22 May 2025 22:37:22 +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 To: David Hildenbrand , 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 References: <20250521092503.3116340-1-pulehui@huaweicloud.com> <62b5ccf5-f1cd-43c2-b0bc-f542f40c5bdf@redhat.com> Content-Language: en-US From: Pu Lehui In-Reply-To: <62b5ccf5-f1cd-43c2-b0bc-f542f40c5bdf@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:gCh0CgAniFyiNi9osPK7NA--.57898S2 X-Coremail-Antispam: 1UD129KBjvJXoW7CrWrZF1rGr1fCw1xAF48Crg_yoW8tryxpa yIqas8KF97JFZ5Ary3A34DXry8twsYy345Ar1fXFya934rWr1aqFW7AFW2kFyfGFZ7tF4r tr4Fqry3tF9rJaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 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: rspam06 X-Rspamd-Queue-Id: E5154120011 X-Stat-Signature: 8tws3nub5z548d9ta7tindtd7zkunwrc X-Rspam-User: X-HE-Tag: 1747924648-244070 X-HE-Meta: U2FsdGVkX18Y1utYPMQVUyI52OojhTSAHhKFr5hAkxGosNoTd8HPsDtty+g+fFcQwUSJYc6KnqIs7uajzdD29BALWYzF+wBFaWq3wQ7pOlDZ3bI8+JUyq1qVKs21jmD6MZFcXW0R7svR6HYVyjJuFmq+IEXG7oS9eJv8J3iDgWCMzQjzEFuRxWbBmFiRX8Q47eNlQZOHfsqxi8s3ms5kcDuG6NKGezQjrNq6lLWKRxrVRcHlgHDL0F09e2WhDKI7W59Jcokp5AcUBxar8VDz31YKdAzpFtzmRs7/OXwLKBKI9VHwq8nqbT6b+HLwIKPdWEy0dxCs2BQqULYheT9DaeTXuzKTq723RshQh13X7tre2djc5sNkyDLmvIh7SWZTxNsjxy19OavRi5yiWkzzUkh9WLsoqfpIe2XyvpyzrU7kLDvP2Xtzpp7KQwOZ6apc00Atmwnobq3+vqi5XH2Q+yGXB5NjyQA3qRtNoWDZYxXNlucIBU3oBvziW9Q7yeO7TzkiRmD7b7moxsKWQoGFyGGD6SIDbYALjCjoYzw6WgfziboKldZzRg1vPVkkEq+SCQVXGzQeKKVMHSd75WEtL2lGQC/Q4+/UmnluEmRMFMcjCFIOH8/RQHHaKgJwSRjnJYAMjrrq8l7mc+q4ZCPucFMx0RiA7e/r+woWsNP7rWcysINuPUvFuHYWMfMQOOaO7cWd9Ng5xov/SBqgOQl94nfpRfGjKEFImRXsFdqeKgbRmM5/6gTbJ7W5ZSzQ5PHs/ibXUQZ+WN1ZYp1wXukme/9Wxt54y1VpZ0FHSOEz+q/6mipYtv+nEjmizz6517m53DxJmis77PYehNY8mPI1NQaKuHkzB6t6j5+gg1xl8ZE= 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/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