From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DBBF5C433EF for ; Fri, 22 Jul 2022 03:16:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:CC:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ky+7Tqw736j0Rc+G6O1omSXsqrNo3sw/mKwIUv9TZyk=; b=kbOYEpddJhUmlb iQUfovxPmWCSgNvzKCTTUlqO+a8nwzdGv/mlBbVzOJ0MdmWiVNB66szmMwv5PLezTnL1/xvw0lHnI IjZrFL4f2VodeC99aAHNc+MkInsgKDE7ndGVhnwJ1JLTFWffeyKIVHjC1zrCPBBLLwWtVNuyWHYbh Gi2wcsNLRhrZlmX93MzMaE8CeVM93qCNRy26ddms144hKOfHO+L6mqv4XGukWfY2b7FCkxx6YBTcH tUk8fdLIzbLVhIXjdJu5xNw/t3jTql8fd83hgOlfZJTNco+bTnV5ZJfmGjrVl5NO6GdIn4Yh1z1BZ NQGeTi9ZDrqZcMbfihMw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oEj87-00H9NQ-Kj; Fri, 22 Jul 2022 03:15:07 +0000 Received: from szxga02-in.huawei.com ([45.249.212.188]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oEj82-00H9Gc-0U for linux-arm-kernel@lists.infradead.org; Fri, 22 Jul 2022 03:15:05 +0000 Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Lpvcq75K3zkXQd; Fri, 22 Jul 2022 11:12:27 +0800 (CST) Received: from [10.67.110.173] (10.67.110.173) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 22 Jul 2022 11:14:52 +0800 Message-ID: <6eb023d2-ba6a-c033-9d16-e03d3e5fa286@huawei.com> Date: Fri, 22 Jul 2022 11:14:52 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH v2] arm64/crypto: poly1305 fix a read out-of-bound Content-Language: en-US To: Will Deacon , Eric Biggers CC: , , , , References: <20220712075031.29061-1-guozihua@huawei.com> <20220720094116.GC15752@willie-the-truck> <20220721092858.GA17088@willie-the-truck> From: "Guozihua (Scott)" In-Reply-To: <20220721092858.GA17088@willie-the-truck> X-Originating-IP: [10.67.110.173] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm500024.china.huawei.com (7.185.36.203) X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220721_201502_490906_2172D88D X-CRM114-Status: GOOD ( 18.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022/7/21 17:28, Will Deacon wrote: > On Wed, Jul 20, 2022 at 07:37:17PM -0700, Eric Biggers wrote: >> On Wed, Jul 20, 2022 at 05:57:30PM +0800, Guozihua (Scott) wrote: >>> On 2022/7/20 17:41, Will Deacon wrote: >>>> On Tue, Jul 12, 2022 at 03:50:31PM +0800, GUO Zihua wrote: >>>>> A kasan error was reported during fuzzing: >>>> >>>> [...] >>>> >>>>> This patch fixes the issue by calling poly1305_init_arm64() instead of >>>>> poly1305_init_arch(). This is also the implementation for the same >>>>> algorithm on arm platform. >>>>> >>>>> Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementation") >>>>> Cc: stable@vger.kernel.org >>>>> Signed-off-by: GUO Zihua >>>>> --- >>>>> arch/arm64/crypto/poly1305-glue.c | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> I'm not a crypto guy by any stretch of the imagination, but Ard is out >>>> at the moment and this looks like an important fix so I had a crack at >>>> reviewing it. >>>> >>>>> diff --git a/arch/arm64/crypto/poly1305-glue.c b/arch/arm64/crypto/poly1305-glue.c >>>>> index 9c3d86e397bf..1fae18ba11ed 100644 >>>>> --- a/arch/arm64/crypto/poly1305-glue.c >>>>> +++ b/arch/arm64/crypto/poly1305-glue.c >>>>> @@ -52,7 +52,7 @@ static void neon_poly1305_blocks(struct poly1305_desc_ctx *dctx, const u8 *src, >>>>> { >>>>> if (unlikely(!dctx->sset)) { >>>>> if (!dctx->rset) { >>>>> - poly1305_init_arch(dctx, src); >>>>> + poly1305_init_arm64(&dctx->h, src); >>>>> src += POLY1305_BLOCK_SIZE; >>>>> len -= POLY1305_BLOCK_SIZE; >>>>> dctx->rset = 1; >>>> >>>> With this change, we no longer initialise dctx->buflen to 0 as part of the >>>> initialisation. Looking at neon_poly1305_do_update(), I'm a bit worried >>>> that we could land in the 'if (likely(len >= POLY1305_BLOCK_SIZE))' block, >>>> end up with len == 0 and fail to set dctx->buflen. Is this a problem, or is >>>> my ignorance showing? >>>> >>>> Will >>>> . >>> >>> Thanks Will. >>> >>> I noticed this as well, but I leaved it out so that the behavior is the same >>> as the implementation for arm. The buflen here seems to be used for >>> maintaining any excessive data after the last block, and is zeroed during >>> init. I am not sure why it should be zeroed again during key initialization. >>> Maybe the thought was that the very first block of the data is always used >>> for initializing rset and that is also considered to be the "initialization" >>> process for the algorithm, thus the zeroing of buflen. I could be completely >>> wrong though. >>> >> >> buflen is initialized by neon_poly1305_init(), so there's no issue here. > > Ah yes, thanks. I missed that. In which case, for the very little it's > worth: > > Acked-by: Will Deacon > > Herbert, please can you pick this up? > > Will > . Thanks Will. Herbert, would you please wait for a v3 patch? I'll update the reproduce example based on Eric's comment. -- Best GUO Zihua _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel