From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753538AbcG3RHN (ORCPT ); Sat, 30 Jul 2016 13:07:13 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:51008 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752094AbcG3RHG (ORCPT ); Sat, 30 Jul 2016 13:07:06 -0400 Date: Sat, 30 Jul 2016 10:07:20 -0700 From: Greg KH To: Kirill Marinushkin Cc: dhowells@redhat.com, zer0mem@yahoo.com, serge@hallyn.com, james.l.morris@oracle.com, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] KEYS: Sort out big_key initialisation Message-ID: <20160730170720.GA10208@kroah.com> References: <1469895701-27055-1-git-send-email-k.marinushkin@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1469895701-27055-1-git-send-email-k.marinushkin@gmail.com> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 30, 2016 at 06:21:41PM +0200, Kirill Marinushkin wrote: > big_key has two separate initialisation functions, one that registers the > key type and one that registers the crypto. If the key type fails to > register, there's no problem if the crypto registers successfully because > there's no way to reach the crypto except through the key type. > > However, if the key type registers successfully but the crypto does not, > big_key_rng and big_key_blkcipher may end up set to NULL - but the code > neither checks for this nor unregisters the big key key type. > > Furthermore, since the key type is registered before the crypto, it is > theoretically possible for the kernel to try adding a big_key before the > crypto is set up, leading to the same effect. > > Fix this by merging big_key_crypto_init() and big_key_init() and calling > the resulting function late. If they're going to be encrypted, we > shouldn't be creating big_keys before we have the facilities to do the > encryption available. The key type registration is also moved after the > crypto initialisation. > > The fix also includes message printing on failure. > > If the big_key type isn't correctly set up, simply doing: > > dd if=/dev/zero bs=4096 count=1 | keyctl padd big_key a @s > > ought to cause an oops. > > Signed-off-by: David Howells > Signed-off-by: Kirill Marinushkin > --- > security/keys/Kconfig | 2 +- > security/keys/big_key.c | 62 +++++++++++++++++++++++++++---------------------- > 2 files changed, 35 insertions(+), 29 deletions(-) This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly.