From patchwork Fri Oct 14 13:09:00 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 9376785 X-Patchwork-Delegate: johannes@sipsolutions.net 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 EDBBD607FD for ; Fri, 14 Oct 2016 13:09:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E0D792A68B for ; Fri, 14 Oct 2016 13:09:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D5A902A690; Fri, 14 Oct 2016 13:09:53 +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=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_HI,RCVD_IN_SORBS_SPAM autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5ED9C2A68B for ; Fri, 14 Oct 2016 13:09:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932550AbcJNNJe (ORCPT ); Fri, 14 Oct 2016 09:09:34 -0400 Received: from mail-qk0-f177.google.com ([209.85.220.177]:34599 "EHLO mail-qk0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932453AbcJNNJI (ORCPT ); Fri, 14 Oct 2016 09:09:08 -0400 Received: by mail-qk0-f177.google.com with SMTP id f128so140716534qkb.1 for ; Fri, 14 Oct 2016 06:09:07 -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; bh=xChN/6gbHLLqDN31boFTkrP5EYe8SV864oXs1B229As=; b=KOx8GPoNn5fALrVTPTkFCtVvw4UJuaIRFpaStZX9A7GhKF0+Q4WB7QT9cUc0qSpRDf Br0HRYkseOZZJFmjazZAQmhp4dWPGKITUEXDiKmxWHdwZMBa3rLN75kjGhOhYJ2WXVMP HN3EiLSjINFo0R+tt+8X5UfIbVKajUXLnWix8= 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=xChN/6gbHLLqDN31boFTkrP5EYe8SV864oXs1B229As=; b=Sk/mDqmWhYTueCBxB9WJwOArdaF3QTP2lDq2f4HdysaQYBA23naoWMTiy3JrjkczCD 8eFcvW5+CyTXeTp5yGTBdI9fImcJrYlHb6ixaIqUIIrmWYB7sBk2MNKSNa0Gkohcp9Y1 MQP0kw0RcPrHnFwh/VW96VuBVzdoMhGK8ZFaO/NTkqn/ToXUJ7cW7dXYhJRFdIodGG9H Tv4RXxtGaAsYR7IJVva8gmORDgiz2XjBSXND5zrCMsHsnLjGmAEBiHi3lLgNfmwe0xJV 2HVs95sn5PBlcPm3dl+hrI8tszyVJKDK5Gc67gHe2qeHMmLkHBlbcHnAgqbRw/vmu/jj UZaw== X-Gm-Message-State: AA6/9Rm2e8wRr8FlMrArwGlkSAL158YVv9qKQCE/VsZR3uxPpgA80isjrH2jjS2Ruq5ex5m7 X-Received: by 10.194.36.103 with SMTP id p7mr1943323wjj.214.1476450546337; Fri, 14 Oct 2016 06:09:06 -0700 (PDT) Received: from localhost.localdomain ([105.149.88.69]) by smtp.gmail.com with ESMTPSA id o1sm31871898wjh.9.2016.10.14.06.09.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 14 Oct 2016 06:09:05 -0700 (PDT) From: Ard Biesheuvel To: johannes@sipsolutions.net, luto@amacapital.net, sergey.senozhatsky.work@gmail.com, netdev@vger.kernel.org, herbert@gondor.apana.org.au, davem@davemloft.net, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, j@w1.fi Cc: Ard Biesheuvel Subject: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack Date: Fri, 14 Oct 2016 14:09:00 +0100 Message-Id: <1476450540-1760-1-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.7.4 Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Some CCM implementations (such as the generic CCM wrapper in crypto/) use scatterlists to map fields of struct aead_req. This means these data structures cannot live in the vmalloc area, which means that in the near future, they can no longer live on the stack either. Given that these data structures have implementation specific context fields, it really depends on the particular driver whether this issue is likely to occur or not, and so it seems best to simply move the entire data structure into the direct mapped kernel heap. So use kzalloc/kfree to allocate and free the data structures. This pattern already exists in the IPsec ESP driver, but in the future, we may need to improve upon this by either moving the request into the SKB, or using a slab cache to allocate/free the data structures. Signed-off-by: Ard Biesheuvel --- This only addresses one half of the problem. The other problem, i.e., the fact that the aad[] array lives on the stack of the caller, is handled adequately imo by the change proposed by Johannes. net/mac80211/aes_ccm.c | 24 ++++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c index 7663c28ba353..a0ae8cebbe4e 100644 --- a/net/mac80211/aes_ccm.c +++ b/net/mac80211/aes_ccm.c @@ -23,13 +23,10 @@ void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, size_t mic_len) { struct scatterlist sg[3]; + struct aead_request *aead_req; - char aead_req_data[sizeof(struct aead_request) + - crypto_aead_reqsize(tfm)] - __aligned(__alignof__(struct aead_request)); - struct aead_request *aead_req = (void *) aead_req_data; - - memset(aead_req, 0, sizeof(aead_req_data)); + aead_req = kzalloc(sizeof(struct aead_request) + + crypto_aead_reqsize(tfm), GFP_ATOMIC); sg_init_table(sg, 3); sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad)); @@ -41,6 +38,7 @@ void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, aead_request_set_ad(aead_req, sg[0].length); crypto_aead_encrypt(aead_req); + kfree(aead_req); } int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, @@ -48,15 +46,14 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, size_t mic_len) { struct scatterlist sg[3]; - char aead_req_data[sizeof(struct aead_request) + - crypto_aead_reqsize(tfm)] - __aligned(__alignof__(struct aead_request)); - struct aead_request *aead_req = (void *) aead_req_data; + struct aead_request *aead_req; + int err; if (data_len == 0) return -EINVAL; - memset(aead_req, 0, sizeof(aead_req_data)); + aead_req = kzalloc(sizeof(struct aead_request) + + crypto_aead_reqsize(tfm), GFP_ATOMIC); sg_init_table(sg, 3); sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad)); @@ -67,7 +64,10 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, aead_request_set_crypt(aead_req, sg, sg, data_len + mic_len, b_0); aead_request_set_ad(aead_req, sg[0].length); - return crypto_aead_decrypt(aead_req); + err = crypto_aead_decrypt(aead_req); + kfree(aead_req); + + return err; } struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],