From patchwork Fri May 26 17:37:34 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Rutland X-Patchwork-Id: 100581 Delivered-To: patch@linaro.org Received: by 10.140.96.100 with SMTP id j91csp362673qge; Fri, 26 May 2017 10:39:46 -0700 (PDT) X-Received: by 10.84.140.164 with SMTP id 33mr59213669plt.142.1495820386044; Fri, 26 May 2017 10:39:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1495820386; cv=none; d=google.com; s=arc-20160816; b=yOGCWXlmd4nBnpkAIsgMXLgFdozsOXxmH56oCZylZD73zHPR31+K/Hd7tSLJXpITvQ mEtlANgl27eY+nPUjT2qIeY/EM4fFWsMldFgUmr26hbvMf/TlqdquD1H9WCo873vhMso MoBle2jjft7DDw5ChVrLrihYpfBJ6uNwS/CeP3kvGvAmNyuuPeNMzEHuVaibaQ8YVOS2 AIxOmcsvB57g8Vb5RT9v/y2WpkiUZXCqGyNMKET++iolvkiro4JclSs+OgwZCBO2Vh95 TmJ8PeusUJ02xcU5+RLGdyeLmK/DLQVX2R9sBVkchkbjPtzZvnYAt2jXCBaVsTx+NXHS IpCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=BaS8iV8Kf3DqITZG8QPv8+Gtkd0GMFif8ZWGuRTYT6c=; b=IA6CpbaECnbDnI3jz7X4WMsMVmcUBqfJd6ZXbDufduJUsE/7jYbFXAFrfa7K4aAwht i2YYwbWwOGqF8+PQCUzuqe252ifdPwUayW44pf4kJJ/hurcgxhLhW/ENEqFG9yDUzL7O WadSmVhkmmO9wiNHX5JZRQSItm3vpuL+3takY1R197m1bTMyHaVq/akNjgemD+wYRtAn wq5HWyNo1tJjkAG2Wx5ZA2We90QN/l3mgwgGBPeZo0Mx32nH5lOX6EeX6MI1wLQSzixT JJRdvB6uiHiT8pllMhxhzkXBVtVmBj78ZejnH7gt1QkDRx9emevG0IM73/LtxyHvkehP HIfA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 30si33696674plc.155.2017.05.26.10.39.45; Fri, 26 May 2017 10:39:46 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1948490AbdEZRjO (ORCPT + 25 others); Fri, 26 May 2017 13:39:14 -0400 Received: from foss.arm.com ([217.140.101.70]:34638 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753169AbdEZRiS (ORCPT ); Fri, 26 May 2017 13:38:18 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 266CB80D; Fri, 26 May 2017 10:38:17 -0700 (PDT) Received: from leverpostej.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 4E15A3F53D; Fri, 26 May 2017 10:38:15 -0700 (PDT) From: Mark Rutland To: dhowells@redhat.com Cc: keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Mark Rutland , David Windsor , Elena Reshetova , Hans Liljestrand , James Morris , Kees Cook , Peter Zijlstra Subject: [PATCH] KEYS: fix refcount_inc() on zero Date: Fri, 26 May 2017 18:37:34 +0100 Message-Id: <1495820254-6651-1-git-send-email-mark.rutland@arm.com> X-Mailer: git-send-email 1.9.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If a key's refcount is dropped to zero between key_lookup() peeking at the refcount and subsequently attempting to increment it, refcount_inc() will see a zero refcount. Here, refcount_inc() will WARN_ONCE(), and will *not* increment the refcount, which will remain zero. Once key_lookup() drops key_serial_lock, it is possible for the key to be freed behind our back. This patch uses refcount_inc_not_zero() to perform the peek and increment atomically. A helper with lockdep annotation is added to document why this is safe. Fixes: fff292914d3a2f1e ("security, keys: convert key.usage from atomic_t to refcount_t") Signed-off-by: Mark Rutland Cc: David Howells Cc: David Windsor Cc: Elena Reshetova Cc: Hans Liljestrand Cc: James Morris Cc: Kees Cook Cc: Peter Zijlstra --- security/keys/key.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) -- 1.9.1 Reviewed-by: Kees Cook diff --git a/security/keys/key.c b/security/keys/key.c index 455c04d..150f51d 100644 --- a/security/keys/key.c +++ b/security/keys/key.c @@ -632,6 +632,12 @@ void key_put(struct key *key) } EXPORT_SYMBOL(key_put); +static bool key_get_not_free(struct key *key) +{ + lockdep_assert_held(&key_serial_lock); + return refcount_inc_not_zero(&key->usage); +} + /* * Find a key by its serial number. */ @@ -660,14 +666,12 @@ struct key *key_lookup(key_serial_t id) goto error; found: - /* pretend it doesn't exist if it is awaiting deletion */ - if (refcount_read(&key->usage) == 0) - goto not_found; - - /* this races with key_put(), but that doesn't matter since key_put() - * doesn't actually change the key + /* + * Pretend it doesn't exist if it is awaiting deletion. This races with + * key_put(), but we can peek at the key until we drop key_serial_lock. */ - __key_get(key); + if (!key_get_not_free(key)) + goto not_found; error: spin_unlock(&key_serial_lock);