linux-kernel - Re: slub freelist issue / BUG: unable to handle page fault for address: 000000003ffe0018

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]

Date:   Thu, 11 Jun 2020 12:54:56 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     "Kaneda, Erik" <erik.kaneda@...el.com>,
        Vegard Nossum <vegard.nossum@...cle.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        "Moore, Robert" <robert.moore@...el.com>
Cc:     Kees Cook <keescook@...omium.org>,
        "Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
        Christoph Lameter <cl@...ux.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Marco Elver <elver@...gle.com>,
        Waiman Long <longman@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux MM <linux-mm@...ck.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Len Brown <lenb@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: slub freelist issue / BUG: unable to handle page fault for
 address: 000000003ffe0018

On 6/11/20 3:40 AM, Kaneda, Erik wrote:
> We'll take this patch for ACPICA and it will be in the next release.
> 
> Rafael, do you want to take this as a part of the next rc? Or should we wait for the next merge window?

IMHO this should rather be fixed in 5.8 with CC stable, not next merge window.

> Thanks,
> Erik
>> 
>> diff --git a/drivers/acpi/acpica/nsaccess.c b/drivers/acpi/acpica/nsaccess.c
>> index 2566e2d4c7803..b76bbab917941 100644
>> --- a/drivers/acpi/acpica/nsaccess.c
>> +++ b/drivers/acpi/acpica/nsaccess.c
>> @@ -98,14 +98,12 @@ acpi_status acpi_ns_root_initialize(void)
>>                   * predefined names are at the root level. It is much easier to
>>                   * just create and link the new node(s) here.
>>                   */
>> -               new_node =
>> -                   ACPI_ALLOCATE_ZEROED(sizeof(struct
>> acpi_namespace_node));
>> +               new_node = acpi_ns_create_node(*ACPI_CAST_PTR (u32,
>> init_val->name));
>>                  if (!new_node) {
>>                          status = AE_NO_MEMORY;
>>                          goto unlock_and_exit;
>>                  }
>> 
>> -               ACPI_COPY_NAMESEG(new_node->name.ascii, init_val->name);
>>                  new_node->descriptor_type = ACPI_DESC_TYPE_NAMED;
>>                  new_node->type = init_val->type;
>> 
>> 
>> Vegard
>