linux-kernel - Re: [PATCH 1/1] ACPI: fix acpi table use after free

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <YESEymRQ2/F7xJGt@linux.ibm.com>
Date:   Sun, 7 Mar 2021 09:46:18 +0200
From:   Mike Rapoport <rppt@...ux.ibm.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     George Kennedy <george.kennedy@...cle.com>,
        David Hildenbrand <david@...hat.com>,
        Robert Moore <robert.moore@...el.com>,
        Erik Kaneda <erik.kaneda@...el.com>,
        Rafael Wysocki <rafael.j.wysocki@...el.com>,
        Len Brown <lenb@...nel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        "open list:ACPI COMPONENT ARCHITECTURE (ACPICA)" <devel@...ica.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>
Subject: Re: [PATCH 1/1] ACPI: fix acpi table use after free

Hello Rafael,

On Fri, Mar 05, 2021 at 02:30:07PM +0100, Rafael J. Wysocki wrote:
> On Fri, Mar 5, 2021 at 12:14 AM George Kennedy <george.kennedy@...cle.com> wrote:
>
> > The ibft table, for example, is mapped in via acpi_map() and kmap(). The
> > page for the ibft table is not reserved, so it can end up on the freelist.
> 
> You appear to be saying that it is not sufficient to kmap() a page in
> order to use it safely.  It is also necessary to reserve it upfront,
> for example with the help of memblock_reserve().  Is that correct?  If
> so, is there an alternative way to reserve a page frame?

Like David said in the other reply, if a BIOS does not mark the memory that
contains an ACPI table as used (e.g. reserved or ACPI data), we need to
make sure the kernel knows that such memory is in use and an early call to
memblock_reserve() is exactly what we need here.
George had this issue with iBFT, but in general this could be any table
that a buggy BIOS forgot to mark as ACPI data.
 
> > >> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > >> index d883176..97deea3 100644
> > >> --- a/arch/x86/kernel/setup.c
> > >> +++ b/arch/x86/kernel/setup.c
> > >> @@ -1046,6 +1046,7 @@ void __init setup_arch(char **cmdline_p)
> > >>          cleanup_highmap();
> > >>
> > >>          memblock_set_current_limit(ISA_END_ADDRESS);
> > >> +       acpi_boot_table_init();
> > > This cannot be moved before the acpi_table_upgrade() invocation AFAICS.
> > >
> > > Why exactly do you want to move it?
> >
> > Want to make sure there are slots for memblock_reserve() to be able to
> > reserve the page.
> 
> Well, that may not require reordering the initialization this way.

The memory that is used by the firmware should be reserved before memblock
allocations are allowed so that ACPI tables won't get trampled by some
random allocation.

On x86 this essentially means that the early reservations need to be
complete before the call to e820__memblock_setup().

We probably need more precise refactoring of ACPI init than simply moving
acpi_boot_table_init() earlier. 
 
> > >>          e820__memblock_setup();
> > >>

-- 
Sincerely yours,
Mike.