linux-kernel - Re: [PATCH] slab: remove __alloc_size attribute from __kmalloc_track

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 18 Feb 2022 18:57:47 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     linux-kernel@...r.kernel.org, stable <stable@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        Daniel Micay <danielmicay@...il.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Christoph Lameter <cl@...ux.com>,
        Pekka Enberg <penberg@...nel.org>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Nathan Chancellor <nathan@...nel.org>, linux-mm@...ck.org,
        llvm@...ts.linux.dev
Subject: Re: [PATCH] slab: remove __alloc_size attribute from
 __kmalloc_track_caller

On Fri, Feb 18, 2022 at 06:14:55PM +0100, Vlastimil Babka wrote:
> On 2/18/22 14:13, Greg Kroah-Hartman wrote:
> > Commit c37495d6254c ("slab: add __alloc_size attributes for better
> > bounds checking") added __alloc_size attributes to a bunch of kmalloc
> > function prototypes.  Unfortunately the change to __kmalloc_track_caller
> > seems to cause clang to generate broken code and the first time this is
> > called when booting, the box will crash.
> > 
> > While the compiler problems are being reworked and attempted to be
> > solved, let's just drop the attribute to solve the issue now.  Once it
> > is resolved it can be added back.
> 
> Could we instead wrap it in some #ifdef that' only true for clang build?
> That would make the workaround more precise and self-documented. Even
> better if it can trigger using clang version range and once a fixed
> clang version is here, it can be updated to stay true for older clangs.

It's not doing all that much good like this, let's just remove it for
now until it does actually provide a benifit and not just crash the box :)

This is only 1 function, that is used in only a very small number of
callers.  I do not think it will be missed.

thanks,

greg k-h