From patchwork Tue Jan 9 20:55:36 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 10153445 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 372C560223 for ; Tue, 9 Jan 2018 21:05:29 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2E25C2040D for ; Tue, 9 Jan 2018 21:05:29 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 206902434C; Tue, 9 Jan 2018 21:05:29 +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=-2.4 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED, T_DKIM_INVALID, URIBL_BLACK 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 12FD42040D for ; Tue, 9 Jan 2018 21:05:27 +0000 (UTC) Received: (qmail 11407 invoked by uid 550); 9 Jan 2018 20:57:59 -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 9570 invoked from network); 9 Jan 2018 20:57:32 -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=tSYhrcy/CkL5mToN++XEZZoZ5fVb+0b1X+bWqCwu4eM=; b=ka0QUISdddTINTZxD2HBwfvTXR3CsCeGSMumkOkEGABj6zprXGWr/1aIiM9Md5OOdO Rn+RVreJJdoK98QSy38ek/pWGCRzAiUSlJ6kRt2bJkUOK0s4TcyLIJkVDhQyR+CPbMfr 7ifKRCzlSmuP/hI4/VKm0yGjWL8kKU6TfywYI= 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=tSYhrcy/CkL5mToN++XEZZoZ5fVb+0b1X+bWqCwu4eM=; b=YX0KoAvL1GcN5ZsFI+6JnFQU2WimjLnEkCNzbOrOEZICTQAqF8o9TIY8HOb04sBepj mBuIhPlwaFcVI4X9G1zxBtIu/WTL8jUCCf3oHefhnP2IPq0KmYuXw3ypPmiFzDiyr3Hg aqSs1xq0CTb1YPB7nq2+HRhC8WJpv6rSSI6KbhWrtdm58tsud47NxXjiCWb268dro3zj HLPHWU9s44mDhC6qrb3VgE6ynsMRqoVAcmehz3iph7ktWp2+cQgyUWTqRMg6l1c6jitk aSYZDGbPlfxwnJ5nW+lATYQaSXZVotOYLJE3b+ictNIXFQWg4Ikgra9uGaYWXCbne5C+ VxeA== X-Gm-Message-State: AKGB3mLEISJzu/2garqmRvi9ddjdV3YPsphvpMhV6y925Xxrbi/OtBAi /uqyZ7KedCQHk1/Zs7oAtd/1SQ== X-Google-Smtp-Source: ACJfBouH3U8MinPJAxsOVTol0MtL3/aum+z66YFJ1sMSIocXodRXyycAcVMeGxDSB+cvvh/CGjFJkA== X-Received: by 10.101.75.73 with SMTP id k9mr13457545pgt.335.1515531441092; Tue, 09 Jan 2018 12:57:21 -0800 (PST) From: Kees Cook To: linux-kernel@vger.kernel.org Cc: Kees Cook , David Windsor , Alexander Viro , linux-fsdevel@vger.kernel.org, Linus Torvalds , Andrew Morton , Andy Lutomirski , Christoph Hellwig , Christoph Lameter , "David S. Miller" , Laura Abbott , Mark Rutland , "Martin K. Petersen" , Paolo Bonzini , Christian Borntraeger , Christoffer Dall , Dave Kleikamp , Jan Kara , Luis de Bethencourt , Marc Zyngier , Rik van Riel , Matthew Garrett , linux-arch@vger.kernel.org, netdev@vger.kernel.org, linux-mm@kvack.org, kernel-hardening@lists.openwall.com Date: Tue, 9 Jan 2018 12:55:36 -0800 Message-Id: <1515531365-37423-8-git-send-email-keescook@chromium.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1515531365-37423-1-git-send-email-keescook@chromium.org> References: <1515531365-37423-1-git-send-email-keescook@chromium.org> Subject: [kernel-hardening] [PATCH 07/36] 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 dynamic 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 5c7df1df81ff..92ad7a2168e1 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -3601,8 +3601,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)