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 E547FC433EF for ; Thu, 16 Jun 2022 16:19:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7EF356B0098; Thu, 16 Jun 2022 12:19:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 777966B0099; Thu, 16 Jun 2022 12:19:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 618DA6B009A; Thu, 16 Jun 2022 12:19:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4F0656B0098 for ; Thu, 16 Jun 2022 12:19:35 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1B640206CD for ; Thu, 16 Jun 2022 16:19:35 +0000 (UTC) X-FDA: 79584609510.07.0F74811 Received: from out30-42.freemail.mail.aliyun.com (out30-42.freemail.mail.aliyun.com [115.124.30.42]) by imf18.hostedemail.com (Postfix) with ESMTP id 2A9761C0087 for ; Thu, 16 Jun 2022 16:19:33 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R981e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046049;MF=xianting.tian@linux.alibaba.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_---0VGaoYUb_1655396370; Received: from localhost(mailfrom:xianting.tian@linux.alibaba.com fp:SMTPD_---0VGaoYUb_1655396370) by smtp.aliyun-inc.com; Fri, 17 Jun 2022 00:19:30 +0800 From: Xianting Tian To: akpm@linux-foundation.org, ziy@nvidia.com, gregkh@linuxfoundation.org, stable@vger.kernel.org, guoren@kernel.org Cc: huanyi.xj@alibaba-inc.com, guohanjun@huawei.com, zjb194813@alibaba-inc.com, tianhu.hh@alibaba-inc.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Xianting Tian Subject: [PATCH 4.9] mm: page_alloc: validate buddy page before using Date: Fri, 17 Jun 2022 00:19:28 +0800 Message-Id: <20220616161928.3565294-1-xianting.tian@linux.alibaba.com> X-Mailer: git-send-email 2.17.1 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655396374; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=SF4R3KgDCTd6hsXxnQcoKVQtQFiigx2kvPGScaqqh/o=; b=7BC9FjSfp/bmTgZhpjtkoiOGDjw6y8QokIDUOoUkkeeRd8ru6hPt3Nn0xLJU5KVtALy0V0 1hf4DiYgIh5+D1ZW/0lQJE60V7zTuYSxxUBxbPIWd5YQaz+HbxrV+6xaBe+ftloduYtq8J A/rCVqKmjdGOzDIlUjjJ1redagLtdvk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655396374; a=rsa-sha256; cv=none; b=cuv/S/uqItWkbvJvQtuYCJV5U6qjBHFBRLhgGHIp7/ZgFig/KTcHZKmBkKTod3nSE5/Hi2 /AQyADbCwWjfo4/nSVu94t4om88tIPzBwf03dkT5pLpJ1T0pXOFSxi+Q4TTST7KTMifxf6 6op85+OP7PIfg7AUqlTu0nVmBB2kQUQ= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf18.hostedemail.com: domain of xianting.tian@linux.alibaba.com designates 115.124.30.42 as permitted sender) smtp.mailfrom=xianting.tian@linux.alibaba.com Authentication-Results: imf18.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf18.hostedemail.com: domain of xianting.tian@linux.alibaba.com designates 115.124.30.42 as permitted sender) smtp.mailfrom=xianting.tian@linux.alibaba.com X-Rspamd-Server: rspam12 X-Rspam-User: X-Stat-Signature: xnqt9h6hqwqfd8ey7e85doocfkssexfa X-Rspamd-Queue-Id: 2A9761C0087 X-HE-Tag: 1655396373-629950 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: Commit 787af64d05cd ("mm: page_alloc: validate buddy before check its migratetype.") fixes a bug in 1dd214b8f21c and there is a similar bug in d9dddbf55667 that can be fixed in a similar way too. In addition, for RISC-V arch the first 2MB RAM could be reserved for opensbi, so it would have pfn_base=512 and mem_map began with 512th PFN when CONFIG_FLATMEM=y. But __find_buddy_pfn algorithm thinks the start pfn 0, it could get 0 pfn or less than the pfn_base value. We need page_is_buddy() to verify the buddy to prevent accessing an invalid buddy. Fixes: d9dddbf55667 ("mm/page_alloc: prevent merging between isolated and other pageblocks") Cc: stable@vger.kernel.org Reported-by: zjb194813@alibaba-inc.com Reported-by: tianhu.hh@alibaba-inc.com Signed-off-by: Xianting Tian --- mm/page_alloc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index a6e682569e5b..1c423faa4b62 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -864,6 +864,9 @@ static inline void __free_one_page(struct page *page, buddy_idx = __find_buddy_index(page_idx, order); buddy = page + (buddy_idx - page_idx); + + if (!page_is_buddy(page, buddy, order)) + goto done_merging; buddy_mt = get_pageblock_migratetype(buddy); if (migratetype != buddy_mt -- 2.17.1