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 X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 02F35C433DB for ; Wed, 24 Mar 2021 15:46:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C840061A09 for ; Wed, 24 Mar 2021 15:46:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236760AbhCXPpc (ORCPT ); Wed, 24 Mar 2021 11:45:32 -0400 Received: from mail-ot1-f41.google.com ([209.85.210.41]:45703 "EHLO mail-ot1-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236739AbhCXPpB (ORCPT ); Wed, 24 Mar 2021 11:45:01 -0400 Received: by mail-ot1-f41.google.com with SMTP id 91-20020a9d08640000b0290237d9c40382so2122426oty.12; Wed, 24 Mar 2021 08:45:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dfhJOg09ikxWSIDPpHsrjFdK9fLKr7xknDIbplXzRO0=; b=HjnhrbpheK5tMS9k29vE0lekUUqTTb1CAY2R9hBHQCNu72tkJh5pHWJQTePJdDc/dV dpy7aCGZjz11BFhcxfUQZXVOqKrItenOUw4tLlBCDlw6WD0oS6zvYes/C1g8uQFY9BiL yqd2QRuMWVKQcPa6zc4WKMxOPximXkYqO0aOS1lybWPyH7fe9m86/GChmBamysh4pssz f9ZIc4YjpVIJsbUxVpQdFFxbbFxy06BUdUa+51oGLbkMK1hX8YHuKoGAzotQjPSKqQ4N zz1xKSftI+SOHfNjkHt9run0q95TAjEV11sLwimD+i5ltYJFRi9LyYdV2RvQRNbgEvm0 afRw== X-Gm-Message-State: AOAM532vLCScw/xWKFyKnojOUFFOyehlgReBwuFfs4Wb5RsezeY9ga/y 3GSW6YsgcXPjQMJa/s/AuZ3B9nA9mhP+rHkAMTI= X-Google-Smtp-Source: ABdhPJznvfbua4AyfGFUKYyzKuFs1u1F8dwJMZKu9QkTc4HwM7IBTRdhTFzkGEBa5+QRALOhKDZb+xDSkXn3UCqq+lU= X-Received: by 2002:a05:6830:1e03:: with SMTP id s3mr3803460otr.321.1616600700966; Wed, 24 Mar 2021 08:45:00 -0700 (PDT) MIME-Version: 1.0 References: <3236337.DtqTXxM43S@kreacher> <4650320.31r3eYUQgx@kreacher> <933519a8-faaf-644c-4368-bc92cfab937f@oracle.com> In-Reply-To: <933519a8-faaf-644c-4368-bc92cfab937f@oracle.com> From: "Rafael J. Wysocki" Date: Wed, 24 Mar 2021 16:44:49 +0100 Message-ID: Subject: Re: [PATCH] ACPI: tables: x86: Reserve memory occupied by ACPI tables To: George Kennedy Cc: "Rafael J. Wysocki" , Mike Rapoport , "Rafael J. Wysocki" , ACPI Devel Maling List , Erik Kaneda , David Hildenbrand , Robert Moore , Rafael Wysocki , Len Brown , Linux Kernel Mailing List , Konrad Rzeszutek Wilk , Dan Carpenter , Dhaval Giani , Andrew Morton , Vlastimil Babka , Oscar Salvador , Wei Yang , Pankaj Gupta , Michal Hocko , x86 Maintainers Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Wed, Mar 24, 2021 at 4:42 PM George Kennedy wrote: > > > > On 3/24/2021 9:27 AM, Rafael J. Wysocki wrote: > > On Wed, Mar 24, 2021 at 9:24 AM Mike Rapoport wrote: > >> On Tue, Mar 23, 2021 at 08:26:52PM +0100, Rafael J. Wysocki wrote: > >>> From: Rafael J. Wysocki > >>> > >>> The following problem has been reported by George Kennedy: > >>> > >>> Since commit 7fef431be9c9 ("mm/page_alloc: place pages to tail > >>> in __free_pages_core()") the following use after free occurs > >>> intermittently when ACPI tables are accessed. > >>> > >>> BUG: KASAN: use-after-free in ibft_init+0x134/0xc49 > >>> Read of size 4 at addr ffff8880be453004 by task swapper/0/1 > >>> CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc1-7a7fd0d #1 > >>> Call Trace: > >>> dump_stack+0xf6/0x158 > >>> print_address_description.constprop.9+0x41/0x60 > >>> kasan_report.cold.14+0x7b/0xd4 > >>> __asan_report_load_n_noabort+0xf/0x20 > >>> ibft_init+0x134/0xc49 > >>> do_one_initcall+0xc4/0x3e0 > >>> kernel_init_freeable+0x5af/0x66b > >>> kernel_init+0x16/0x1d0 > >>> ret_from_fork+0x22/0x30 > >>> > >>> ACPI tables mapped via kmap() do not have their mapped pages > >>> reserved and the pages can be "stolen" by the buddy allocator. > >>> > >>> Apparently, on the affected system, the ACPI table in question is > >>> not located in "reserved" memory, like ACPI NVS or ACPI Data, that > >>> will not be used by the buddy allocator, so the memory occupied by > >>> that table has to be explicitly reserved to prevent the buddy > >>> allocator from using it. > >>> > >>> In order to address this problem, rearrange the initialization of the > >>> ACPI tables on x86 to locate the initial tables earlier and reserve > >>> the memory occupied by them. > >>> > >>> The other architectures using ACPI should not be affected by this > >>> change. > >>> > >>> Link: https://lore.kernel.org/linux-acpi/1614802160-29362-1-git-send-email-george.kennedy@oracle.com/ > >>> Reported-by: George Kennedy > >>> Signed-off-by: Rafael J. Wysocki > >> FWIW: > >> Reviewed-by: Mike Rapoport > > Thank you! > > > > George, can you please try this patch on the affected system? > > Rafael, > > 10 for 10 successful reboots with your patch. > > First, verified the failure is still there with latest 5.12.0-rc4. Thank you! I'll add a Tested-by from you to it, then.