linux-kernel - Re: [PATCH] ACPI: tables: x86: Reserve memory occupied by ACPI tables

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 24 Mar 2021 16:44:49 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     George Kennedy <george.kennedy@...cle.com>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Erik Kaneda <erik.kaneda@...el.com>,
        David Hildenbrand <david@...hat.com>,
        Robert Moore <robert.moore@...el.com>,
        Rafael Wysocki <rafael.j.wysocki@...el.com>,
        Len Brown <lenb@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Dhaval Giani <dhaval.giani@...cle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Oscar Salvador <osalvador@...e.de>,
        Wei Yang <richard.weiyang@...ux.alibaba.com>,
        Pankaj Gupta <pankaj.gupta.linux@...il.com>,
        Michal Hocko <mhocko@...e.com>,
        x86 Maintainers <x86@...nel.org>
Subject: Re: [PATCH] ACPI: tables: x86: Reserve memory occupied by ACPI tables

On Wed, Mar 24, 2021 at 4:42 PM George Kennedy
<george.kennedy@...cle.com> wrote:
>
>
>
> On 3/24/2021 9:27 AM, Rafael J. Wysocki wrote:
> > On Wed, Mar 24, 2021 at 9:24 AM Mike Rapoport <rppt@...ux.ibm.com> wrote:
> >> On Tue, Mar 23, 2021 at 08:26:52PM +0100, Rafael J. Wysocki wrote:
> >>> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >>>
> >>> 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 <george.kennedy@...cle.com>
> >>> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >> FWIW:
> >> Reviewed-by: Mike Rapoport <rppt@...ux.ibm.com>
> > 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.