From patchwork Tue Jan 9 20:55:46 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 10153363 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 23063602CA for ; Tue, 9 Jan 2018 21:00:45 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1A1C52097A for ; Tue, 9 Jan 2018 21:00:45 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0DF2026224; Tue, 9 Jan 2018 21:00:45 +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 EFD1F26224 for ; Tue, 9 Jan 2018 21:00:43 +0000 (UTC) Received: (qmail 9488 invoked by uid 550); 9 Jan 2018 20:57:30 -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 8023 invoked from network); 9 Jan 2018 20:57:16 -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=J+XcHHVNOJAQb9tKM5ZC8hGOlYsu++RQBcLLYJMGa1I=; b=HwDSCzP2fF3047R81dt4oLUBEpLKBHPF8zE2uoUZTSyKZEKnmZAPatnMH0qpRhd4a0 xpLq2fbmV5od/baU30WcUEnKqw4JFua/JzIhA1J139IeHymCnNikCwknsDzpIMFVYT2e 9k/QqiNZWFuCqMmb+ngAnAottfV3yQyiAigNQ= 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=J+XcHHVNOJAQb9tKM5ZC8hGOlYsu++RQBcLLYJMGa1I=; b=HX3cHHTKUhJVhWb0kCTXulUYXCFG6Gy1C4HlEUlit6HWaLFqw8bJmWLDBWA4LGdnXx 2tywJVAurzFFFAeY5qUgOiUqkp/i/jUQfxgmnIjuUG+yQ0Oy6qSkGzG3qzVs3Bc0gOyU pujdfrW0FwvEfpTLIgHR6Lyv4Xw5QgLNnL7TElsC3266vos9tGZ/nAaTF3zxNNOlMufw DImnyH6ADMUDR9XmV6FJ+bFz/w9Yg9G2kBeID+4tO7O0OenHL2IxmiyWF+SqrhOhe/F7 9e1Ke/xxdjVTZE11BmnBRTKKpwapyxfD7T2/XruplVN5J0Z9ExJFbGssmlmn0Ogj98j9 49jw== X-Gm-Message-State: AKGB3mJmCBuJ/gbNfHiA8Gal1QV5L+QzBLW0VcLh4oZtpGUz7lNK5gY2 mc5zfb1JgzcJcTcXSR+1gdjmDg== X-Google-Smtp-Source: ACJfBou6ryGX7yzz1uAiA5Uif5ulKJQF8LaFT7zd8o+2RcirfyVWmvgz0PTFDGeQSQ+7mpHJITLRUw== X-Received: by 10.84.133.226 with SMTP id f89mr16496267plf.407.1515531424571; Tue, 09 Jan 2018 12:57:04 -0800 (PST) From: Kees Cook To: linux-kernel@vger.kernel.org Cc: Kees Cook , David Windsor , Christoph Hellwig , Linus Torvalds , Alexander Viro , Andrew Morton , Andy Lutomirski , 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-fsdevel@vger.kernel.org, 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:46 -0800 Message-Id: <1515531365-37423-18-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 17/36] vxfs: Define usercopy region in vxfs_inode slab cache X-Virus-Scanned: ClamAV using ClamSMTP From: David Windsor vxfs symlink pathnames, stored in struct vxfs_inode_info field vii_immed.vi_immed and therefore contained in the vxfs_inode slab cache, need to be copied to/from userspace. cache object allocation: fs/freevxfs/vxfs_super.c: vxfs_alloc_inode(...): ... vi = kmem_cache_alloc(vxfs_inode_cachep, GFP_KERNEL); ... return &vi->vfs_inode; fs/freevxfs/vxfs_inode.c: cxfs_iget(...): ... inode->i_link = vip->vii_immed.vi_immed; 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 vxfs_inode 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 dynamically sized 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: Christoph Hellwig Signed-off-by: Kees Cook --- fs/freevxfs/vxfs_super.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/freevxfs/vxfs_super.c b/fs/freevxfs/vxfs_super.c index f989efa051a0..48b24bb50d02 100644 --- a/fs/freevxfs/vxfs_super.c +++ b/fs/freevxfs/vxfs_super.c @@ -332,9 +332,13 @@ vxfs_init(void) { int rv; - vxfs_inode_cachep = kmem_cache_create("vxfs_inode", + vxfs_inode_cachep = kmem_cache_create_usercopy("vxfs_inode", sizeof(struct vxfs_inode_info), 0, - SLAB_RECLAIM_ACCOUNT|SLAB_MEM_SPREAD, NULL); + SLAB_RECLAIM_ACCOUNT|SLAB_MEM_SPREAD, + offsetof(struct vxfs_inode_info, vii_immed.vi_immed), + sizeof_field(struct vxfs_inode_info, + vii_immed.vi_immed), + NULL); if (!vxfs_inode_cachep) return -ENOMEM; rv = register_filesystem(&vxfs_fs_type);