linux-kernel - Re: Crypto Fixes for 4.12

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]

Message-Id: <20170616.124953.645541138227532301.davem@davemloft.net>
Date:   Fri, 16 Jun 2017 12:49:53 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     tytso@....edu
Cc:     torvalds@...ux-foundation.org, herbert@...dor.apana.org.au,
        linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org
Subject: Re: Crypto Fixes for 4.12

From: Theodore Ts'o <tytso@....edu>
Date: Fri, 16 Jun 2017 08:50:07 -0400

> On Thu, Jun 15, 2017 at 11:01:18AM -0400, David Miller wrote:
>> As a side note, ext4 does something similar with a private
>> implementation, but it doesn't use something the evaluates to an
>> alloca.  Instead it uses a fixed 4-byte size for the shash context
>> value in the on-stack declaration.
> 
> In ext4's case, we're doing it inside an inline function, and then
> using the "return" value from inside the calling function.  Assuming
> that gcc actually inlines the function, are we in danger of tripping
> over the bug?

Again, the bug can only be triggered if you do a dynamically sized
object on the stack.

Which ext4 is not doing, since it uses fixed size elements in the
on-stack shash context.