Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4729418ybi; Tue, 30 Jul 2019 07:10:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqyiPgs+qTvT3bWmnrx5L6/ytWQA6y0NyBHjPwS7Zv8EjlKX8guX6Ri56KT3He66UVOTB1lY X-Received: by 2002:aa7:9a01:: with SMTP id w1mr40711370pfj.262.1564495824987; Tue, 30 Jul 2019 07:10:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564495824; cv=none; d=google.com; s=arc-20160816; b=hxeWF1MFlPAQFUy2ZRPkaPuVqERNqe7X19L4L2LRRJKdfyuiOpml21/AzTNYZiBaRE s05Nos5tuJP5idiSxpxtUIs3/RiGzYcqpG2l3ojJQXKYm3CC34cSRmnCwMT/GukC2HGz 6bcVw12fvertxJgj8gR0pI3iT4G7+YwKSMor6lqxfJX+VKxm+dXbpTu0srqhn0T79EPC kRWP29y38dlnI1l8IMEFq+KYhGc/un9x7gKFEIkUAnCKyh/tB3J3dFXSqQ5Ng0WCcFa0 exkufDjD2XoBz+5OM0wcOQ5ZbDymbp/QSrPGEX/XHgJkBPuW+F0hn+A/6SFEr8UHmBte 7xoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Ou13JSb7APrBhtuQv/5kmhMM+zV7koQaR2bgg5AZQlY=; b=zCSfd/+iLyVY6pGrYd3yon8mNMGvNH7sSU9DDiCy9CW7FPmt19JyUbZR7zxDmfhjI1 KAly+Ma11WlRcZZ+XFClyR21aJVUHy7MYxT/wITZU7q0cAOdNuLsJdlOfg58uWeXUKFT gFQzQAslm2XFQ+1b4a0maA3KcL2Qd2M12zB7cGjvSj4hlDc4fl+6BMfQJDmGenscH1Tf uDOowoqcEUXUKKrcJPo/rGY3FJWzjSMDm1sN9y8Mrlpxnp/8YE5YYsCrpNjjmOtDWh7i 1Gbl8E2NQvpPmAb2xq3kcQMZj9iLbDZSM9iRvJIlXLMnb7gaFqR35mkopjH4gW9fVExo MFEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=j0EFIzRf; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s15si30251389pgm.413.2019.07.30.07.10.06; Tue, 30 Jul 2019 07:10:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=j0EFIzRf; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731789AbfG3Ji1 (ORCPT + 99 others); Tue, 30 Jul 2019 05:38:27 -0400 Received: from mail-io1-f68.google.com ([209.85.166.68]:34696 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728830AbfG3Ji1 (ORCPT ); Tue, 30 Jul 2019 05:38:27 -0400 Received: by mail-io1-f68.google.com with SMTP id k8so126642137iot.1; Tue, 30 Jul 2019 02:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ou13JSb7APrBhtuQv/5kmhMM+zV7koQaR2bgg5AZQlY=; b=j0EFIzRfAw0lRTK+yYPE5ulbxWukeaSAp3cdW3OtkvwySlKqShPEX+esUskyEmaz91 smWqM1KuHFepV/SlIWOSjqsSdg8Rx2XmuuZpOHigBAW4QSrFVXmG7MdUVnC6R9ajU2hm xm15gw005bdAhMxcfib8hbYxQCjB7VN7JpsJ94/H0hBwuKq/94Av/hGYlmwDR0GJvrEI Zl60nLCHPxaRhKZmHADpAje0zxwvLZx/J8L99Ybb886lm1oPeQxkk9KtTFwsj/jRh7zE tWatY/3twGR0P+54g2zzWwAK/Iz5zfAqGrFuLR2sUEL4/fHqysGsmSGKYK1dOCJ3nW0G TeUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ou13JSb7APrBhtuQv/5kmhMM+zV7koQaR2bgg5AZQlY=; b=Y7lKTsJDyBa1QlcMkslkasyaY5LhfA1oDvCsNxCnSLxkyV3AgEoZl2jkg7MP5QDMEp UXuOxk5Vd7T6ZNVdvpMyEgoCa81OrACqqwGob3tyYtj0N5GE5vo1tIhJoW2aWjNQvITH grGmFTIAVErnezdS0fgHF9bOfSGM0d8I+6pnUH14IL+P6Atd7FXhD4OpIOWoWZxY7pVa M2Vkypyvrg0AA8kQ+0pn8WbswoEXyVxSKafKjLJdyEZFkNjZGfKvgvULStwaGsvp1jsb Mf0p0KEJ1POZcSKcVXhs+P5DYsbV/7WYXvBnvO6k//dNCeElbxHAB+5BYxAMkzeHdwdN 2YZA== X-Gm-Message-State: APjAAAUKlUmRl25Uy5oiaeDvscNmdfmEBDvdu39dpTnrazFU08TgNYSM ptr+OFtgSnC7mGuviRSKtzSpaLRuXrvGJbWq7Ss= X-Received: by 2002:a5e:d817:: with SMTP id l23mr6112819iok.282.1564479506244; Tue, 30 Jul 2019 02:38:26 -0700 (PDT) MIME-Version: 1.0 References: <20190724094306.1866-1-baijiaju1990@gmail.com> In-Reply-To: <20190724094306.1866-1-baijiaju1990@gmail.com> From: Ilya Dryomov Date: Tue, 30 Jul 2019 11:41:20 +0200 Message-ID: Subject: Re: [PATCH] net: ceph: Fix a possible null-pointer dereference in ceph_crypto_key_destroy() To: Jia-Ju Bai Cc: Jeff Layton , Sage Weil , "David S. Miller" , Ceph Development , netdev , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 24, 2019 at 11:43 AM Jia-Ju Bai wrote: > > In set_secret(), key->tfm is assigned to NULL on line 55, and then > ceph_crypto_key_destroy(key) is executed. > > ceph_crypto_key_destroy(key) > crypto_free_sync_skcipher(key->tfm) > crypto_skcipher_tfm(tfm) > return &tfm->base; > > Thus, a possible null-pointer dereference may occur. > > To fix this bug, key->tfm is checked before calling > crypto_free_sync_skcipher(). > > This bug is found by a static analysis tool STCheck written by us. > > Signed-off-by: Jia-Ju Bai > --- > net/ceph/crypto.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/net/ceph/crypto.c b/net/ceph/crypto.c > index 5d6724cee38f..ac28463bcfd8 100644 > --- a/net/ceph/crypto.c > +++ b/net/ceph/crypto.c > @@ -136,7 +136,8 @@ void ceph_crypto_key_destroy(struct ceph_crypto_key *key) > if (key) { > kfree(key->key); > key->key = NULL; > - crypto_free_sync_skcipher(key->tfm); > + if (key->tfm) > + crypto_free_sync_skcipher(key->tfm); > key->tfm = NULL; > } > } Hi Jia-Ju, Yeah, looks like the only reason this continued to work after 69d6302b65a8 ("libceph: Remove VLA usage of skcipher") is because crypto_sync_skcipher is a trivial wrapper around crypto_skcipher added just for type checking AFAICT. struct crypto_sync_skcipher { struct crypto_skcipher base; }; Before that ceph_crypto_key_destroy() used crypto_free_skcipher(), which is safe to call on a NULL tfm. Applied with a slight modification -- I moved key->tfm = NULL under the new if and amended the changelog. https://github.com/ceph/ceph-client/commit/b3d79916ff99074d289d66f1643b423ae0008c50 Thanks, Ilya