Received: by 10.223.185.116 with SMTP id b49csp6386473wrg; Wed, 28 Feb 2018 08:33:58 -0800 (PST) X-Google-Smtp-Source: AH8x227W0ynbALkc1PFtOAyHysB3iJahBWRjkBi7goHGKFKzyRrBO3TZlaT6DsFpdIJH5UvNc+mf X-Received: by 10.98.27.10 with SMTP id b10mr18345885pfb.121.1519835638230; Wed, 28 Feb 2018 08:33:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519835638; cv=none; d=google.com; s=arc-20160816; b=uSgt+Z5HXECGpWr/1BcsHoEGchUoarDvrvo0d+G6drUldYSrIGAzrAEzNqFaOoAuNq GKRAiHcDajl/rACITebrehr4f3lHGaR2f6GmD8ayyXH7OUH4h3wbw9KMppb6o2SWayXN Yinb+gMCpuoUP5lYguKHB3PDiF8PUHsRrQ3x9EiG9tDPyLATxZIwdNmoroDb/fAS7Bvz mkBPD0Z6ddyJnkJ11D7WDvoFwPQVwqqmbtO8GhADb7Et7f6xkqGV/DhEmqWZsz730kp6 4cAnQdEG9DjoiOSCDFQfMcQsVkSCi8vO304QEWOutW0oTpVpLXMHu5/oIbQCUI7uMU8P ZyPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=24Sx/u2Eojwxb1xFAma/4aYhxpMfPnWniVKarLr14v0=; b=TvG1tjy+X5azd/w5p+wdAECWDll8MGp4FvIl+v12iQgjNHjFuEZtKKDbExUlXYN9IQ uXvjxRuVIuroj1Ydmgn+XEojtehsVA3y93+Ii9ajAtaAPYhunXs7rh0Bo9/SClYwx7rk ucVlRYBZR6WcgmqYSso3hB6HnOuB3tcBHSnJFI5M9NfJTLmXTFwoB5I2u8S+DfVE0M/2 Wrfz/LmyZgumVsmcX2R5vDK8pXLcYMhe3xj7EY2mnw/QAAWuPvQSiBvuFiLwLsMYAre2 b6OtvCJV+VWIuI4WSBBdXb1qo+F/zMU4xxf2zcxYDzvbOMeRuPjkp7iUSX3rSNJw+LNv phgQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 33-v6si1484191pls.710.2018.02.28.08.33.43; Wed, 28 Feb 2018 08:33:58 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753071AbeB1QOP (ORCPT + 99 others); Wed, 28 Feb 2018 11:14:15 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:35092 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752615AbeB1QOM (ORCPT ); Wed, 28 Feb 2018 11:14:12 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Yu-0006Xg-5X; Wed, 28 Feb 2018 15:22:32 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Ye-0008R5-EV; Wed, 28 Feb 2018 15:22:16 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Pablo Neira Ayuso" , "Jann Horn" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 051/254] netfilter: xt_bpf: add overflow checks In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Jann Horn commit 6ab405114b0b229151ef06f4e31c7834dd09d0c0 upstream. Check whether inputs from userspace are too long (explicit length field too big or string not null-terminated) to avoid out-of-bounds reads. As far as I can tell, this can at worst lead to very limited kernel heap memory disclosure or oopses. This bug can be triggered by an unprivileged user even if the xt_bpf module is not loaded: iptables is available in network namespaces, and the xt_bpf module can be autoloaded. Triggering the bug with a classic BPF filter with fake length 0x1000 causes the following KASAN report: ================================================================== BUG: KASAN: slab-out-of-bounds in bpf_prog_create+0x84/0xf0 Read of size 32768 at addr ffff8801eff2c494 by task test/4627 CPU: 0 PID: 4627 Comm: test Not tainted 4.15.0-rc1+ #1 [...] Call Trace: dump_stack+0x5c/0x85 print_address_description+0x6a/0x260 kasan_report+0x254/0x370 ? bpf_prog_create+0x84/0xf0 memcpy+0x1f/0x50 bpf_prog_create+0x84/0xf0 bpf_mt_check+0x90/0xd6 [xt_bpf] [...] Allocated by task 4627: kasan_kmalloc+0xa0/0xd0 __kmalloc_node+0x47/0x60 xt_alloc_table_info+0x41/0x70 [x_tables] [...] The buggy address belongs to the object at ffff8801eff2c3c0 which belongs to the cache kmalloc-2048 of size 2048 The buggy address is located 212 bytes inside of 2048-byte region [ffff8801eff2c3c0, ffff8801eff2cbc0) [...] ================================================================== Fixes: e6f30c731718 ("netfilter: x_tables: add xt_bpf match") Signed-off-by: Jann Horn Signed-off-by: Pablo Neira Ayuso [bwh: Backported to 3.16: - Add len variable in bpf_mt_check() - Drop change in __bpf_mt_check_path()] Signed-off-by: Ben Hutchings --- --- a/net/netfilter/xt_bpf.c +++ b/net/netfilter/xt_bpf.c @@ -24,8 +24,12 @@ static int bpf_mt_check(const struct xt_ { struct xt_bpf_info *info = par->matchinfo; struct sock_fprog_kern program; + u16 len = info->bpf_program_num_elem; - program.len = info->bpf_program_num_elem; + if (len > XT_BPF_MAX_NUM_INSTR) + return -EINVAL; + + program.len = len; program.filter = info->bpf_program; if (sk_unattached_filter_create(&info->filter, &program)) {