From patchwork Mon Aug 28 21:34:50 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 9926259 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 0E07B603B4 for ; Mon, 28 Aug 2017 21:37:56 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 01AE6287DA for ; Mon, 28 Aug 2017 21:37:56 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EACA1287E9; Mon, 28 Aug 2017 21:37:55 +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 E9D19287E0 for ; Mon, 28 Aug 2017 21:37:54 +0000 (UTC) Received: (qmail 13355 invoked by uid 550); 28 Aug 2017 21:35:40 -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 12035 invoked from network); 28 Aug 2017 21:35:35 -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=7gWlyUzchCdA9QtL5rm5aDz4DvfWn/x/56DUhAQfhMw=; b=eWkBLeBGlcSM+1nBWqO0fMx/QKPY4SyUBuhbaKZW0ZdxWJ8+c5AuJ8x24WAKyHvweE yMSk7UaHDHLYwJdUUc5OCHiZL9sHbTgOvgO69MfYGDm+JCZ9q0PVAgISyE5wUJM9b0DU XtnpoSBV+9k0OCcrDuqhsEJhPPGf94ZWyy6zA= 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=7gWlyUzchCdA9QtL5rm5aDz4DvfWn/x/56DUhAQfhMw=; b=e0MqjprNbBxVD4rbFvsASjCRGxAHLw5ZRAIRfz50UOpPJ5x20UG3/GaHcLSTyc/ALU 7zyD0/6irhavuVLXK2D7tpNj2NMRiBbVAK3Wjx/FTXuQuDK3fcpLIdGEqdyI1d2dF0lu +oF8Hcys3QUfCDtd8U8yihT7hb3xW66jr4FBWtCilGvkY3sgq4oTA6W96LWl/E/+BCxu l3s7H/UtZqQUplU5cslzvCzOJshcdsmxgtAh0AflqN0lXVzAgR/PsVUEBX+N/v7dRQJR AWwSdtvFXlAQob/K8TJEYEH+pN77ena1VV3Omtw7Cs8+ReSoMTph2YsH80x+A94AR7hq DepQ== X-Gm-Message-State: AHYfb5hD3DVpQhoksh9wqd5DWFwKxtvLj1/q7GiLYJeFWj8YRQpfAig4 JB6gl4Pcx4D8/PBR X-Received: by 10.84.217.156 with SMTP id p28mr2464990pli.422.1503956123402; Mon, 28 Aug 2017 14:35:23 -0700 (PDT) From: Kees Cook To: linux-kernel@vger.kernel.org Cc: Kees Cook , David Windsor , Dave Kleikamp , jfs-discussion@lists.sourceforge.net, linux-mm@kvack.org, kernel-hardening@lists.openwall.com Date: Mon, 28 Aug 2017 14:34:50 -0700 Message-Id: <1503956111-36652-10-git-send-email-keescook@chromium.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1503956111-36652-1-git-send-email-keescook@chromium.org> References: <1503956111-36652-1-git-send-email-keescook@chromium.org> Subject: [kernel-hardening] [PATCH v2 09/30] jfs: Define usercopy region in jfs_ip slab cache X-Virus-Scanned: ClamAV using ClamSMTP From: David Windsor The jfs symlink pathnames, stored in struct jfs_inode_info.i_inline and therefore contained in the jfs_ip slab cache, need to be copied to/from userspace. cache object allocation: fs/jfs/super.c: jfs_alloc_inode(...): ... jfs_inode = kmem_cache_alloc(jfs_inode_cachep, GFP_NOFS); ... return &jfs_inode->vfs_inode; fs/jfs/jfs_incore.h: JFS_IP(struct inode *inode): return container_of(inode, struct jfs_inode_info, vfs_inode); fs/jfs/inode.c: jfs_iget(...): ... inode->i_link = JFS_IP(inode)->i_inline; example usage trace: readlink_copy+0x43/0x70 vfs_readlink+0x62/0x110 SyS_readlinkat+0x100/0x130 fs/namei.c: readlink_copy(..., link): ... copy_to_user(..., link, len); (inlined in vfs_readlink) generic_readlink(dentry, ...): struct inode *inode = d_inode(dentry); const char *link = inode->i_link; ... readlink_copy(..., link); In support of usercopy hardening, this patch defines a region in the jfs_ip 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 commit log, provide usage trace] Cc: Dave Kleikamp Cc: jfs-discussion@lists.sourceforge.net Signed-off-by: Kees Cook --- fs/jfs/super.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/fs/jfs/super.c b/fs/jfs/super.c index e8aad7d87b8c..10b958f49f57 100644 --- a/fs/jfs/super.c +++ b/fs/jfs/super.c @@ -972,9 +972,11 @@ static int __init init_jfs_fs(void) int rc; jfs_inode_cachep = - kmem_cache_create("jfs_ip", sizeof(struct jfs_inode_info), 0, - SLAB_RECLAIM_ACCOUNT|SLAB_MEM_SPREAD|SLAB_ACCOUNT, - init_once); + kmem_cache_create_usercopy("jfs_ip", sizeof(struct jfs_inode_info), + 0, SLAB_RECLAIM_ACCOUNT|SLAB_MEM_SPREAD|SLAB_ACCOUNT, + offsetof(struct jfs_inode_info, i_inline), + sizeof_field(struct jfs_inode_info, i_inline), + init_once); if (jfs_inode_cachep == NULL) return -ENOMEM;