From patchwork Tue Mar 13 04:29:06 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tycho Andersen X-Patchwork-Id: 10277761 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id DE5A1601A0 for ; Tue, 13 Mar 2018 04:29:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E7B2928C47 for ; Tue, 13 Mar 2018 04:29:48 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DA73F28D17; Tue, 13 Mar 2018 04:29:48 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id 04CA028C47 for ; Tue, 13 Mar 2018 04:29:47 +0000 (UTC) Received: (qmail 3377 invoked by uid 550); 13 Mar 2018 04:29:46 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 3357 invoked from network); 13 Mar 2018 04:29:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tycho-ws.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=3m64m4812TaCibAtDMzmJiivBFzUMendi6gNta4oOlM=; b=dX53qXgS9TcZ6CNNZmciKy75wBUsc2aH8yXs5PJpAtsRj+1PKO5d7luQh/0w0eoiE+ y8nG5ZwngBgBpKMse1i1/a/wEJUF9fuYOTykSdEeG53nFBrARlLTxtR+5RKBDXWWFuhF EhtGtjBm+3wfVWW+O6JHg725/OpDYydua77GmkwqYhv8WgqcPPqtH5LWTHaC8ERMy6sp gbSfjobX0ybS/cbRGg394oPBDaxPhbgEFpVkDl8Xa+LaXty6J7f73YKTNfaKWHw0hSl1 ImREio0UIv0h2qhwMm+FmLGxmxh07KNDpvgP9/PZm61RINVP5ehbVC3f8aWcjEhbBy+x iwmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=3m64m4812TaCibAtDMzmJiivBFzUMendi6gNta4oOlM=; b=R6gsN46xQtow4Jhk6yTaJKaE817kB2g7PG9sCxOY8So+NiN9ap7/HBKS5Q24vJG1SF 1XqPt7MYjIvCiY/pkBfQdXUem/7T1LvuN33k+iFkieLNje0h+O32LsF56K401XpSddge dPOJSInBPNJzjbXZRTXy8qC/Tz4hfGYayW2/TYCQfvQPcLrhHGM4SeBS9pWhzvwyvShn oiQ6w/xFY5rSF8YxfLBWouXH9o+1y8mk8U6DER4pd9zCmmf2U4AQbQIMRsgNcOPQsp03 ZWnm30nNb8TP6Zwu4Y0CIM3T1gsokJoKtfGJT17E04thu49LLglPmvjPGxNNSkx7AdgQ BoHw== X-Gm-Message-State: AElRT7FCd0/p1ADBWYDtp9VRqduJPB9bN2n04h7AEh407CMWbPyf4Rkk fY0cK3vgRYJJiplakSx7t9wSYg== X-Google-Smtp-Source: AG47ELttJaW0CNOzxtcWdASOQ6gS30HF71ou4wrBR2zpBH8Ab0GBYzwiiO3+sY5KV7/LnBMFpVEqZw== X-Received: by 10.36.46.22 with SMTP id i22mr10919635ita.59.1520915373317; Mon, 12 Mar 2018 21:29:33 -0700 (PDT) From: Tycho Andersen To: David Howells Cc: keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, Tycho Andersen , James Morris , "Serge E. Hallyn" , "Jason A . Donenfeld" Subject: [PATCH 1/2] big key: get rid of stack array allocation Date: Mon, 12 Mar 2018 22:29:06 -0600 Message-Id: <20180313042907.29598-1-tycho@tycho.ws> X-Mailer: git-send-email 2.15.1 X-Virus-Scanned: ClamAV using ClamSMTP We're interested in getting rid of all of the stack allocated arrays in the kernel [1]. This patch removes one in keys by switching to malloc/free. Note that we use kzalloc, to avoid leaking the nonce. I'm not sure this is really necessary, but extra paranoia seems prudent. Manually tested using the program from the add_key man page to trigger big_key. [1]: https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Tycho Andersen CC: David Howells CC: James Morris CC: "Serge E. Hallyn" CC: Jason A. Donenfeld --- security/keys/big_key.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/security/keys/big_key.c b/security/keys/big_key.c index fa728f662a6f..70f9f785c59d 100644 --- a/security/keys/big_key.c +++ b/security/keys/big_key.c @@ -108,13 +108,18 @@ static int big_key_crypt(enum big_key_op op, struct big_key_buf *buf, size_t dat * an .update function, so there's no chance we'll wind up reusing the * key to encrypt updated data. Simply put: one key, one encryption. */ - u8 zero_nonce[crypto_aead_ivsize(big_key_aead)]; + u8 *zero_nonce; + + zero_nonce = kzalloc(crypto_aead_ivsize(big_key_aead), GFP_KERNEL); + if (!zero_nonce) + return -ENOMEM; aead_req = aead_request_alloc(big_key_aead, GFP_KERNEL); - if (!aead_req) + if (!aead_req) { + kfree(zero_nonce); return -ENOMEM; + } - memset(zero_nonce, 0, sizeof(zero_nonce)); aead_request_set_crypt(aead_req, buf->sg, buf->sg, datalen, zero_nonce); aead_request_set_callback(aead_req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL); aead_request_set_ad(aead_req, 0); @@ -131,6 +136,7 @@ static int big_key_crypt(enum big_key_op op, struct big_key_buf *buf, size_t dat error: mutex_unlock(&big_key_aead_lock); aead_request_free(aead_req); + kzfree(zero_nonce); return ret; }