From patchwork Wed Sep 20 20:45:10 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 9962397 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 5CAD760234 for ; Wed, 20 Sep 2017 20:46:13 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5002129227 for ; Wed, 20 Sep 2017 20:46:13 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 44CD52922A; Wed, 20 Sep 2017 20:46:13 +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.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID 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 3F8E329227 for ; Wed, 20 Sep 2017 20:46:11 +0000 (UTC) Received: (qmail 1962 invoked by uid 550); 20 Sep 2017 20:46:09 -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 1923 invoked from network); 20 Sep 2017 20:46:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=AItuPkxoXP2lQMo2mwVBJC43AWaOTOyiRxkn5bbYjPo=; b=aDvAvQ1SkZDGOJoKFajT7ucBgLpCSyAEM1GVYDpk9EiYwozOjHJf/Xah/pcvkTbuDE Irk28pRpF3CruIXTkLfZvixIh9dEbOmQcrBPX50oysuUEfbvgznnH/L7RlM2+TBueAv9 4N85YzvLW1rzVR636P4DvtgGBeojP76B4LWQs= 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=AItuPkxoXP2lQMo2mwVBJC43AWaOTOyiRxkn5bbYjPo=; b=s3S3QAtYsJhFyIHbogkIu/2UmG0tIBwTEq5TZxKKYBKmh9UN06l4jyvG0/uH6gN6CA ShAiuLKXGxIMMrqJm1CykcQVtIbzMkXtLWSRSQg6FhDWT0p0QFiXeDH+FavE+eWoBXDj FhxFyZVdvlwT43TdTrZWrIH8GZUKXmXjYdD1k7R8AiBA4ZLaITu3gKTvyQi/IoXL2gso WGkB+j88ULAXiwvEZIUQUXW1NaN/m9YsrenI8g93jvhhsHsGFXVFT6X85UgDiYiMUcPK FIy+GzJzRFv3mSz2d+zIDjXN6dZetcl7tI2mnWz7TOG8pHTZNgus1HbgVJFWg3Ufc44j zCtw== X-Gm-Message-State: AHPjjUgqe7IkXzZBUQhI1a/y+y3Cn5lkq/1gdpyIJvQ0Cfrqtn4x3okR 5uUHs9+6XgR8IJKKmkIT2hX8mg== X-Google-Smtp-Source: AOwi7QDbpkm9vl3CE7hQ/RcbWT8LJgDOcR21yLCjyMYy4jx0MyRy+XPcYxPO22PAAvc9fdu3cA+7Cw== X-Received: by 10.84.252.130 with SMTP id y2mr3175583pll.68.1505940356706; Wed, 20 Sep 2017 13:45:56 -0700 (PDT) From: Kees Cook To: linux-kernel@vger.kernel.org Cc: Kees Cook , David Windsor , Alexander Viro , linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org, linux-mm@kvack.org, kernel-hardening@lists.openwall.com Date: Wed, 20 Sep 2017 13:45:10 -0700 Message-Id: <1505940337-79069-5-git-send-email-keescook@chromium.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1505940337-79069-1-git-send-email-keescook@chromium.org> References: <1505940337-79069-1-git-send-email-keescook@chromium.org> Subject: [kernel-hardening] [PATCH v3 04/31] dcache: Define usercopy region in dentry_cache slab cache X-Virus-Scanned: ClamAV using ClamSMTP From: David Windsor When a dentry name is short enough, it can be stored directly in the dentry itself (instead in a separate kmalloc allocation). These dentry short names, stored in struct dentry.d_iname and therefore contained in the dentry_cache slab cache, need to be coped to userspace. cache object allocation: fs/dcache.c: __d_alloc(...): ... dentry = kmem_cache_alloc(dentry_cache, ...); ... dentry->d_name.name = dentry->d_iname; example usage trace: filldir+0xb0/0x140 dcache_readdir+0x82/0x170 iterate_dir+0x142/0x1b0 SyS_getdents+0xb5/0x160 fs/readdir.c: (called via ctx.actor by dir_emit) filldir(..., const char *name, ...): ... copy_to_user(..., name, namlen) fs/libfs.c: dcache_readdir(...): ... next = next_positive(dentry, p, 1) ... dir_emit(..., next->d_name.name, ...) In support of usercopy hardening, this patch defines a region in the dentry_cache slab cache in which userspace copy operations are allowed. This region is known as the slab cache's usercopy region. Slab caches can now check that each copy operation involving cache-managed memory falls entirely within the slab's usercopy region. This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY whitelisting code in the last public patch of grsecurity/PaX based on my understanding of the code. Changes or omissions from the original code are mine and don't reflect the original grsecurity/PaX code. Signed-off-by: David Windsor [kees: adjust hunks for kmalloc-specific things moved later] [kees: adjust commit log, provide usage trace] Cc: Alexander Viro Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Kees Cook --- fs/dcache.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index f90141387f01..5f5e7c1fcf4b 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -3603,8 +3603,9 @@ static void __init dcache_init(void) * but it is probably not worth it because of the cache nature * of the dcache. */ - dentry_cache = KMEM_CACHE(dentry, - SLAB_RECLAIM_ACCOUNT|SLAB_PANIC|SLAB_MEM_SPREAD|SLAB_ACCOUNT); + dentry_cache = KMEM_CACHE_USERCOPY(dentry, + SLAB_RECLAIM_ACCOUNT|SLAB_PANIC|SLAB_MEM_SPREAD|SLAB_ACCOUNT, + d_iname); /* Hash may have been set up in dcache_init_early */ if (!hashdist)