From patchwork Mon Aug 28 21:34:55 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 9926323 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 190E860375 for ; Mon, 28 Aug 2017 21:44:38 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0D1F9283C7 for ; Mon, 28 Aug 2017 21:44:38 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 01E682855D; Mon, 28 Aug 2017 21:44:37 +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 ED137283C7 for ; Mon, 28 Aug 2017 21:44:36 +0000 (UTC) Received: (qmail 9438 invoked by uid 550); 28 Aug 2017 21:44:06 -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 8139 invoked from network); 28 Aug 2017 21:44:04 -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=DaDd4yc4IlPMUJsl+NYmyankzTRdIIRePDn0+bmi6SI=; b=SCajBdG2ftRTfWpx1FIUwPUR+ULDNHzV169DipELyURHxiKHOxgJGrLnWLbPPIjZir lpllGON3+l3L7IH9pEVA9zUXHYK8waK+u5YK0/lYOvOQoRy2reGyTeM6Tj1lz++sii8T vdNCKWoxf/6Z/h91PiLZWTIneGJn/1XqlkoA8= 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=DaDd4yc4IlPMUJsl+NYmyankzTRdIIRePDn0+bmi6SI=; b=cXiVaQxRzoHDt5xCYLWUzeee0+3utLKfITfUufqab5SkUDET3f+n34VptwGDjG2c7+ ll252VkZl2/PtZ7/dd9CY3D0te8dh1EozktoHVisCN4E7yqFnbOlRumMDpxkBgCBXrw3 Z5EvDMuRPXa2bmN6AV/nd0jzZdkUECXqQMUEascB0BandyhW27kQZKD2lqn2dvUbMyMC 8/gWNVmZoTgfSgToBwPp6j5rMgZvkwb5YrONW7QxdKc7wSYhCeVckXyFybxViRpP3hw8 qi4eWk1Fbz2LtFj6KENiXGk8HBaH45UYXy0jeDwCteH/iqHbn0RcGws5mgTN6ZL15TyG zYSw== X-Gm-Message-State: AHYfb5gzBinDi4VbCWZ5acJIX01Basgd9yHV/Axx6bQToJyLgyVguB19 H0G7vqA00MH9x7eh X-Received: by 10.99.5.18 with SMTP id 18mr1831898pgf.245.1503956632405; Mon, 28 Aug 2017 14:43:52 -0700 (PDT) From: Kees Cook To: linux-kernel@vger.kernel.org Cc: Kees Cook , David Windsor , Christoph Hellwig , linux-mm@kvack.org, kernel-hardening@lists.openwall.com Date: Mon, 28 Aug 2017 14:34:55 -0700 Message-Id: <1503956111-36652-15-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 14/30] 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 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 455ce5b77e9b..c143e18d5a65 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);