Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2242024imm; Wed, 16 May 2018 09:54:20 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqvV50ZTgjJXzQm31hdFgoWMUuegKreA56ctt347GLCoVge73jwtJ0PHj/CV6/QjLTayS9I X-Received: by 2002:a65:6151:: with SMTP id o17-v6mr1380306pgv.120.1526489660468; Wed, 16 May 2018 09:54:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526489660; cv=none; d=google.com; s=arc-20160816; b=AIdGcA8PKIBQTd5JdYP5mBTsHru2sI05s+aJqYk3oUGBSqmB3maCmhAjsC6GJHa19a Vr8rfQ8k7qHFNNnFtiGoKvY6YTvJE9wf6PA/AfqZZr8tos0i0t0G2ROSpQajUrnnjgUM Hv76wgNt2i9CWh0KN6gGj2eVS6vJ2v97pMJtAXQ/6XFaJoW2RGxfCjj0qCbfSkGmi5TO rDgYSxZzkyNYaMAn0Djxpxj/kAGzPuVAGQpK00dY1gB1hh/1bjl5Nc1XMr7IWacqX0ZF 64Twtdd1grpKFKKWmpO5ONTf1aZGSKH6x9eeiaOILt1zodStsX5eWnovZSB/GEd2NRHS +/ig== 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=fuBHjrE31bV7Vn6cRqGc2C9XKRiORjh+qToMEBoGmEU=; b=EmNMPLmsifYzXnS3wJ/zNMKkFJKVWMZJl+zXa/2CKhhnGH3swsBhyrXY+gYvVMfyVM HBcM0Z7azm8cpLhjEmHLgh+lTtKwDN+NCwNeiXza01t3tRLwc1xJ7ce65e3ySRbVZ4cz AUGdjXZhzqXtS43VrzH1Jl/IxLxqGzYqhdtZrO3BPXLjRBgP69Oz7VrMdEXQuKBpWXi+ 2fiO5y8rBmYWKvhfXrBSQUvsVak4KVdmgTCkDvN8p8tt25Xsj/LEvW/gHwpnGq+hHldf huIIWQ1Da1Hp1UyVSzlvfbvk2nqBLEdKplGRmDLpRdSB6lavwPiHm+XvYwwK+2/Uuu5P fB/w== 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 v8-v6si2913066plg.491.2018.05.16.09.54.05; Wed, 16 May 2018 09:54:20 -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 S1750879AbeEPQxy (ORCPT + 99 others); Wed, 16 May 2018 12:53:54 -0400 Received: from imap1.codethink.co.uk ([176.9.8.82]:48779 "EHLO imap1.codethink.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750759AbeEPQxw (ORCPT ); Wed, 16 May 2018 12:53:52 -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 1fIzgT-0000yY-KN; Wed, 16 May 2018 17:53:49 +0100 Message-ID: <1526489629.9159.147.camel@codethink.co.uk> Subject: Re: [PATCH 4.4 23/97] ubi: fastmap: Dont flush fastmap work on detach From: Ben Hutchings To: Martin Townsend , Richard Weinberger Cc: stable@vger.kernel.org, Greg Kroah-Hartman , LKML Date: Wed, 16 May 2018 17:53:49 +0100 In-Reply-To: <20180422135306.338619311@linuxfoundation.org> References: <20180422135304.577223025@linuxfoundation.org> <20180422135306.338619311@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 Sun, 2018-04-22 at 15:53 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > ------------------ > > From: Richard Weinberger > > commit 29b7a6fa1ec07e8480b0d9caf635a4498a438bf4 upstream. > > At this point UBI volumes have already been free()'ed and fastmap can no > longer access these data structures. I don't see how this change can fix a use-after-free. If this function can be called with *ubi already freed, then the rest of the function body is also not safe to run. But I don't think that is the case. ubi->fm_work doesn't depend on any other structure (except a global workqueue, which won't go away). It seems to me that the bug is really a race condition, and removing the flush_work() makes it harder to hit that condition. The proper fix would be to call flush_work() (or cancel_work_sync()) before the UBI volumes are freed. Ben. > Reported-by: Martin Townsend > Fixes: 74cdaf24004a ("UBI: Fastmap: Fix memory leaks while closing the WL sub-system") > Cc: stable@vger.kernel.org > Signed-off-by: Richard Weinberger > Signed-off-by: Greg Kroah-Hartman > > --- >  drivers/mtd/ubi/fastmap-wl.c |    1 - >  1 file changed, 1 deletion(-) > > --- a/drivers/mtd/ubi/fastmap-wl.c > +++ b/drivers/mtd/ubi/fastmap-wl.c > @@ -360,7 +360,6 @@ static void ubi_fastmap_close(struct ubi >  { >   int i; >   > - flush_work(&ubi->fm_work); >   return_unused_pool_pebs(ubi, &ubi->fm_pool); >   return_unused_pool_pebs(ubi, &ubi->fm_wl_pool); >   > > > -- Ben Hutchings Software Developer, Codethink Ltd.