Received: by 10.223.176.5 with SMTP id f5csp1340598wra; Wed, 7 Feb 2018 17:46:09 -0800 (PST) X-Google-Smtp-Source: AH8x226QPvVoNE9e2mNqsUXKGCPwB/s/qT/8fn1QORSf4ok6hBDUEe7XN5LqQ9RM8FSfdPjpA0cg X-Received: by 10.99.52.199 with SMTP id b190mr902740pga.40.1518054369253; Wed, 07 Feb 2018 17:46:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518054369; cv=none; d=google.com; s=arc-20160816; b=G5dS4Ep1Xe0+XFRon8DUFvJozPT3W6e0bW5UtNmnE56B0oIMluBalMXNj3Mmxvvdom adXRZXO9KulnMcGBoOJWfl99pJ0K1tY04LnF3l+VhyCYhe6dfnwiGdf0x1szJfhDhhcE 2IOtZ1BIkmfyhNdYFstYoiWvgrf6ki8fgVmO0mynodlYHcvPnW3hvW3Kgc6hMgwIe1z6 FboFYgbkxkXcuUTATEBE2ySo52EjD4gX1u68IowqHRvfzh6u1/4yezvEDuSNvdXBMz1O GlxYTW4VnVGrXQ+mnvTeh0y5g27uHqgJW7LCsZU99yQ/38MbH6GUafQdkoa672gfzTK4 kSmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition:mime-version :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=Qsu+Km5u+hE5+WRE+e8GummY0hk0+fhrohDWrdBEkVw=; b=TRgQt2BqJDeu2tMHZm3zOVloRDhSuaY3eEcFlXfcUZ26UDEpuhdXPeRkIYxkCYvCHR RWwTH2YATtcuvtk90N+rEZsn3zok3nz1M/7im+xmIZRWrUVufWxIk2t3qPhsg9L0nyWs 1+zaT8D+oOBoy8QhgEqzHbzjOuXdtYFtAoYoR7LY/Se+vI9T+GRyi1DwL8eq3dhFyDV+ sQOsjL/Jdd9ao+qm3Fdm5/0BUqiGVDUlExST9obXH7TWEKKWxSpXnOWJSZez4UvbUBpM KtUJduj2sLlqutVpiJzvikGXEV8nXQoO80swvi/hWGGVnMcwgJDLJlhQlaRhag5sZCiA Ab4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=l/onYSX6; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bd8-v6si1886588plb.3.2018.02.07.17.45.55; Wed, 07 Feb 2018 17:46:09 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=l/onYSX6; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752111AbeBHBoq (ORCPT + 99 others); Wed, 7 Feb 2018 20:44:46 -0500 Received: from mail-pf0-f193.google.com ([209.85.192.193]:45015 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751988AbeBHBol (ORCPT ); Wed, 7 Feb 2018 20:44:41 -0500 Received: by mail-pf0-f193.google.com with SMTP id 17so1146398pfw.11 for ; Wed, 07 Feb 2018 17:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:mime-version:content-disposition; bh=Qsu+Km5u+hE5+WRE+e8GummY0hk0+fhrohDWrdBEkVw=; b=l/onYSX60yBlYlhUNKTfKz9WUy2agmlF6zHJF7KxpiiljP49S7gorI23yDblx9bPQ/ e96dUpT0guC9onU6hy4CnNszQeYuAa0Me1wv6+tg7YAJ3pj2hAbE7Hmyo+IuiixrcUOe pi3nqhNwShdrn4gVhvfxWdlYDEYQhrk5/nlZ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition; bh=Qsu+Km5u+hE5+WRE+e8GummY0hk0+fhrohDWrdBEkVw=; b=C2bCfkHs5WQfwiTCi45Ok185Vds+jC8A/aV/15RzWRPM6Ovrr1YHXnJO7v8BtN6M0q yeJ/Fm7Ng2xZHzr5m0aW//Odr10BuIYNHXofxxh900P8FFQ2Z6GQTJcMo/yRqb3UiPEp +kUYQfMDEPMpCo+uv3lb75a+p0kYWTkVEcQFF8vSYGg1n9Aj13W/bJ0PZDgir2I2xu+l 1ju3odVNJLHe0gAxLau0uzh1ihV/F+InBpbNbL1B/gztcwRUcDG4JCYGmMv0D16Vjr5j G2Ed+RH+L8f+LJKV+ZyV1UHRFluyGLeytxQNXBo17mFVFOahFVE8yxk1gUE2FJJ4sUxK Ds3g== X-Gm-Message-State: APf1xPCS/K3IzU6/chOd4k7veVLheoorbhUDHbwnOUblqIDQcIHGr9CQ eSR2q7W/qg3d6HB6wJ+XoaYF8Q== X-Received: by 10.101.69.9 with SMTP id n9mr6619135pgq.317.1518054281087; Wed, 07 Feb 2018 17:44:41 -0800 (PST) Received: from www.outflux.net (173-164-112-133-Oregon.hfc.comcastbusiness.net. [173.164.112.133]) by smtp.gmail.com with ESMTPSA id l10sm5784565pff.64.2018.02.07.17.44.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 17:44:39 -0800 (PST) Date: Wed, 7 Feb 2018 17:44:38 -0800 From: Kees Cook To: David Miller Cc: syzbot+e2d6cfb305e9f3911dea@syzkaller.appspotmail.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, ebiggers3@gmail.com, james.morse@arm.com, keun-o.park@darkmatter.ae, labbott@redhat.com, linux-mm@kvack.org Subject: [PATCH] net: Whitelist the skbuff_head_cache "cb" field Message-ID: <20180208014438.GA12186@beast> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Most callers of put_cmsg() use a "sizeof(foo)" for the length argument. Within put_cmsg(), a copy_to_user() call is made with a dynamic size, as a result of the cmsg header calculations. This means that hardened usercopy will examine the copy, even though it was technically a fixed size and should be implicitly whitelisted. All the put_cmsg() calls being built from values in skbuff_head_cache are coming out of the protocol-defined "cb" field, so whitelist this field entirely instead of creating per-use bounce buffers, for which there are concerns about performance. Original report was: Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLAB object 'skbuff_head_cache' (offset 64, size 16)! WARNING: CPU: 0 PID: 3663 at mm/usercopy.c:81 usercopy_warn+0xdb/0x100 mm/usercopy.c:76 ... __check_heap_object+0x89/0xc0 mm/slab.c:4426 check_heap_object mm/usercopy.c:236 [inline] __check_object_size+0x272/0x530 mm/usercopy.c:259 check_object_size include/linux/thread_info.h:112 [inline] check_copy_size include/linux/thread_info.h:143 [inline] copy_to_user include/linux/uaccess.h:154 [inline] put_cmsg+0x233/0x3f0 net/core/scm.c:242 sock_recv_errqueue+0x200/0x3e0 net/core/sock.c:2913 packet_recvmsg+0xb2e/0x17a0 net/packet/af_packet.c:3296 sock_recvmsg_nosec net/socket.c:803 [inline] sock_recvmsg+0xc9/0x110 net/socket.c:810 ___sys_recvmsg+0x2a4/0x640 net/socket.c:2179 __sys_recvmmsg+0x2a9/0xaf0 net/socket.c:2287 SYSC_recvmmsg net/socket.c:2368 [inline] SyS_recvmmsg+0xc4/0x160 net/socket.c:2352 entry_SYSCALL_64_fastpath+0x29/0xa0 Reported-by: syzbot+e2d6cfb305e9f3911dea@syzkaller.appspotmail.com Fixes: 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0") Signed-off-by: Kees Cook --- I tried the inlining, it was awful. Splitting put_cmsg() was awful. So, instead, whitelist the "cb" field as the least bad option if bounce buffers are unacceptable. Dave, do you want to take this through net, or should I take it through the usercopy tree? --- net/core/skbuff.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 6b0ff396fa9d..201b96c8f414 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -3889,10 +3889,12 @@ EXPORT_SYMBOL_GPL(skb_gro_receive); void __init skb_init(void) { - skbuff_head_cache = kmem_cache_create("skbuff_head_cache", + skbuff_head_cache = kmem_cache_create_usercopy("skbuff_head_cache", sizeof(struct sk_buff), 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, + offsetof(struct sk_buff, cb), + sizeof_field(struct sk_buff, cb), NULL); skbuff_fclone_cache = kmem_cache_create("skbuff_fclone_cache", sizeof(struct sk_buff_fclones), -- 2.7.4 -- Kees Cook Pixel Security