Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp3058834pxt; Mon, 9 Aug 2021 16:01:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxTYh4PREPX9g5VpWxq9pb0am8Is/hS6ixvnT3DZeey3+YRIo4wOL5zQD891jZCklKAI95b X-Received: by 2002:a17:906:684e:: with SMTP id a14mr10432663ejs.440.1628550113792; Mon, 09 Aug 2021 16:01:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628550113; cv=none; d=google.com; s=arc-20160816; b=JbB/jnsOlZiaUU6SSR6CzLh32lGNwaEIsuJxbS8oHGRffIjeE/UIp9O3/m1MhahvnY peZeb4zl+zISHVI99VEbZmjKih2OvP/8j3V3G0jgT/bMBXH2jtzmKM6J0RzRacNBCk6w 9Gtq6SoIZb0F1G9DhABP1tHL+apWE/dCL8LR2YUeuPerc7k865drhtTQn8hYTHW95dQ/ mieT+AfDmB6TOXK++gc7QdxkS7lnQIS3wACBdEeL3WKBbrJ1CylqLsV6bOg//SXHwrMf kJyM10ixRX/stbFxi8NPRM7zKesW34eFXHAuxy5X/sfX74anF3r/Lf++H0+1xY23NnfN zxAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=FTZPI0adCc+haILEywBLskdqRD9JOn+9FC5ZrJL0/Js=; b=lsLRDGXTTHmxEwXX7edK0VND6mu3Ms/OVe59s32ro0mUIv2B7PM0Xx3Kuh7f9cKifL LttiC+Uzkd4zXdxUmMbY10LXGH+3rcSrzx/DGoso+wnPIZ1ywmFfRezcNdqCNA1PmO0G HiHZIpo/ebxit1fkMNz952gBG+EI+t76CSQHRbOhtflZjsGoOY/XygTa0lTCIhgJz6EB 5LpDXQJeNFH+kCChMxEYrK9UtR723xJxKGmr2G+YsBcudern6g1D1RzvJeudSF9IiOhF NlcUddu1FlxdvNfgqeHlQxtKcL2e5+XLonkRKaNSV09y6UedymYTGUczw7c0u90x6Lgb Osjg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p15si5331103edq.262.2021.08.09.16.01.30; Mon, 09 Aug 2021 16:01:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236255AbhHIUjn (ORCPT + 99 others); Mon, 9 Aug 2021 16:39:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45914 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233500AbhHIUjn (ORCPT ); Mon, 9 Aug 2021 16:39:43 -0400 Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2a0a:51c0:0:12e:520::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B113C0613D3; Mon, 9 Aug 2021 13:39:22 -0700 (PDT) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1mDC3I-0002rF-E2; Mon, 09 Aug 2021 22:39:16 +0200 Date: Mon, 9 Aug 2021 22:39:16 +0200 From: Florian Westphal To: Pavel Skripkin Cc: syzbot , coreteam@netfilter.org, davem@davemloft.net, fw@strlen.de, kadlec@netfilter.org, kuba@kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, pablo@netfilter.org, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] KASAN: use-after-free Write in nft_ct_tmpl_put_pcpu Message-ID: <20210809203916.GP607@breakpoint.cc> References: <000000000000b720b705c8f8599f@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Pavel Skripkin wrote: > I think, there a missing lock in this function: > > for_each_possible_cpu(cpu) { > ct = per_cpu(nft_ct_pcpu_template, cpu); > if (!ct) > break; > nf_ct_put(ct); > per_cpu(nft_ct_pcpu_template, cpu) = NULL; > > } > > Syzbot hit a UAF in nft_ct_tmpl_put_pcpu() (*), but freed template should be > NULL. > > So I suspect following scenario: > > > CPU0: CPU1: > = per_cpu() > = per_cpu() > > nf_ct_put > per_cpu = NULL > nf_ct_put() > * UAF * Yes and no. The above is fine since pcpu will return different pointers for cpu 0 and 1. The race is between two different net namespaces that race when changing nft_ct_pcpu_template_refcnt. This happens since commit f102d66b335a417d4848da9441f585695a838934 netfilter: nf_tables: use dedicated mutex to guard transactions Before this, all transactions were serialized by a global mutex, now we only serialize transactions in the same netns. Its probably best to add DEFINE_MUTEX(nft_ct_pcpu_mutex) and then acquire that when we need to inc/dec the nft_ct_pcpu_template_refcnt so we can't have two distinct cpus hitting a zero refcount. Would you send a patch for this? Thanks.