From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com [113.46.200.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 51807363C59 for ; Fri, 21 Aug 2026 03:10:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.220 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787281852; cv=none; b=cOf9N5LeRznlFzxaIK1hVSZS97kzXAtQ2Pc71xBlsi+lC4NV+gjGQ6QdGO4usN2/TX3QwXg2P0KSLnF5V0fiMvTytFY5UbLDcWWhtqwD2E4jSzEymvmH9r199xN4c8gcCNH1iDMosGU6zuL811obGyJZ4ye5M11nE6dcAYuOJSM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787281852; c=relaxed/simple; bh=NItB3YMX0Ih5nOZcJ8nJdZJnG1VUqbBnn0/j2YRX9PQ=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=YkGWrYTYGpgSWyee2Un/D8eiqjwG/HfBOZLDiD5CX2Qp/saGwuEOuI8QwMP81xQG5io8C0HGwt6icL6qHjLR/Wzl2opnHU6KG2a2vBzEkBbI9dzrU6y2zpdPi20slR0s1WDL1e7xC+dRpzqh5O/FKvUU3qsy3m4j3xkL+eqqWFo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=g+fheIFq; arc=none smtp.client-ip=113.46.200.220 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="g+fheIFq" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=0eyQGcLk/I018xLXVBLLUtlOMnk+JLbGJei5TJgp0VU=; b=g+fheIFqBSycJ334Qz83fCGu2OqglfLRMYVHvaDkDgjgIq+bRk4gipe/Mm2/0rqEnEreeqftU fEjmcCQjoZCaONf1Dx8r5ddkMLwwTd19rLXe/NRiauE5ia1FglSST2PBpPEwaZtjJVPgy48m7iU n7hTlNkiafAb89oq/NhJCT0= Received: from mail.maildlp.com (unknown [172.19.162.223]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4hR4mX1fSSz12LFy; Fri, 21 Aug 2026 11:00:12 +0800 (CST) Received: from kwepemo200010.china.huawei.com (unknown [7.202.195.178]) by mail.maildlp.com (Postfix) with ESMTPS id 4FFC640575; Fri, 21 Aug 2026 11:10:32 +0800 (CST) Received: from huawei.com (10.44.142.85) by kwepemo200010.china.huawei.com (7.202.195.178) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Fri, 21 Aug 2026 11:10:31 +0800 From: Qi Xi To: Andrew Morton , Vlastimil Babka CC: Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , , , , , Subject: [PATCH v2 1/2] mm/page_isolation: fix UBSAN shift-out-of-bounds warning Date: Fri, 21 Aug 2026 10:55:00 +0800 Message-ID: <20260821025501.2752563-2-xiqi2@huawei.com> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20260821025501.2752563-1-xiqi2@huawei.com> References: <20260821025501.2752563-1-xiqi2@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To kwepemo200010.china.huawei.com (7.202.195.178) A contig-range allocation racing with buddy allocation on the adjacent pageblock can trigger: UBSAN: shift-out-of-bounds in mm/page_isolation.c:393:15 shift exponent -749042176 is negative Call trace: isolate_single_pageblock start_isolate_page_range alloc_contig_frozen_range_noprof alloc_contig_range_noprof isolate_single_pageblock() first calls set_migratetype_isolate() with zone->lock held, which marks the pageblock MIGRATE_ISOLATE and moves any free page straddling the boundary out of the way. Once the lock is dropped, it scans the MAX_ORDER_NR_PAGES-aligned window [start_pfn, boundary_pfn) locklessly, only to skip the free pages already handled above and to detect in-use pages straddling the boundary. Since this scan only reads page state to decide how far to skip and returns -EBUSY on a straddling in-use page, it does not take the lock. The window also covers the adjacent pageblock, whose free pages stay on the normal movable/CMA freelist and can be allocated concurrently. So after the scan observes PageBuddy(page), another CPU can allocate the page, leaving a stale value in page->private that makes "1 << order" shift out of range. Use buddy_order_unsafe() with READ_ONCE to read the order, and validate it is within MAX_PAGE_ORDER before shifting to prevent UBSAN warnings. Since pageblock_isolate_and_move_free_pages() already handles free pages straddling boundary_pfn under zone->lock, bail out with -EBUSY instead of VM_WARN_ON_ONCE() when a PageBuddy page appears to cross the boundary during the lockless scan. Fixes: b2c9e2fbba32 ("mm: make alloc_contig_range work at pageblock granularity") Cc: stable@vger.kernel.org Signed-off-by: Qi Xi --- mm/page_isolation.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/mm/page_isolation.c b/mm/page_isolation.c index 32ce8a7d9df3..f2b648a68531 100644 --- a/mm/page_isolation.c +++ b/mm/page_isolation.c @@ -387,13 +387,15 @@ static int isolate_single_pageblock(unsigned long boundary_pfn, } if (PageBuddy(page)) { - int order = buddy_order(page); + unsigned int order = buddy_order_unsafe(page); - /* pageblock_isolate_and_move_free_pages() handled this */ - VM_WARN_ON_ONCE(pfn + (1 << order) > boundary_pfn); - - pfn += 1UL << order; - continue; + /* buddy_order_unsafe() is racy. Validate the order before shifting. */ + if (order <= MAX_PAGE_ORDER && + pfn + (1UL << order) <= boundary_pfn) { + pfn += 1UL << order; + continue; + } + goto failed; } /* -- 2.33.0