From patchwork Fri Apr 21 08:30:37 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 9692101 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 19D2D6037F for ; Fri, 21 Apr 2017 08:34:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0BA8E28613 for ; Fri, 21 Apr 2017 08:34:41 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0095528617; Fri, 21 Apr 2017 08:34:40 +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.3 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham 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 9FB2928613 for ; Fri, 21 Apr 2017 08:34:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1036752AbdDUIcW (ORCPT ); Fri, 21 Apr 2017 04:32:22 -0400 Received: from mail-io0-f195.google.com ([209.85.223.195]:33731 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1036739AbdDUIcO (ORCPT ); Fri, 21 Apr 2017 04:32:14 -0400 Received: by mail-io0-f195.google.com with SMTP id k87so27583625ioi.0; Fri, 21 Apr 2017 01:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=ks42Kjl/A7efhlnzQyjq10zbRKJ7aC3+pZRcVC+sxnE=; b=bLdUTtFfPyreAaFvVBCNH3Qspf+kiQo95U2ZXtqchiB0SMDOzP+eZoeclGsDzSdv8b eB7FVoLwdoiHOnLfHyJu1bo2DJNWmmIkTbVdqTzRaJsWScoLoIsN1ubtTuDO0QWriDtm SaItJbbtoMAgz+98vxGZzekYzmdlDrar7obYADR/rEQBVUZdq1FAE0WFQtwQxIQSpSPD 01IClCBmSsN/NpcDEh9qYL8BsNggv/Kk0OXP2WMyd6MBPukcN5nIogYQ/YMe3VHJLHsw NEIZtnqKtf56vVggAiUqyYj3ZdpGkIHpRMe4uPf7NaMb7z5yamq13dVHuU0cVLTJyXEx TFVg== 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:in-reply-to :references; bh=ks42Kjl/A7efhlnzQyjq10zbRKJ7aC3+pZRcVC+sxnE=; b=jv8bMBnc7fH+d4myb9Koo78mNhTbwRT69ro8LyRT8V+5gHHEGvc0NjvyER1Ke2Lf4h lEgFCs6rwV12mEdxCbrXQtPUHLgi9otfkF3QJndd0X6amzviC1qn5HGPXm6Q5f7NZcwM XckbCHR9eA05ZozCJ5Ib91MC2woQfBnnjfxuIdvw8mDKhLATputoAlrC13MCwvUGAlJ6 ceJadOVVotm2yod5nZjarr1D9zEIyT5qVOFHjLER5JRftpJpGf+Mm0PZynUPNzslCSk0 rw/l6e7o8wd+YDBV4MEEkmE+EdSMwxL1UyDDt+QSYXTP12LJmOj9oGxwtioC07Q3cxd1 yMSw== X-Gm-Message-State: AN3rC/79qaiN3sdpLwWg5SQ4j1CzzKI/hwUbJ6xWixgF1RFPncwlVpJg UHMayXD4nxPbRg== X-Received: by 10.98.215.94 with SMTP id v30mr11225907pfl.121.1492763532782; Fri, 21 Apr 2017 01:32:12 -0700 (PDT) Received: from localhost.localdomain (c-73-239-167-150.hsd1.wa.comcast.net. [73.239.167.150]) by smtp.gmail.com with ESMTPSA id m187sm14593981pfm.122.2017.04.21.01.32.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 01:32:12 -0700 (PDT) From: Eric Biggers To: keyrings@vger.kernel.org Cc: linux-security-module@vger.kernel.org, David Howells , linux-kernel@vger.kernel.org, Eric Biggers Subject: [PATCH 5/5] KEYS: sanitize key structs before freeing Date: Fri, 21 Apr 2017 01:30:37 -0700 Message-Id: <20170421083037.12746-6-ebiggers3@gmail.com> X-Mailer: git-send-email 2.12.2 In-Reply-To: <20170421083037.12746-1-ebiggers3@gmail.com> References: <20170421083037.12746-1-ebiggers3@gmail.com> Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: X-Virus-Scanned: ClamAV using ClamSMTP From: Eric Biggers While a 'struct key' itself normally does not contain sensitive information, Documentation/security/keys.txt actually encourages this: "Having a payload is not required; and the payload can, in fact, just be a value stored in the struct key itself." In case someone has taken this advice, or will take this advice in the future, zero the key structure before freeing it. We might as well, and as a bonus this could make it a bit more difficult for an adversary to determine which keys have recently been in use. This is safe because the key_jar cache does not use a constructor. Signed-off-by: Eric Biggers --- include/linux/key.h | 1 - security/keys/gc.c | 4 +--- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/include/linux/key.h b/include/linux/key.h index 0c9b93b0d1f7..78e25aabedaf 100644 --- a/include/linux/key.h +++ b/include/linux/key.h @@ -173,7 +173,6 @@ struct key { #ifdef KEY_DEBUGGING unsigned magic; #define KEY_DEBUG_MAGIC 0x18273645u -#define KEY_DEBUG_MAGIC_X 0xf8e9dacbu #endif unsigned long flags; /* status flags (change with bitops) */ diff --git a/security/keys/gc.c b/security/keys/gc.c index 15b9ddf510e4..5233c073d982 100644 --- a/security/keys/gc.c +++ b/security/keys/gc.c @@ -158,9 +158,7 @@ static noinline void key_gc_unused_keys(struct list_head *keys) kfree(key->description); -#ifdef KEY_DEBUGGING - key->magic = KEY_DEBUG_MAGIC_X; -#endif + memzero_explicit(key, sizeof(*key)); kmem_cache_free(key_jar, key); } }