On Tue, Jun 06, 2017 at 03:04:08PM -0400, David Miller wrote: > From: David Miller <da...@davemloft.net> > Date: Fri, 02 Jun 2017 11:28:54 -0400 (EDT) > > > > > On sparc, if we have an alloca() like situation, as is the case with > > SHASH_DESC_ON_STACK(), we can end up referencing deallocated stack > > memory. The result can be that the value is clobbered if a trap > > or interrupt arrives at just the right instruction. > > > > It only occurs if the function ends returning a value from that > > alloca() area and that value can be placed into the return value > > register using a single instruction. > > > > For example, in lib/libcrc32c.c:crc32c() we end up with a return > > sequence like: > > > > return %i7+8 > > lduw [%o5+16], %o0 ! MEM[(u32 *)__shash_desc.1_10 + 16B], > > > > %o5 holds the base of the on-stack area allocated for the shash > > descriptor. But the return released the stack frame and the > > register window. > > > > So if an intererupt arrives between 'return' and 'lduw', then > > the value read at %o5+16 can be corrupted. > > > > Add a data compiler barrier to work around this problem. This is > > exactly what the gcc fix will end up doing as well, and it absolutely > > should not change the code generated for other cpus (unless gcc > > on them has the same bug :-) > > > > With crucial insight from Eric Sandeen. > > > > Reported-by: Anatoly Pugachev <mator...@gmail.com> > > Signed-off-by: David S. Miller <da...@davemloft.net> > > Herbert, please take a look at this and push via your crypto tree > and submit to -stable if you don't have any objections.
Sure I'll push it today. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
