From patchwork Tue Dec 13 13:34:02 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 87880 Delivered-To: patch@linaro.org Received: by 10.140.20.101 with SMTP id 92csp2204229qgi; Tue, 13 Dec 2016 05:34:12 -0800 (PST) X-Received: by 10.99.37.2 with SMTP id l2mr175167134pgl.160.1481636052828; Tue, 13 Dec 2016 05:34:12 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g5si48019735pfj.289.2016.12.13.05.34.12; Tue, 13 Dec 2016 05:34:12 -0800 (PST) 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 S932564AbcLMNeL (ORCPT + 1 other); Tue, 13 Dec 2016 08:34:11 -0500 Received: from mail-wm0-f54.google.com ([74.125.82.54]:35809 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932656AbcLMNeK (ORCPT ); Tue, 13 Dec 2016 08:34:10 -0500 Received: by mail-wm0-f54.google.com with SMTP id a197so109970254wmd.0 for ; Tue, 13 Dec 2016 05:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=uEUOgg5MEoRtTrULI6E1/xRIyI11p4SIH0yXjRohqlw=; b=jJvJpo4CCwAno60IWrMfph3pO1yPW86n2IibYlS6jTOyAEAem41Gzz0IY4KqDSj/rR 65kYI7769+Z7WbKOVW2Y7rvZOWjBVw6Gj722JYTzlZM8TaLa4zmzBp4rSCC3QBiChmPH pYIyH3H6Y+FyI0bBMv0PXL/0/EXIFRyk0kr3E= 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; bh=uEUOgg5MEoRtTrULI6E1/xRIyI11p4SIH0yXjRohqlw=; b=enQjh98H/V3qyNXEuApGOzcR/MUj8F/UAdhRBpEbhf04OlMGW/wFMYePFe4bINXatm 6hgNGwIbKsQAsbh2CXthvJiceueNYhn9onjWjOZwaLzTG2ktubjBjVjICWkc37NeVR6d qhd+BHQbGuwtW8XS0+ybGoZ9khb2zNArVdaldbEp20J6dGBgW9RFYnITRLAmMCte2LR+ EfarV5lw9QbOxG1N6xZg4t+cof/LV6V7RGclMKXE44Fb/7pgknQyeTIzFfNsA5Y+AXZV ZlNjMc6qLhfBnBWdRmRHfts2DTy1LwxE+hztUf1peZ39ua81Wo7Gb7fy0OOMFnuJOF0u M/WA== X-Gm-Message-State: AKaTC03dlV0olNfh0/r48j1Bh2BnQevOng2vKBNNv/WUsx2EIhiqtcWFnnwMoalhl1KxpFj4 X-Received: by 10.28.47.196 with SMTP id v187mr2660179wmv.75.1481636049160; Tue, 13 Dec 2016 05:34:09 -0800 (PST) Received: from localhost.localdomain ([105.150.173.252]) by smtp.gmail.com with ESMTPSA id js10sm62275178wjb.19.2016.12.13.05.34.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Dec 2016 05:34:08 -0800 (PST) From: Ard Biesheuvel To: linux-crypto@vger.kernel.org Cc: herbert@gondor.apana.org.au, Ard Biesheuvel Subject: [PATCH] crypto: skcipher - fix crash in virtual walk Date: Tue, 13 Dec 2016 13:34:02 +0000 Message-Id: <1481636042-27347-1-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.7.4 Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org The new skcipher walk API may crash in the following way. (Interestingly, the tcrypt boot time tests seem unaffected, while an explicit test using the module triggers it) Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... [] __memcpy+0x84/0x180 [] skcipher_walk_done+0x328/0x340 [] ctr_encrypt+0x84/0x100 [] simd_skcipher_encrypt+0x88/0x98 [] crypto_rfc3686_crypt+0x8c/0x98 [] test_skcipher_speed+0x518/0x820 [tcrypt] [] do_test+0x1408/0x3b70 [tcrypt] [] tcrypt_mod_init+0x50/0x1000 [tcrypt] [] do_one_initcall+0x44/0x138 [] do_init_module+0x68/0x1e0 [] load_module+0x1fd0/0x2458 [] SyS_finit_module+0xe0/0xf0 [] el0_svc_naked+0x24/0x28 This is due to the fact that skcipher_done_slow() may be entered with walk->buffer unset. Since skcipher_walk_done() already deals with the case where walk->buffer == walk->page, it appears to be the intention that walk->buffer point to walk->page after skcipher_next_slow(), so ensure that is the case. Signed-off-by: Ard Biesheuvel --- crypto/skcipher.c | 4 +++- 1 file changed, 3 insertions(+), 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 Tested-by: Milan Broz diff --git a/crypto/skcipher.c b/crypto/skcipher.c index aca07c643d41..0e1e6c35188e 100644 --- a/crypto/skcipher.c +++ b/crypto/skcipher.c @@ -226,7 +226,9 @@ static int skcipher_next_slow(struct skcipher_walk *walk, unsigned int bsize) void *v; if (!phys) { - buffer = walk->buffer ?: walk->page; + if (!walk->buffer) + walk->buffer = walk->page; + buffer = walk->buffer; if (buffer) goto ok; }