On Tue, Jun 06, 2017 at 03:04:08PM -0400, David Miller wrote:
> From: David Miller
> 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
From: David Miller
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 a
From: David Miller
Date: Fri, 02 Jun 2017 14:39:06 -0400 (EDT)
> From: "Darrick J. Wong"
> Date: Fri, 2 Jun 2017 11:08:08 -0700
>
>> ext4/jbd2's crc32c implementations will also need a fix like this for
>> {ext4,jbd2}_chksum. Note that both of these modules call the crypto api
>> directly to a
From: "Darrick J. Wong"
Date: Fri, 2 Jun 2017 11:08:08 -0700
> ext4/jbd2's crc32c implementations will also need a fix like this for
> {ext4,jbd2}_chksum. Note that both of these modules call the crypto api
> directly to avoid a static dependence on libcrc32c; this was done to
> reduce kernel fo
[add ext4 list to cc]
On Fri, Jun 02, 2017 at 11:28:54AM -0400, David Miller wrote:
>
> 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
