Received: by 10.213.65.68 with SMTP id h4csp1495523imn; Thu, 15 Mar 2018 00:55:01 -0700 (PDT) X-Google-Smtp-Source: AG47ELtJ84SI1yNuuJIO69hjD3PzDqYRK4dqW6eXttH7IwbLAj0mUHEyu+RHmZLw7T2ekhqA15am X-Received: by 2002:a17:902:ac1:: with SMTP id 59-v6mr7052221plp.228.1521100501230; Thu, 15 Mar 2018 00:55:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521100501; cv=none; d=google.com; s=arc-20160816; b=0L3ecTp9Hr0J27J23UAej5fILwQsBUU2cWFe/6uOtvtKM1W56W4YxcAIoCsJ5IXFva LQ3XpvwQCqZuiF9sov7EQg7Jb5Vv44sYyv/IrrDaRiOuBlmV++8RK0OHVDisYd9+ZUKR pEPBz3ychINKSWoWBsQnLfha9mBZrUkBHjkvKUHAts3miefe05EL4sfi8hNKgJMRj8W0 V8y1izwqzeq0jhJM61RAhuMvkNWEy+lmsI9+TFjqBeaIPsUdXlItN18YQLVgxHALjTw/ dVITiz9QEHalhQ25l+9Nkody8FN/BkbFfrV3t/loS2gOAOcX64xmi528Gw1tj2ton0XS 4YVw== 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:date:subject:cc:to:from :arc-authentication-results; bh=FLo52kvVhHK3kJ73BbzHqE/TrfVJrKCGfEp6yzFma+s=; b=0sShFxlWw7aWF0KXlQCBaGogh2sDyvHjJUCN241YuOXFPu7l0PeNqZd1xpbtLH+FS1 U5P6NPIKb4gaYUfNxZ2Zf/IQfMlGfeR7shQhEgacUVvquLTYfi3ztz4DuZFfE7Ixyv2K CizHgnTOIcsUYPFafzb+K2/wqV4A5w6uWjBX0nzQdiIMMfR1MT3dYhy/JTW9kDIoLD56 AjFQAPG1dAToKklBORC1fmJ0hBFiLBvMkimsr1TcKZ9fpLekKJ5RaGyVFBAoCCXbX9gQ fAZeOWW89HlQHtxAx3nj3Ff1Gpt8NVlvyYRpUa3uxMD13OebmwoetCPpjKzILvTf9jdG j4BA== 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 c23-v6si1696541pli.143.2018.03.15.00.54.47; Thu, 15 Mar 2018 00:55:01 -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 S1751679AbeCOHxo convert rfc822-to-8bit (ORCPT + 99 others); Thu, 15 Mar 2018 03:53:44 -0400 Received: from lilium.sigma-star.at ([109.75.188.150]:49826 "EHLO lilium.sigma-star.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751414AbeCOHxn (ORCPT ); Thu, 15 Mar 2018 03:53:43 -0400 Received: from localhost (localhost [127.0.0.1]) by lilium.sigma-star.at (Postfix) with ESMTP id 860AE181878AF; Thu, 15 Mar 2018 08:53:41 +0100 (CET) From: Richard Weinberger To: Arvind Yadav Cc: dwmw2@infradead.org, computersforpeace@gmail.com, boris.brezillon@free-electrons.com, marek.vasut@gmail.com, cyrille.pitchen@wedev4u.fr, dedekind1@gmail.com, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org Subject: Re: [PATCH 2/2 v2] mtd: ubi: use put_device() if device_register fail Date: Thu, 15 Mar 2018 08:55:09 +0100 Message-ID: <5296799.FRhcbj8Hd9@blindfold> In-Reply-To: <1521098431-29565-1-git-send-email-arvind.yadav.cs@gmail.com> References: <1521098431-29565-1-git-send-email-arvind.yadav.cs@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Donnerstag, 15. M?rz 2018, 08:20:31 CET schrieb Arvind Yadav: > if device_register() returned an error! Always use put_device() > to give up the reference initialized. Like DaveM said, there is no need to shout and use "!". > Signed-off-by: Arvind Yadav > --- > change in v2: > Fix use-after-free bug. move put_device() after cdev_del(). > > drivers/mtd/ubi/vmt.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mtd/ubi/vmt.c b/drivers/mtd/ubi/vmt.c > index 3fd8d7f..93c6163 100644 > --- a/drivers/mtd/ubi/vmt.c > +++ b/drivers/mtd/ubi/vmt.c > @@ -610,6 +610,7 @@ int ubi_add_volume(struct ubi_device *ubi, struct > ubi_volume *vol) > > out_cdev: > cdev_del(&vol->cdev); > + put_device(&vol->dev); > return err; The more I dig into device code, the more questions I have. Why is cdev_del() not part of the release function? Thanks, //richard