From patchwork Thu Oct 26 20:57:44 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 10028789 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 79D6C601E8 for ; Thu, 26 Oct 2017 20:58:15 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6B7B128ECD for ; Thu, 26 Oct 2017 20:58:15 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6029828ED3; Thu, 26 Oct 2017 20:58:15 +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 3B58028ECD for ; Thu, 26 Oct 2017 20:58:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751933AbdJZU6N (ORCPT ); Thu, 26 Oct 2017 16:58:13 -0400 Received: from mail-io0-f196.google.com ([209.85.223.196]:51449 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751651AbdJZU6L (ORCPT ); Thu, 26 Oct 2017 16:58:11 -0400 Received: by mail-io0-f196.google.com with SMTP id b186so8339423iof.8; Thu, 26 Oct 2017 13:58:11 -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; bh=6AsZ8Ffl1riTjvA/Q7KUrWSyjrk4+f9YUxnq/GEaIxs=; b=sNOE+o2YWESB3SdiCuHdrn+5z/m5Tq+cQT8ZSG2rL1mTzznGuSwxXBwmz0ke1711pT AvpOThDP5sVYBoz3eDocY1H9fv1lbWunVfLvniX/M2CExYDsh0tBnIbbRQz3o/eGLadO sGcPUMHlYgDuiP2CiKENfLAfzp1SqhdrTvQyI4Eakd6XsJzWWR3vmkzAtQ8axmRGUjb7 vd4vLkiJczPxtDUrFm8DI1joyWjekepYFiO9L/HQyjMF9HaqGGRKgaHcRor+qEbMm0wl VbaiFnwWl2CxoALhAogQqhBuFkEPiFzF0wrQR7jqaJDwwxcKvMSmNwC7NKcQ3kFHK36h 2k2Q== 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=6AsZ8Ffl1riTjvA/Q7KUrWSyjrk4+f9YUxnq/GEaIxs=; b=EfhR0kG7noldPBpV3EuczVoeUKK9qdf5lrAsqLdrAqe3wj5kxrha/6sl1JOPYoxYw2 ueHkJKPQDV0frc5SjgZAp2MJU5eMA56YMf+vf09cI2jQGcuc5JEkws19JUhK11VoEjD0 n/Nxz0Xu6UgTJwjBAvuZjneGT73qSY5C9/poJj+KPuvjETVXToaboXIK7WaJobaa3zTV uX6jQrkg5EnCJzco6cP5H2QZhCBYCM9FZw9BkZAO90kTVNIJOhECmDe66cUyabUIbQVK 75NYchHDb5G8gjzzWa2cev2VJf+4kRoX0Nu1P4gbuFoLI2cSQCNYtVUthPh/nkahxxd/ 6qBg== X-Gm-Message-State: AMCzsaWE82pwZXh/zKL4ED1/2jfNeinqoNbHRpXn8lYxEm35Uo63XtWW 8mm/9TCK2kzizYvA+nYXI/6Mzd9H X-Google-Smtp-Source: ABhQp+SX8XGy3gwAulzYkgJvL1tTEG6FBZN2O/1WQwegNEX9PEnxi/bmJo8hJYyXBrbGQvni0Kxhyg== X-Received: by 10.36.69.100 with SMTP id y97mr399497ita.50.1509051490707; Thu, 26 Oct 2017 13:58:10 -0700 (PDT) Received: from ebiggers-linuxstation.kir.corp.google.com ([100.66.175.88]) by smtp.gmail.com with ESMTPSA id u188sm96441itb.2.2017.10.26.13.58.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 26 Oct 2017 13:58:10 -0700 (PDT) From: Eric Biggers To: keyrings@vger.kernel.org Cc: David Howells , Ben Hutchings , Xiao Yang , David Safford , Mimi Zohar , linux-security-module@vger.kernel.org, Eric Biggers , stable@vger.kernel.org Subject: [PATCH] KEYS: trusted: fix writing past end of buffer in trusted_read() Date: Thu, 26 Oct 2017 13:57:44 -0700 Message-Id: <20171026205744.105566-1-ebiggers3@gmail.com> X-Mailer: git-send-email 2.15.0.rc2.357.g7e34df9404-goog Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: X-Virus-Scanned: ClamAV using ClamSMTP From: Eric Biggers When calling keyctl_read() on a key of type "trusted", if the user-supplied buffer was too small, the kernel ignored the buffer length and just wrote past the end of the buffer, potentially corrupting userspace memory. Fix it by instead returning the size required, as per the documentation for keyctl_read(). We also don't even fill the buffer at all in this case, as this is slightly easier to implement than doing a short read, and either behavior appears to be permitted. It also makes it match the behavior of the "encrypted" key type. Fixes: d00a1c72f7f4 ("keys: add new trusted key-type") Reported-by: Ben Hutchings Cc: # v2.6.38+ Signed-off-by: Eric Biggers Reviewed-by: Mimi Zohar Reviewed-by: James Morris --- security/keys/trusted.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/security/keys/trusted.c b/security/keys/trusted.c index bd85315cbfeb..98aa89ff7bfd 100644 --- a/security/keys/trusted.c +++ b/security/keys/trusted.c @@ -1147,20 +1147,21 @@ static long trusted_read(const struct key *key, char __user *buffer, p = dereference_key_locked(key); if (!p) return -EINVAL; - if (!buffer || buflen <= 0) - return 2 * p->blob_len; - ascii_buf = kmalloc(2 * p->blob_len, GFP_KERNEL); - if (!ascii_buf) - return -ENOMEM; - bufp = ascii_buf; - for (i = 0; i < p->blob_len; i++) - bufp = hex_byte_pack(bufp, p->blob[i]); - if ((copy_to_user(buffer, ascii_buf, 2 * p->blob_len)) != 0) { + if (buffer && buflen >= 2 * p->blob_len) { + ascii_buf = kmalloc(2 * p->blob_len, GFP_KERNEL); + if (!ascii_buf) + return -ENOMEM; + + bufp = ascii_buf; + for (i = 0; i < p->blob_len; i++) + bufp = hex_byte_pack(bufp, p->blob[i]); + if (copy_to_user(buffer, ascii_buf, 2 * p->blob_len) != 0) { + kzfree(ascii_buf); + return -EFAULT; + } kzfree(ascii_buf); - return -EFAULT; } - kzfree(ascii_buf); return 2 * p->blob_len; }