From patchwork Tue Sep 13 08:48:53 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 76046 Delivered-To: patch@linaro.org Received: by 10.140.106.72 with SMTP id d66csp1253996qgf; Tue, 13 Sep 2016 01:49:03 -0700 (PDT) X-Received: by 10.66.222.169 with SMTP id qn9mr35633388pac.133.1473756543231; Tue, 13 Sep 2016 01:49:03 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id cz4si26506702pad.270.2016.09.13.01.49.03; Tue, 13 Sep 2016 01:49:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756644AbcIMItC (ORCPT + 1 other); Tue, 13 Sep 2016 04:49:02 -0400 Received: from mail-wm0-f50.google.com ([74.125.82.50]:38227 "EHLO mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756474AbcIMItB (ORCPT ); Tue, 13 Sep 2016 04:49:01 -0400 Received: by mail-wm0-f50.google.com with SMTP id 1so187941171wmz.1 for ; Tue, 13 Sep 2016 01:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=9yfE2zRsINQBUYbUkYgt9dob7ZMhncdGzNYN1T8RSsA=; b=aXitfO9PUuijsfN7RwXkel45DYm5WbYjUEa2Q+DHNm4Mc+zXdgHEXgHjL5I22FrcMR tszSoGemAoo0zc1PUDvwB8D0DNi1Q49g/LTctXj7GyqSISn2o/7D/aNJ+HaOB4iZeV0t yM/HUtJxr9aNBr37Aku01Sa6OouNL6o6fxjCY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=9yfE2zRsINQBUYbUkYgt9dob7ZMhncdGzNYN1T8RSsA=; b=GXRGcDrSUI1f/rsSJxh9z9e7GkiDSboOf/ATm3MLPfhEqPPe66U7eGyh1LiceitCCX WkY3YBcQMTMZ9WfVuqU+VQAWZnhU80NVSP0HS+rmP4Pt43D+iFvwQSsLO033Yqrqp3mH z1yIJ6pHsd6Tp9/bnayokVrm6N7YL/HrsEcifVkNUkpqWDvV/0bNLHjZs6Lgm98WnvHH hN/D4/CviuuWQfKuj2yA8g5DhEhxmL+XlLt2/xgQHatvb/MKaiFYQKnQuenBasXtWaTh dtZOG0fsj1phD8aYiN4G57hh8a5XZaF6rTNtpF1AyJEVB7Dw77SB1cRNvnAoA2K0FIAE HU7w== X-Gm-Message-State: AE9vXwOZY78WYWidjZ/YxAdeSUd92AEgFvMWQ8siy1c53X58qZN1F2gbbNLq1cwLuhi5Rbbi X-Received: by 10.28.139.75 with SMTP id n72mr3854984wmd.104.1473756540233; Tue, 13 Sep 2016 01:49:00 -0700 (PDT) Received: from localhost.localdomain ([197.128.106.42]) by smtp.gmail.com with ESMTPSA id nd1sm16866713wjb.22.2016.09.13.01.48.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Sep 2016 01:48:59 -0700 (PDT) From: Ard Biesheuvel To: linux-crypto@vger.kernel.org, herbert@gondor.apana.org.au, linux-arm-kernel@lists.infradead.org Cc: xiakaixu@huawei.com, Ard Biesheuvel Subject: [PATCH 2/2] crypto: arm64/aes-ctr: fix NULL dereference in tail processing Date: Tue, 13 Sep 2016 09:48:53 +0100 Message-Id: <1473756533-21078-2-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1473756533-21078-1-git-send-email-ard.biesheuvel@linaro.org> References: <1473756533-21078-1-git-send-email-ard.biesheuvel@linaro.org> Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org The AES-CTR glue code avoids calling into the blkcipher API for the tail portion of the walk, by comparing the remainder of walk.nbytes modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight into the tail processing block if they are equal. This tail processing block checks whether nbytes != 0, and does nothing otherwise. However, in case of an allocation failure in the blkcipher layer, we may enter this code with walk.nbytes == 0, while nbytes > 0. In this case, we should not dereference the source and destination pointers, since they may be NULL. So instead of checking for nbytes != 0, check for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in non-error conditions. Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions") Reported-by: xiakaixu Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/aes-glue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c index 5c888049d061..6b2aa0fd6cd0 100644 --- a/arch/arm64/crypto/aes-glue.c +++ b/arch/arm64/crypto/aes-glue.c @@ -216,7 +216,7 @@ static int ctr_encrypt(struct blkcipher_desc *desc, struct scatterlist *dst, err = blkcipher_walk_done(desc, &walk, walk.nbytes % AES_BLOCK_SIZE); } - if (nbytes) { + if (walk.nbytes % AES_BLOCK_SIZE) { u8 *tdst = walk.dst.virt.addr + blocks * AES_BLOCK_SIZE; u8 *tsrc = walk.src.virt.addr + blocks * AES_BLOCK_SIZE; u8 __aligned(8) tail[AES_BLOCK_SIZE];