Re: crypto: Work around deallocated stack frame reference gcc bug on sparc.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 06, 2017 at 03:04:08PM -0400, David Miller wrote:
> From: David Miller <davem@xxxxxxxxxxxxx>
> 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 <matorola@xxxxxxxxx>
> > Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
> 
> 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 <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux