Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp4370302pxb; Tue, 5 Oct 2021 01:24:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxpynTa6wEMBbFcYvyc987QY66JdEz7Jm+wpT5T/O/1QNe4AIJLWUfovDs5GgZEV/Ptksrz X-Received: by 2002:a63:b04c:: with SMTP id z12mr14440730pgo.371.1633422251428; Tue, 05 Oct 2021 01:24:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633422251; cv=none; d=google.com; s=arc-20160816; b=L7ZoZSXgK/hOYEIu8VlbaO8OnchyWpT+bU3PNi7enLzUDATbepI5vyG+ugq09JB4eL VIgUO2kcccMksBAJumqWMVXP3mI+bmLBNyRT+wmUWLZZ/d3AhBlhzNIyst7bknMiREar 3NXcO4SmA1OM25CdYMBI3+GNE7r1RDDI2dOjYCvmR2XfGWPfCC/XFkXvGBVpp16RsvS+ 3t0qaa0vcZXgL4fNHpVRXGmXIezCn7dirlig5UjX9hmaaTYQJogtRaeuL44zsYCp3CQa qKrT9RRQSUVSPBx9rVfd4PPv/z+x+R8ZeZWas8xh9HfjXLph896ysgoi3WMOUByPY0tK XKZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=hi5SAre581L6W5vdy1I4aQNo4R/thWu/UYiWhbyJ97Y=; b=J+adhfBF1U9+8SRGQ9JLNQsu3yB+ZLXdzsX6UKEvKja225PGcZ500/vZId/wOT10o2 G2ZkcQH2lC5zQCwfHuQwCHPJOwljD5KdnpaTq3gut8itBxTnKlVqg0FOVq1CMjWMx0Wc JA1mK5N5B7K4U0m1E0R7QXjvYnTvLme2nX6MK4zDTSKrbR110MNmYe8NrSjews2fJx5T cBDE/e1/icQCl4mtaaRPuQ+EPsxldHDJ4Nrwjadt+c6rPYCZbuIiVZAEX99bE8mxJ8ty knk07Mhy1HoUviD2CQ+NNDus/qH9AwmYU+1C8oCt2UIV8dwnxB/PthdB8zckt/XgE9WV hmLg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q18si1194652pjp.61.2021.10.05.01.23.59; Tue, 05 Oct 2021 01:24:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232723AbhJEIXu (ORCPT + 99 others); Tue, 5 Oct 2021 04:23:50 -0400 Received: from mga03.intel.com ([134.134.136.65]:38245 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232478AbhJEIXs (ORCPT ); Tue, 5 Oct 2021 04:23:48 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10127"; a="225626827" X-IronPort-AV: E=Sophos;i="5.85,348,1624345200"; d="scan'208";a="225626827" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Oct 2021 01:21:58 -0700 X-IronPort-AV: E=Sophos;i="5.85,348,1624345200"; d="scan'208";a="439429468" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Oct 2021 01:21:56 -0700 Received: from andy by smile with local (Exim 4.95) (envelope-from ) id 1mXfhx-008pT9-8B; Tue, 05 Oct 2021 11:21:53 +0300 Date: Tue, 5 Oct 2021 11:21:53 +0300 From: Andy Shevchenko To: Kent Gibson Cc: Heikki Krogerus , Greg Kroah-Hartman , "Rafael J. Wysocki" , ACPI Devel Maling List , Linux Kernel Mailing List , Bartosz Golaszewski Subject: Re: linux 5.15-rc4: refcount underflow when unloading gpio-mockup Message-ID: References: <20211004093416.GA2513199@sol> <20211004121942.GA3343713@sol> <20211004124701.GA3418302@sol> <20211004141754.GA3510607@sol> <20211004152844.GA3825382@sol> <20211005004035.GA29779@sol> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211005004035.GA29779@sol> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 05, 2021 at 08:40:35AM +0800, Kent Gibson wrote: > On Mon, Oct 04, 2021 at 10:56:00PM +0300, Andy Shevchenko wrote: > > On Mon, Oct 4, 2021 at 8:51 PM Kent Gibson wrote: ... > > Here is debug prints of what happens > > > > # modprobe gpio-mockup gpio_mockup_ranges=-1,10 > > [ 212.850993] (null): device_create_managed_software_node <<< 0 > > [ 212.858177] platform gpio-mockup.0: software_node_notify 0 <<< > > [ 212.865264] platform gpio-mockup.0: software_node_notify 1 <<< 1 > > [ 212.874159] gpio-mockup gpio-mockup.0: no of_node; not parsing pinctrl DT > > [ 212.882962] gpiochip_find_base: found new base at 840 > > [ 212.889873] gpio gpiochip3: software_node_notify 0 <<< > > [ 212.896164] gpio gpiochip3: software_node_notify 1 <<< 1 > > [ 212.905099] gpio gpiochip3: (gpio-mockup-A): added GPIO chardev (254:3) > > [ 212.913313] gpio gpiochip840: software_node_notify 0 <<< > > [ 212.920676] gpio gpiochip3: registered GPIOs 840 to 849 on gpio-mockup-A > > [ 212.935601] modprobe (185) used greatest stack depth: 12744 bytes left > > > > As I read it the software node is created for gpio-mockup device and > > then _shared_ with the GPIO device, since it's managed it's gone when > > GPIO device gone followed by UAF when mockup (platform) device itself > > gone. I.o.w. this software node mustn't be managed because it covers > > the lifetime of two different objects. The correct fix is to create > > manually software node and assign it to the pdev and manually free in > > gpio_mockup_unregister_pdevs()/ > > > > Tl;DR: it's a bug in gpio-mockup. > > So the bug is in the behaviour of gpio_mockup_register_chip()? Not really. The utter root cause is the former API (device_add_properties() et al) which Heikki is getting rid of in particular because of this issue, i.e. when users blindly call it without fully understanding the picture of the object lifetimes. > That is out of my court, so I'll leave it to you and Bart to sort out. I'll see what I can do about. -- With Best Regards, Andy Shevchenko