From nobody Mon Sep 28 19:23:43 2026 Received: from canpmsgout12.his.huawei.com (canpmsgout12.his.huawei.com [113.46.200.227]) (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 05E33448B9E for ; Tue, 18 Aug 2026 11:44:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.227 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787053476; cv=none; b=h2AZeY3YdqvxBJVYxAAcjKtJGpn32NHeBUhQ0x6cwt7bQned6Krq1EnEuxHmHgjHoNjxjCog+/yOFL4GofKJm0Ys3xncdBooWxgiqCpjo2CFG5Ujw2HYnyUCrlr4pHTbIyMc/G5XmSwnBIaZ0gFevAWlve0cYxuRASRUW3xxO2s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787053476; c=relaxed/simple; bh=eIe9mDgHtKDcrdl2Cju+C7zIhfXKSIi6c1WQHv10C5I=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=rgjK95doWzoMjJecnTKn+iMPEPNV7nq4YeiTqkV7mCLexwLhDr7WKP0zAmzEhei6l3JjuWUkU6Yn/652KhBC02/gL+59zZ1EO7LPEiBY0xzouB3zf1/lojP2TZ5cMFya6ciiECYBb430ZwDiKwwMXJGB1QzWGC7TdvoEYM8thiw= 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=b/+OOCV0; arc=none smtp.client-ip=113.46.200.227 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="b/+OOCV0" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=yXfHL44eCUMFCHve4lXyhhgcYfqAVccG0nG6arA10Ng=; b=b/+OOCV0NyCVdVuVlkR3i/mf2U+JUfM7eohksm2/7DExBKsnjYUWUl1umIf+rpr2meV7qlZ4H oroOF4MoEC+s69bNQy1gZ0efeIrrHPTp1au3gLPpw2qs8qi2cdtm6no10+Urp0XgitAUr/Pk4uQ GARKNWhYd9hRojcwdACHzgE= Received: from mail.maildlp.com (unknown [172.19.163.15]) by canpmsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4hPSJr1SkDznTbN; Tue, 18 Aug 2026 19:34:04 +0800 (CST) Received: from kwepemo200010.china.huawei.com (unknown [7.202.195.178]) by mail.maildlp.com (Postfix) with ESMTPS id 3278040578; Tue, 18 Aug 2026 19:44:23 +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; Tue, 18 Aug 2026 19:44:22 +0800 From: Qi Xi To: Andrew Morton , Vlastimil Babka CC: Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , , , , , Subject: [PATCH] mm/page_isolation: fix UBSAN shift-out-of-bounds warning Date: Tue, 18 Aug 2026 19:28:55 +0800 Message-ID: <20260818112855.3831692-1-xiqi2@huawei.com> X-Mailer: git-send-email 2.33.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To kwepemo200010.china.huawei.com (7.202.195.178) Content-Type: text/plain; charset="utf-8" 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() to read the order exactly once (READ_ONCE), and guard the shift with an order <=3D MAX_PAGE_ORDER check so it is never performed with a bogus value. Fixes: b2c9e2fbba32 ("mm: make alloc_contig_range work at pageblock granula= rity") Signed-off-by: Qi Xi Reviewed-by: Zi Yan --- mm/page_isolation.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/mm/page_isolation.c b/mm/page_isolation.c index 32ce8a7d9df3..8aa096f1754d 100644 --- a/mm/page_isolation.c +++ b/mm/page_isolation.c @@ -387,13 +387,16 @@ static int isolate_single_pageblock(unsigned long bou= ndary_pfn, } =20 if (PageBuddy(page)) { - int order =3D buddy_order(page); + unsigned int order; =20 - /* pageblock_isolate_and_move_free_pages() handled this */ - VM_WARN_ON_ONCE(pfn + (1 << order) > boundary_pfn); + order =3D buddy_order_unsafe(page); + if (likely(order <=3D MAX_PAGE_ORDER)) { + /* pageblock_isolate_and_move_free_pages() handled this */ + VM_WARN_ON_ONCE(pfn + (1 << order) > boundary_pfn); =20 - pfn +=3D 1UL << order; - continue; + pfn +=3D 1UL << order; + continue; + } } =20 /* --=20 2.33.0