Received: by 10.213.65.68 with SMTP id h4csp3797262imn; Tue, 3 Apr 2018 10:47:34 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/xEf/BVwSLjLJKpcGIjfLthFukbbc2kzbU8n6CS5NcJ/K4sm9ai0QOXaTnj/nt/ZdFeA1h X-Received: by 10.99.186.72 with SMTP id l8mr10007361pgu.410.1522777654563; Tue, 03 Apr 2018 10:47:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522777654; cv=none; d=google.com; s=arc-20160816; b=KQIawMTmVFLZu/3GOMmMEwfsLcMzG/lwMGvnuQfpzZjHLvOd1osRHzOxwv6oIXuBna MAcMoWpR4rBqD792iu8sj5I2RosMCwcJXsdnmtN6NTNgJbi68pIMiscGh8sEq6DiDt/n mw6zmSfSG+NoWbNicdFCTnWrGSyxWsuzugPXoaRDc5g1fz9kfJklRkuB1S5sj261+EKq MHzebBiotAmnRcGRVuzp4WdyLCB/tdtsPInhnczQtsZVLOHvFDSlkCl7AbZPKWqRPT4F jq6QLtjmCUTX+dxJeqV+vYCq76b3kD2Sxh/E0x2cbM3NUDQeDGMQQkITQU7jnzZ8XY8u TF4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=4hrAFv10wfI/EfcgBYLAirKsAMvFx/KEdYzteGEBnZg=; b=uy6/MPrC4X0uF22U8JOiJ7vupeyh3/WKo4k51CYIDyA9eAYc2FlacaLqFIMPf3g3EU yEUjncjrTQz1Mlqq4fV8YnBN+FU3uXRemDhI1hMNmTV1f9B0LzGV5rWZz2DiuUMSOtX5 zb8GdRUs9hzJ8Sn+snaSYBPl3rW0H4UcT0/L9+7HEpYe3St5papC83uwNNbRR2DbFaM8 fCVv2DBRD0xjilV4QIl8H6rivWxK+rTnqkQJc+RCjRNQpV4ehs2msOYN8cW7XeIAa8KX 50+NHs0xpIniRbK5LLARWlesNlMnOsY2pRjYngwQHw/e7NWn/IlJwJXOvcLE+ebzaJv7 HkIw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k191si2312411pgd.449.2018.04.03.10.47.20; Tue, 03 Apr 2018 10:47:34 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751850AbeDCRqO (ORCPT + 99 others); Tue, 3 Apr 2018 13:46:14 -0400 Received: from imap1.codethink.co.uk ([176.9.8.82]:59902 "EHLO imap1.codethink.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751413AbeDCRqM (ORCPT ); Tue, 3 Apr 2018 13:46:12 -0400 Received: from 167-98-27-229.cust-167.exponential-e.net ([167.98.27.229] helo=xylophone) by imap1.codethink.co.uk with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1f3Q0T-0004Pq-3F; Tue, 03 Apr 2018 18:46:05 +0100 Message-ID: <1522777564.2654.115.camel@codethink.co.uk> Subject: Re: [PATCH 4.4 38/97] netfilter: xt_CT: fix refcnt leak on error path From: Ben Hutchings To: Gao Feng , Liping Zhang , Pablo Neira Ayuso Cc: stable@vger.kernel.org, Sasha Levin , Greg Kroah-Hartman , LKML Date: Tue, 03 Apr 2018 18:46:04 +0100 In-Reply-To: <20180323094159.781131756@linuxfoundation.org> References: <20180323094157.535925724@linuxfoundation.org> <20180323094159.781131756@linuxfoundation.org> Organization: Codethink Ltd. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > ------------------ > > From: Gao Feng > > > [ Upstream commit 470acf55a021713869b9bcc967268ac90c8a0fac ] [...] > --- a/net/netfilter/xt_CT.c > +++ b/net/netfilter/xt_CT.c > @@ -168,8 +168,10 @@ xt_ct_set_timeout(struct nf_conn *ct, co >   goto err_put_timeout; >   } >   timeout_ext = nf_ct_timeout_ext_add(ct, timeout, GFP_ATOMIC); > - if (timeout_ext == NULL) > + if (!timeout_ext) { >   ret = -ENOMEM; > + goto err_put_timeout; > + } >   >   rcu_read_unlock(); >   return ret; This part looks fine. > @@ -201,6 +203,7 @@ static int xt_ct_tg_check(const struct x > >     struct xt_ct_target_info_v1 *info) >  { >   struct nf_conntrack_zone zone; > + struct nf_conn_help *help; >   struct nf_conn *ct; >   int ret = -EOPNOTSUPP; >   > @@ -249,7 +252,7 @@ static int xt_ct_tg_check(const struct x >   if (info->timeout[0]) { >   ret = xt_ct_set_timeout(ct, par, info->timeout); >   if (ret < 0) > - goto err3; > + goto err4; >   } >   __set_bit(IPS_CONFIRMED_BIT, &ct->status); >   nf_conntrack_get(&ct->ct_general); > @@ -257,6 +260,10 @@ out: >   info->ct = ct; >   return 0; >   > +err4: > + help = nfct_help(ct); > + if (help) > + module_put(help->helper->me); >  err3: >   nf_ct_tmpl_free(ct); >  err2: This does not. nf_ct_tmpl_free() calls nf_ct_ext_destroy() which I think will call back into xt_ct_tg_destroy(). So I think the module reference is already dropped here and we mustn't do it twice. Am I missing something? Ben. -- Ben Hutchings Software Developer, Codethink Ltd.