linux-kernel - Re: kmemleak detects leak in msr_build

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: <YeFZ/cPoKPx4h1N0@arm.com>
Date:   Fri, 14 Jan 2022 11:09:49 +0000
From:   Catalin Marinas <catalin.marinas@....com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Paul Menzel <pmenzel@...gen.mpg.de>,
        Dave Hansen <dave.hansen@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org
Subject: Re: kmemleak detects leak in msr_build_context

On Wed, Jan 12, 2022 at 12:16:17AM +0100, Borislav Petkov wrote:
> On Tue, Jan 11, 2022 at 10:05:43PM +0100, Paul Menzel wrote:
> > [    0.672475] smpboot: CPU0: AMD A6-6400K APU with Radeon(tm) HD Graphics (family: 0x15, model: 0x13, stepping: 0x1)
> 
> I have a similar box to yours:
> 
> [    0.382127] smpboot: CPU0: AMD PRO A12-8800B R7, 12 Compute Cores 4C+8G (family: 0x15, model: 0x60, stepping: 0x1)
> 
> ...
> 
> [    0.974044] x86/pm: family 0x15 cpu detected, MSR saving is needed during suspending.
> 
> well, Bulldozer-based at least, and booting with kmemleak enabled is fine:
> 
> $ cat /sys/kernel/debug/kmemleak 
> $
> 
> I wonder whether you have something else applied and forgotten along
> with all those random printks I'm seeing in dmesg...
> 
> Also,
> 
> unreferenced object 0xffff8914823de500 (size 64):
> 					^^^^^^^^
> 
> That's strange too - sizeof(struct saved_msr) is 40 and not 64 so that
> looks weird...

That's probably because slab_post_alloc_hook() doesn't get the original
kmalloc() size, so it uses the slab object size when calling the
kmemleak hook.

-- 
Catalin