Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp4020930ybc; Tue, 26 Nov 2019 02:28:30 -0800 (PST) X-Google-Smtp-Source: APXvYqzxtetOe+6qBSpwcewJyhAu0rmww0RYSvaQakUZBacgtmRhyITUtQ5SmzeHQVJzunzRkQS4 X-Received: by 2002:aa7:df09:: with SMTP id c9mr2083109edy.133.1574764109658; Tue, 26 Nov 2019 02:28:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574764109; cv=none; d=google.com; s=arc-20160816; b=rJKMs6TTR8fCeX59f+S9WRBTz5BU4/qeC6WCpmFLHCUzXIE52PRWi+bDzLM+uxSNlz W75ix8TAVMXjfj/BsZirzwyVVrNBekjHRxKArSgGB+R5GRct2Mitvfkrtbpe0iH9jS2i 8AUWMJgbAYe4nOyNB5KEFEzmfHnSu9Xbs7OSQxtUTtIQFJwdoxgmPZZbaT4pl0nZfRgW ykf13CUbKvIibp3fyMx2kmbo7DXIzkq+uUUvy0JdhKq3oSGQV5hDt4qLmHKwpaA8WXky otoR24vux52mDvhU2ZPP83UeOMObOLTKQvSpx37HLDNeTvet+AmYExAGrBzg93Trp/hf SwqA== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=+nPGKsVQYzJSyva/H7lzbzv37VFMhoTRL6ZQB9AtCYY=; b=CAjHiuGnCX9U34rwcsHKzPYVZv2LHa30IEAGyIX8KtNqgEVv3SHvh4dInzAROTYVOJ hn8oRNLKqs9RVOfBfB9b57mn6IVfJhBmL+RWLwpKNDmREbIwLb9KC1QvluIEuUmJumXQ C9932xiTIc3tMxYjBJUtLZua0Un5ke9/ensO4GcfmREHM37qSXXrmUwt6R20nFq5M1qB kZYhmlCb8tjE4HGWQkDqC5ofX8k8ynbsCK1sV8ENFwXnogJmwlv89RR8Q8gkhPvfxQUN KsZCXuxoDJi9MYHriqzFM3QvDHahtMWYT6p0A9J2TXqDe0iG6HKOKmICgz0t61KIrkdx wf1w== 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=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d6si7965991eda.262.2019.11.26.02.28.06; Tue, 26 Nov 2019 02:28:29 -0800 (PST) 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=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727817AbfKZKZA (ORCPT + 99 others); Tue, 26 Nov 2019 05:25:00 -0500 Received: from out4436.biz.mail.alibaba.com ([47.88.44.36]:30462 "EHLO out4436.biz.mail.alibaba.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727726AbfKZKZA (ORCPT ); Tue, 26 Nov 2019 05:25:00 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R131e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01422;MF=wenyang@linux.alibaba.com;NM=1;PH=DS;RN=4;SR=0;TI=SMTPD_---0Tj8hI5Z_1574763887; Received: from IT-C02W23QPG8WN.local(mailfrom:wenyang@linux.alibaba.com fp:SMTPD_---0Tj8hI5Z_1574763887) by smtp.aliyun-inc.com(127.0.0.1); Tue, 26 Nov 2019 18:24:48 +0800 Subject: Re: [PATCH] firmware: arm_scmi: avoid double free in error flow To: Sudeep Holla Cc: Arnd Bergmann , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20191125155409.9948-1-wenyang@linux.alibaba.com> <20191125161313.GA1157@bogus> From: Wen Yang Message-ID: <21f4f7d6-9085-382d-42d3-a63484aca8a2@linux.alibaba.com> Date: Tue, 26 Nov 2019 18:24:47 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <20191125161313.GA1157@bogus> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/11/26 12:13 上午, Sudeep Holla wrote: > On Mon, Nov 25, 2019 at 11:54:09PM +0800, Wen Yang wrote: >> If device_register() fails, both put_device() and kfree() >> are called, ending with a double free of the scmi_dev. >> > > Correct. > >> Calling kfree() is needed only when a failure happens between the >> allocation of the scmi_dev and its registration, so move it to >> there and remove it from the error flow. >> > > kstrdup_const can fail and in that case device is not yet registered, > so we need to free. Since device_register() calls put_device() on failure > too, I would just drop it as it's unnecessary, not sure why I have added > it in the first place. Can you re-spin the patch dropping put_device > and renaming put_dev label to something like free_const. > > -- > Regards, > Sudeep > Hi Sudeep, Thanks for your comments. Let's check the code like this: int device_register(struct device *dev) { device_initialize(dev); --> Initialize kobj-> kref to 1 return device_add(dev); } int device_add(struct device *dev) { ... dev = get_device(dev); --> kobj-> kref increases by 1 ... done: put_device(dev); --> kobj-> kref decreases by 1 and is now 1 return error; ... } So we also need to call put_device (), and the original patch should be fine. Please kindly help to check again, thank you. -- Regards, Wen