From patchwork Wed Sep 20 20:45:22 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 9962461 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 A74EC60208 for ; Wed, 20 Sep 2017 20:49:13 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9AC3A29226 for ; Wed, 20 Sep 2017 20:49:13 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8F69B29229; Wed, 20 Sep 2017 20:49: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=-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 913AB29226 for ; Wed, 20 Sep 2017 20:49:12 +0000 (UTC) Received: (qmail 5125 invoked by uid 550); 20 Sep 2017 20:46:34 -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 3750 invoked from network); 20 Sep 2017 20:46:26 -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=ErIxzF/Xu/2NZZKnHLK0hzq0ZrhO56rwZ77Q2c+O7Y8=; b=a0KHLHewgT3WMj4ycgRnE/k4/SnM1DN8iHVua9lmyyHKvZ0A41xXzJ4aN8Zybd+z9B voMVpMmg5CmTprSBa456YJEm+i4GnjCaLuVcs5pvUjdiZROiM9dEYXNVnBr3S1PXpSEm dmEo6KYNAY9j7H0b5BbXlxAwUPpYZRoPf7sNE= 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=ErIxzF/Xu/2NZZKnHLK0hzq0ZrhO56rwZ77Q2c+O7Y8=; b=cPVnlWcoza/Ovrz5a5vBwlTOm6Jyjpj3b2Km7St2HPQ7T3D7cckW9O2NBB9diXWWHA 7fTIu3/3wB6P+H4kGDp9q+e3mmTVL65ajvYsRFLx8n6RLwSSJMrflKtermbnb6GmVU6I dnNmnYG3V4VPAf2bKqs8TDZL2KZacg0F1sRxMYCW8QW3gglkPdzbTr2ccPIqjxeQOanG gCEDE+q6cZqBLL+pEQwC7r77kSzzf852oWyQHITM/I6QQzK49RmGXzx1J+eCDZFT0GKU KsaOMzoCLyx1EC7kzN4KNjO3FiVkGUwAK9h92GMZQPsVJWT7+nfjRrA740LDQx822c6U Ah7g== X-Gm-Message-State: AHPjjUji/2xCyGuTviD4tM1jVT/dmM2ggbBhYnwXkjikztsDFrVwF6Wl raRASnQewJPJqDvYDkAFVnLezQ== X-Google-Smtp-Source: AOwi7QC3SBQuv5ScYeh+3sjLv1sAEPGXdjl2npvnYqsvYMcxH4GB0t5MmaaOjcYnGDvYZKxczcEhFg== X-Received: by 10.84.248.144 with SMTP id q16mr3313921pll.345.1505940374877; Wed, 20 Sep 2017 13:46:14 -0700 (PDT) From: Kees Cook To: linux-kernel@vger.kernel.org Cc: Kees Cook , David Windsor , Steve French , linux-cifs@vger.kernel.org, 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:22 -0700 Message-Id: <1505940337-79069-17-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 16/31] cifs: Define usercopy region in cifs_request slab cache X-Virus-Scanned: ClamAV using ClamSMTP From: David Windsor CIFS request buffers, stored in the cifs_request slab cache, need to be copied to/from userspace. cache object allocation: fs/cifs/cifsfs.c: cifs_init_request_bufs(): ... cifs_req_poolp = mempool_create_slab_pool(cifs_min_rcv, cifs_req_cachep); fs/cifs/misc.c: cifs_buf_get(): ... ret_buf = mempool_alloc(cifs_req_poolp, GFP_NOFS); ... return ret_buf; In support of usercopy hardening, this patch defines a region in the cifs_request 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 verbatim 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: Steve French Cc: linux-cifs@vger.kernel.org Signed-off-by: Kees Cook --- I wasn't able to actually track down the _usage_ of the cifs_request where it is copied to userspace. If any CIFS folks could help point that out, it would be very welcome. :) I suspect it might be part of the debug routines, but I never managed to exercise them. --- fs/cifs/cifsfs.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c index 180b3356ff86..09dfdf76c738 100644 --- a/fs/cifs/cifsfs.c +++ b/fs/cifs/cifsfs.c @@ -1229,9 +1229,11 @@ cifs_init_request_bufs(void) cifs_dbg(VFS, "CIFSMaxBufSize %d 0x%x\n", CIFSMaxBufSize, CIFSMaxBufSize); */ - cifs_req_cachep = kmem_cache_create("cifs_request", + cifs_req_cachep = kmem_cache_create_usercopy("cifs_request", CIFSMaxBufSize + max_hdr_size, 0, - SLAB_HWCACHE_ALIGN, NULL); + SLAB_HWCACHE_ALIGN, 0, + CIFSMaxBufSize + max_hdr_size, + NULL); if (cifs_req_cachep == NULL) return -ENOMEM; @@ -1257,9 +1259,9 @@ cifs_init_request_bufs(void) more SMBs to use small buffer alloc and is still much more efficient to alloc 1 per page off the slab compared to 17K (5page) alloc of large cifs buffers even when page debugging is on */ - cifs_sm_req_cachep = kmem_cache_create("cifs_small_rq", + cifs_sm_req_cachep = kmem_cache_create_usercopy("cifs_small_rq", MAX_CIFS_SMALL_BUFFER_SIZE, 0, SLAB_HWCACHE_ALIGN, - NULL); + 0, MAX_CIFS_SMALL_BUFFER_SIZE, NULL); if (cifs_sm_req_cachep == NULL) { mempool_destroy(cifs_req_poolp); kmem_cache_destroy(cifs_req_cachep);