linux-kernel - Re: [PATCH 5.4] ACPICA: Always create namespace nodes using acpi_ns_create

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, 5 May 2022 17:34:47 +0200
From:   Vegard Nossum <vegard.nossum@...cle.com>
To:     "Jason A. Donenfeld" <Jason@...c4.com>, linux-acpi@...r.kernel.org,
        stable@...r.kernel.org, rafael@...nel.org,
        gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org
Cc:     Jan Kiszka <jan.kiszka@...mens.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Kees Cook <keescook@...omium.org>,
        Bob Moore <robert.moore@...el.com>,
        Erik Kaneda <erik.kaneda@...el.com>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [PATCH 5.4] ACPICA: Always create namespace nodes using
 acpi_ns_create_node()


On 5/5/22 17:01, Jason A. Donenfeld wrote:
> From: Vegard Nossum <vegard.nossum@...cle.com>
> 
> commit 25928deeb1e4e2cdae1dccff349320c6841eb5f8 upstream.
> 
> ACPICA commit 29da9a2a3f5b2c60420893e5c6309a0586d7a329
> 
> ACPI is allocating an object using kmalloc(), but then frees it
> using kmem_cache_free(<"Acpi-Namespace" kmem_cache>).
> 

[...]

> Link: https://lore.kernel.org/lkml/4dc93ff8-f86e-f4c9-ebeb-6d3153a78d03@oracle.com/
> Link: https://lore.kernel.org/r/a1461e21-c744-767d-6dfc-6641fd3e3ce2@siemens.com
> Link: https://github.com/acpica/acpica/commit/29da9a2a
> Fixes: f79c8e4136ea ("ACPICA: Namespace: simplify creation of the initial/default namespace")
> Reported-by: Jan Kiszka <jan.kiszka@...mens.com>
> Diagnosed-by: Vlastimil Babka <vbabka@...e.cz>
> Diagnosed-by: Kees Cook <keescook@...omium.org>
> Signed-off-by: Vegard Nossum <vegard.nossum@...cle.com>
> Signed-off-by: Bob Moore <robert.moore@...el.com>
> Signed-off-by: Erik Kaneda <erik.kaneda@...el.com>
> Cc: 5.10+ <stable@...r.kernel.org> # 5.10+
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> ---
> Greg/Rafael - tihs was marked as 5.10, but 5.4 crashes without it. So
> maybe it was mistagged? Will let you guys decide. -Jason

If I look up the Fixes: commit I get:

$ git name-rev f79c8e4136eac37255ead8875593ae33a2c16d20
f79c8e4136eac37255ead8875593ae33a2c16d20 tags/linus/v5.3-rc1~166^2~1^2~4

so it looks like the buggy commit actually went into v5.3.

I think maybe the bug was there since v5.3 but it was merely exposed by
some unrelated SLUB change that went in later, maybe that's where the
version number confusion came from, see
<https://lore.kernel.org/lkml/ce333dcb-2b2c-3e1f-2a7e-02a7819b1db4@suse.cz/>
as well. The commit I had bisected to it was:

$ git name-rev --refs='v5.*' 67a72420a326b45514deb3f212085fb2cd1595b5
67a72420a326b45514deb3f212085fb2cd1595b5 linus/v5.4-rc1~141^2~2^2~7

But as Vlastimil Babka pointed out, the bug is sensitive to slab merging.

Anyway, thanks for spotting that.


Vegard