Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 15 Jun 2017 18:04:44 +0900 | Subject | Re: Crypto Fixes for 4.12 |
| |
On Thu, Jun 15, 2017 at 9:54 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > This push fixes a bug on sparc where we may dereference freed stack > memory.
Ugh, that's a particularly ugly fix for a random gcc bug on a random architecture that almost nobody tests.
In other words, it's nasty. It's nasty because nobody sane will ever realize this pattern, and the code will either bit-rot or just happen again somewhere else.
I'd have been *much* happier if this had been some nicer abstraction that is built up around the use of SHASH_DESC_ON_STACK(), and just have some rule that "SHASH_DESC_ON_STACK()" needs to be paired with retrieving the final value and then a SHASH_DESC_DEALLOC() or whatever.
Then you *could* implement SHASH_DESC_ON_STACK() as a kmalloc, and SHASH_DESC_DEALLOC() would be a kfree - but with an alloca()-like allocation the SHASH_DESC_DEALLOC() would be that "barrier_data()".
At that point the interface would make _sense_ at some conceptual level, rather than being a random hack for a small collection of random users of this thing.
There's a fair number of SHASH_DESC_ON_STACK users, are all the others safe for some random reason that just happens to be about code generation? Did people actually verify that?
Linus
| |