From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5B742C433F5 for ; Thu, 6 Jan 2022 18:36:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242928AbiAFSgF (ORCPT ); Thu, 6 Jan 2022 13:36:05 -0500 Received: from smtp02.smtpout.orange.fr ([80.12.242.124]:52079 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242731AbiAFSgE (ORCPT ); Thu, 6 Jan 2022 13:36:04 -0500 Received: from [192.168.1.18] ([90.11.185.88]) by smtp.orange.fr with ESMTPA id 5XcCn6oLyBazo5XcDn2y4b; Thu, 06 Jan 2022 19:36:03 +0100 X-ME-Helo: [192.168.1.18] X-ME-Auth: YWZlNiIxYWMyZDliZWIzOTcwYTEyYzlhMmU3ZiQ1M2U2MzfzZDfyZTMxZTBkMTYyNDBjNDJlZmQ3ZQ== X-ME-Date: Thu, 06 Jan 2022 19:36:03 +0100 X-ME-IP: 90.11.185.88 Message-ID: Date: Thu, 6 Jan 2022 19:35:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [PATCH] fsi: Aspeed: Fix a potential double free Content-Language: en-US To: Guenter Roeck , Dan Carpenter , Greg KH Cc: kernel-janitors@vger.kernel.org, linux-aspeed@lists.ozlabs.org, alistair@popple.id.au, linux-kernel@vger.kernel.org, linux-fsi@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org References: <2cafa0607ca171ebd00ac6c7e073b46808e24f00.1640537669.git.christophe.jaillet@wanadoo.fr> <20220106081418.GH7674@kadam> From: Christophe JAILLET In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 06/01/2022 à 18:25, Guenter Roeck a écrit : > On 1/6/22 12:14 AM, Dan Carpenter wrote: >> On Mon, Dec 27, 2021 at 07:29:07AM +0100, Greg KH wrote: >>> On Sun, Dec 26, 2021 at 05:56:02PM +0100, Christophe JAILLET wrote: >>>> 'aspeed' is a devm_alloc'ed, so there is no need to free it >>>> explicitly or >>>> there will be a double free(). >>> >>> A struct device can never be devm_alloced for obvious reasons.  Perhaps >>> that is the real problem here? >>> >> >> I don't understand how "aspeed" is a struct device. >> > > -static void aspeed_master_release(struct device *dev) > -{ > -    struct fsi_master_aspeed *aspeed = > -        to_fsi_master_aspeed(dev_to_fsi_master(dev)); > - > -    kfree(aspeed); > -} > > So "dev" is embedded in struct fsi_master, and struct fsi_master is > embedded > in struct fsi_master_aspeed. Since "struct device" is embedded, the data > structure embedding it must be released with the release function, as is > done > here. The problem is indeed that the data structure is allocated with > devm_kzalloc(), which as Greg points out must not be devm_ allocated > (because its lifetime does not match the lifetime of devm_ allocated > memory). Thanks a lot for the detailed explanation. Crystal clear for me now. Do you want me to send a patch to remove the devm_ or will you? CJ > >> I've been working on understanding device managed memory recently for >> Smatch.  It's really complicated.  There are a bunch of rules/heuristics >> that I'm slowly creating to generate new warnings but I'm a long way >> from understanding it well myself. >> > > A data structure embedding struct device must not be devm_ allocated, > and it must be released with the release callback. Maybe there is > a means to flag that somehow ? > > Guenter >