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: <dc974549-6ea4-899d-7f3a-b2fcfafe1528@arm.com>
Date:   Mon, 14 Oct 2019 17:15:05 +0100
From:   James Morse <james.morse@....com>
To:     John Garry <john.garry@...wei.com>
Cc:     Borislav Petkov <bp@...en8.de>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        tony.luck@...el.com, Robert Richter <rrichter@...vell.com>,
        linux-edac@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: edac KASAN warning in experimental arm64 allmodconfig boot

Hi John,

On 14/10/2019 16:18, John Garry wrote:
> I'm experimenting by trying to boot an allmodconfig arm64 kernel, as mentioned here:

Crumbs!


> One thing that I noticed - it's hard to miss actually - is the amount of complaining from
> KASAN about the EDAC/ghes code. Maybe this is something I should not care about/red
> herring, or maybe something genuine. Let me know what you think.

Hmmm, I thought I tested this recently...

> Log snippet (I cut off after the first KASAN warning):
> 
> [   70.471011][    T1] random: get_random_u32 called from new_slab+0x360/0x698 with
> crng_init=0

> [   70.478671][    T1] [Firmware Bug]: APEI: Invalid bit width + offset in GAR
> [0x94110034/64/0/3/0]

(this one's for you right?)

> [   70.700412][    T1] ------------[ cut here ]------------

> [   70.802080][    T1] Call trace:
> [   70.802093][    T1]  debug_print_object+0xec/0x130
> [   70.802106][    T1]  __debug_check_no_obj_freed+0x114/0x290
> [   70.802119][    T1]  debug_check_no_obj_freed+0x18/0x28
> [   70.802130][    T1]  slab_free_freelist_hook+0x18c/0x228
> [   70.802140][    T1]  kfree+0x264/0x420
> [   70.802157][    T1]  _edac_mc_free+0x6c/0x210
> [   70.814163][    T1]  edac_mc_free+0x68/0x88
> [   70.814177][    T1]  ghes_edac_unregister+0x44/0x70
> [   70.814193][    T1]  ghes_remove+0x274/0x2a0

Ugh. This must be the test driver remove thing.

I've reproduced this, but had to remove the parent GHES twice. It looks like it tries to
use the first ghes_edac global variables when freeing the second. ghes_init prevents it
from re-allocating over the top.

The below diff fixes it for me. (I'll post it as a proper patch once I've done the
archaeology)

-----------%<-----------
diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index d413a0bdc9ad..955b59b6aade 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -554,6 +554,7 @@ void ghes_edac_unregister(struct ghes *ghes)
                return;

        mci = ghes_pvt->mci;
+       ghes_pvt = NULL;
        edac_mc_del_mc(mci->pdev);
        edac_mc_free(mci);
 }

-----------%<-----------


Thanks!

James

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ