[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <VI1PR0402MB371251675D031EBB78F206238CC00@VI1PR0402MB3712.eurprd04.prod.outlook.com>
Date: Wed, 8 Apr 2020 08:15:37 +0000
From: Iuliana Prodan <iuliana.prodan@....com>
To: Horia Geanta <horia.geanta@....com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Aymen Sghaier <aymen.sghaier@....com>
CC: "David S. Miller" <davem@...emloft.net>,
Silvano Di Ninno <silvano.dininno@....com>,
Franck Lenormand <franck.lenormand@....com>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
dl-linux-imx <linux-imx@....com>
Subject: Re: [PATCH] crypto: caam - fix the address of the last entry of S/G
On 4/7/2020 9:56 PM, Horia Geanta wrote:
> On 4/7/2020 6:59 PM, Iuliana Prodan wrote:
>> For skcipher algorithms, the input, output HW S/G tables
>> look like this: [IV, src][dst, IV]
>> Now, we can have 2 conditions here:
>> - there is no IV;
>> - src and dst are equal (in-place encryption) and scattered
>> and the error is an "off-by-one" in the HW S/G table.
>>
>> This issue was seen with KASAN:
>> BUG: KASAN: slab-out-of-bounds in skcipher_edesc_alloc+0x95c/0x1018
>>
>> Read of size 4 at addr ffff000022a02958 by task cryptomgr_test/321
>>
>> CPU: 2 PID: 321 Comm: cryptomgr_test Not tainted
>> 5.6.0-rc1-00165-ge4ef8383-dirty #4
> Non-public SHA1, dirty tree.
>
> Probably it's not reproducible without applying previous fixes?
> https://patchwork.kernel.org/project/linux-crypto/list/?series=266561
Yes, this appears after applying the use-after-free patches.
>> Fixes: 334d37c9e263 ("crypto: caam - update IV using HW support")
>> Cc: <stable@...r.kernel.org> # v5.3+
>> Signed-off-by: Iuliana Prodan <iuliana.prodan@....com>
> Reviewed-by: Horia Geantă <horia.geanta@....com>
>
> Thanks,
> Horia
>
Powered by blists - more mailing lists