Since a crypto_ahash_import() can be called against a request context
that has not had a crypto_ahash_init() performed, the request context
needs to be cleared to insure there is no random data present. If not,
the random data can result in a kernel oops during crypto_ahash_update().
Cc: # 3.14.x
On 02/25/2016 04:11 PM, Herbert Xu wrote:
> On Thu, Feb 25, 2016 at 03:56:31PM -0600, Tom Lendacky wrote:
>>
>> I can fix this in the driver by doing a memset to zero of the request
>> context area during the import. But I guess I'm also wondering if there
>> is an expectation/requirement that cryp
On Thu, Feb 25, 2016 at 03:56:31PM -0600, Tom Lendacky wrote:
>
> I can fix this in the driver by doing a memset to zero of the request
> context area during the import. But I guess I'm also wondering if there
> is an expectation/requirement that crypto_ahash_init() be called before
> doing an impo
I'm seeing an issue on one system that I wasn't seeing on another
system. It turns out that the testmgr sha testing exports an ahash
request context, allocates a new ahash request context and then imports
into that new ahash request context. Since crypto_ahash_init() is not
performed the driver req
你的老朋友邀你来Q群:343257759
On Wed, Feb 24, 2016 at 09:37:39PM +, Mark McKinstry wrote:
> On 19/02/16 01:19, Steffen Klassert wrote:
> > On Thu, Feb 18, 2016 at 01:40:00AM +, Mark McKinstry wrote:
> >> This patch fixes our issue, thanks. In our scenario the tunnel path MTU
> >> now gets updated so that subsequent larg
