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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0BF88C433F5 for ; Thu, 6 Jan 2022 17:27:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:Cc:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=tA/7nLGgVLJ6dCDWq12uKAea27CjiTboXNfiOjTFe8c=; b=sCdItwkNMwRjRhwqA6i/h7TBWf DJRwXnZRaJvVb0t51Bq5uY4UuqfywQVG9R2x2bXJI/29YyJJ95CCE8MjAt2enqfuVsFtLI0STq6FB Jw/BGTCB1uu7pfvPy8J18Xu8V/mFOGCJB7hhOc2S9f99D9WipKqa3o/pS92euw54OCK5uh0jKA2GO 9U4IedscdLV7YChAbZl3IApNWWvar15ugqMY7IxC5NQYIrBKeYnzxzgr1B4vfEjFzcpdx4UkBtsRt 2UGBBc3ue8U/Cv3nwDbM9mcvER9pxkC8ZlG4IPRJTcud6REUqWTPzX1lV23kwbBQl/7/iXC2RxHdp 0efaFBAA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n5WW6-000oFO-Dh; Thu, 06 Jan 2022 17:25:34 +0000 Received: from mail-oi1-x22d.google.com ([2607:f8b0:4864:20::22d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n5WW3-000oCs-C4 for linux-arm-kernel@lists.infradead.org; Thu, 06 Jan 2022 17:25:32 +0000 Received: by mail-oi1-x22d.google.com with SMTP id w80so4641968oie.9 for ; Thu, 06 Jan 2022 09:25:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:to:cc:references:from:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TozlrHGra5XodYQFqCtDs+94E5DctxLnj7llPHao5XY=; b=ShaVbv1mLd0t/CMtcyvNeH+MVOScPrT2gNMh1L9O+mbMwJJEzoCnU5bOVvLFTFbx29 CIW3P5q5QyTpy6pyT4EBsYGYXOSQLWhxqlXSWfnWtyEM+kiCOhVqB0YrvaAr2Pk9qUfa VgIycswwxuc31jd4f9ZqkD2jM3fV2euzyj67EIHLT7Ll2jMm9UUjf1fkvMygD61A+3Ic t45RWPwOVlul4HkRHH39SgCXbeZoXSxQa0AQHbwXUAVYIAbixIN8mkdNtQK1Q99yR8Sh xuQXgPXx9dG3G2WLjltBRGzGRstCVw7RH6mR7QyEn/GVsqzMACOU0P65oBDvCJ0+V0EC H+Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:to:cc:references:from:subject:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TozlrHGra5XodYQFqCtDs+94E5DctxLnj7llPHao5XY=; b=eZWUNMVTMGIMdXeZrnnEaapqtcUeYPkiAEvnWTGN6aP/h6OShBaXTduPElqNQ8lnlW RBwvKCk6MUS/aRJHgqqBraGE+r50vY234qWDs1D3WiMXFEPoizeYBloIyOqOM1M5ia6g mJqY9UPkac59iFE4TPtfJByK6Ct5IpoqL4XHXa0Pf6wGe33F9N2n4Dyqb5hJF6PctaeG ZiQ0OFg2FReyWsG6aKPdeHeQrlWuBdkgaP4QtIs59yqpKXUxp7NxGDCCHUiVNXH37KSX gDa3BXA5Opx2GfMGX7ZzPokjQe5I/2L9FXcov8xs7Xk46aYYWdjRP1iDKfZBScl+ER77 VrZw== X-Gm-Message-State: AOAM533h4EYV/ot+T7+dOJbIw6/Kus7jYlYLcB5XBFMpgsXQq2+amWBX LXPQNu3XT/LHjzvZQ5hvXiz7pUsavq8= X-Google-Smtp-Source: ABdhPJwaVLxSFBfd3Dmpfs7ev1L4qtYx6bsFTZlvyEcxN0rHUzXDQWgkZ5ORNW5g6GbEH+1WZr5Ezw== X-Received: by 2002:aca:ad57:: with SMTP id w84mr6597267oie.69.1641489925201; Thu, 06 Jan 2022 09:25:25 -0800 (PST) Received: from server.roeck-us.net ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id bi20sm513287oib.29.2022.01.06.09.25.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Jan 2022 09:25:24 -0800 (PST) To: Dan Carpenter , Greg KH Cc: kernel-janitors@vger.kernel.org, linux-aspeed@lists.ozlabs.org, alistair@popple.id.au, linux-kernel@vger.kernel.org, Christophe JAILLET , linux-fsi@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org References: <2cafa0607ca171ebd00ac6c7e073b46808e24f00.1640537669.git.christophe.jaillet@wanadoo.fr> <20220106081418.GH7674@kadam> From: Guenter Roeck Subject: Re: [PATCH] fsi: Aspeed: Fix a potential double free Message-ID: Date: Thu, 6 Jan 2022 09:25:22 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20220106081418.GH7674@kadam> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220106_092531_457188_7DC3E2C0 X-CRM114-Status: GOOD ( 20.23 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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). > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel