Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3446906ybb; Mon, 23 Mar 2020 00:57:25 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvcOflGuq0ELC8U/jUCO3gz0aGz8gfO8iNBHVDrQHHVWfxYIoAHA2Ory7oR/gSRwjM1bj1m X-Received: by 2002:a9d:6354:: with SMTP id y20mr17226098otk.171.1584950245255; Mon, 23 Mar 2020 00:57:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584950245; cv=none; d=google.com; s=arc-20160816; b=JwEKXxFMvuOPnFYNHR2++BLKFswaAn8q9qm3vrcIOxOoEF8W4Op0PXb61o65IhTkbo WD6CENQtzkZ+h5XV7xxDHx+zwUztfonqJ1Dwjm0F+tI7OqJJZUDa4ZCGztXBCVB8CerD dM9S8rkZ0mAOLDoNAfHPzuFnacy0E3JFz3rIO+dmT81/2B7RjE+Bscgw4/CO+EKViETb luV3oLUnnYo8sDUBj9YnWcJ/vIjlRPnuWs8pBqoH8QIAyYHupAsG1eRO3LOLW2vPGgQS 0UTh8ZhtmqAorFtBTsJ2wWZm1ejvtXXp2VKWTLk9qZEkFowsn60RqjZI6YlwjFsGNWFO 6kew== 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 :references:in-reply-to:message-id:subject:cc:to:from:date; bh=RxozTuwl/55ffhZ3F6euP3e/uvA+foyXaasqGP7bLks=; b=XLJxtD+MFYdlR8D4rNYOinFFWky22QZOf6kneZ0w5T5jwLCemRv576zWNSEpUkRk/T bBoN4HsfQX0BHp1JsHHxNhklTZkMKo0vdZ+k887+NRQDIyTLrsYuZWFy8RykxBc+aVuP oAWytYXlYSbr3y2A+FGlbfjisAPgQ0I8uHhtzTzY/Tk6Qp5c4VU8IvdYuOD+pqylW6KY cIerdJQKJfmf5d+o9BkTmLWp1GcMU+Y7ImoSkLGfdgg5xQ2HIigp5NZo37PGWVMBTSYv kj7nvorqMy+88WyV8C+i7rrPvFqJhINsOirBhajcp5q1wvvHePGK2dhaMPfD/WkUe1CG 2vsA== 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 a10si1926378otp.3.2020.03.23.00.57.12; Mon, 23 Mar 2020 00:57:25 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727495AbgCWH4y (ORCPT + 99 others); Mon, 23 Mar 2020 03:56:54 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:39960 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727428AbgCWH4y (ORCPT ); Mon, 23 Mar 2020 03:56:54 -0400 Received: by mail-lj1-f195.google.com with SMTP id 19so13393245ljj.7; Mon, 23 Mar 2020 00:56:52 -0700 (PDT) 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=RxozTuwl/55ffhZ3F6euP3e/uvA+foyXaasqGP7bLks=; b=ua9pUQr58uwOlj6bUpsZjTfOj8sUfMPvzYRyXoOE3grAK1UJRxGmoElzuNf4gwo3r7 KleHWcM7f9DwMvH3EnZJsRbvZXYDRkQ2nhielpcXdUdLs7dqwzJkXcs4lTZJ4wdGa9oJ jvrkAZUDOq4SbsxTNqxVftXRWwHyi5qKnCFtI9NV3CXweVGEUcgwFPJfWpadKsNevIZO NHohR1V+6H+i1x9afidKKNd06xGDYzqmoUI/eC7gQwYYK54VwT6v19LEGDRDadWr+Nal 5iOaToYJ5u6pjMWeiwiVn9oXVmqSgGbQcHtDIpHgYNZD8lwyg0qcKUdcIDxPYHZvHVIj wcjw== X-Gm-Message-State: ANhLgQ0sf2mxdoGmyvxigYgjL6kg4EGgcpNerpXA0ONRDJF1sGkxwHQc qS16T5hHf94tyfOxZMY6nbw= X-Received: by 2002:a2e:b804:: with SMTP id u4mr3537196ljo.159.1584950211373; Mon, 23 Mar 2020 00:56:51 -0700 (PDT) Received: from vostro.wlan (dty2hzyyyyyyyyyyyyx9y-3.rev.dnainternet.fi. [2001:14ba:802c:6a00::4fa]) by smtp.gmail.com with ESMTPSA id f16sm8024546ljj.34.2020.03.23.00.56.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Mar 2020 00:56:51 -0700 (PDT) Date: Mon, 23 Mar 2020 09:56:47 +0200 From: Timo Teras To: Yuehaibing Cc: , , , , , Subject: Re: [PATCH v2] xfrm: policy: Fix doulbe free in xfrm_policy_timer Message-ID: <20200323095647.5e93ffd2@vostro.wlan> In-Reply-To: <832e03ea-2511-eb7f-49d1-3cda6c9e6d18@huawei.com> References: <20200318034839.57996-1-yuehaibing@huawei.com> <20200323014155.56376-1-yuehaibing@huawei.com> <20200323085311.35aefe10@vostro.wlan> <832e03ea-2511-eb7f-49d1-3cda6c9e6d18@huawei.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-alpine-linux-musl) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 23 Mar 2020 15:21:45 +0800 Yuehaibing wrote: > On 2020/3/23 14:53, Timo Teras wrote: > > Hi > > > > On Mon, 23 Mar 2020 09:41:55 +0800 > > YueHaibing wrote: > > > >> After xfrm_add_policy add a policy, its ref is 2, then > >> > >> xfrm_policy_timer > >> read_lock > >> xp->walk.dead is 0 > >> .... > >> mod_timer() > >> xfrm_policy_kill > >> policy->walk.dead = 1 > >> .... > >> del_timer(&policy->timer) > >> xfrm_pol_put //ref is 1 > >> xfrm_pol_put //ref is 0 > >> xfrm_policy_destroy > >> call_rcu > >> xfrm_pol_hold //ref is 1 > >> read_unlock > >> xfrm_pol_put //ref is 0 > >> xfrm_policy_destroy > >> call_rcu > >> > >> xfrm_policy_destroy is called twice, which may leads to > >> double free. > > > > I believe the timer changes were added later in commit e7d8f6cb2f > > which added holding a reference when timer is running. I think it > > fails to properly account for concurrently running timer in > > xfrm_policy_kill(). > > commit e7d8f6cb2f hold a reference when &pq->hold_timer is armed, > in my case, it's policy->timer, and hold_timer is not armed. Ah, misread. Should have waited until first cup of coffee of the morning.. I must have not understood del_timer() return value fully back then. I first thought a more robust fix would be to take an extra reference in the beginning of the timer function (and instead of using mod_timer() return to see if a new reference is needed, it could be used in the prologue to "keep" the reference). This would guarantee always proper reference count inside the timer function. But I suppose because of the above xfrm_policy_kill() is the only place supposed to delete the timer, and that's why it had the locking in the first place. And the above "fix" might still end up having timer armed after kill_policy called del_timer() which is wrong. So perhaps it's more straightforward to just have the lock as it was originally around policy->walk.dead only. Perhaps adding a comment that it's synchronizing with the timer function. Since xfrm_policy_timer() ends with policy unref already now, the above reference keeping tricking might be good to do even for the current code as separate patch to avoid atomic ops if possible. Thanks, Timo