From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C99393C2BBA for ; Thu, 2 Jul 2026 10:57:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782989854; cv=none; b=XyHri5UWJCnxRARymyVnxe2v0Rwx1Y7B750b7r6IFlg9vRChdvoLIgQ/TrT8GCk5LWxWXVIPk6xDutPm0W3+MtniXZJFnrLxgtQWc1UYiy3GrJb0tTPcJri1GR15CV5OmAfs5YwosxE9Vyd75gDu4nNCOowLNU4Tci2+AHt2YmY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782989854; c=relaxed/simple; bh=ewRCJhE0qvl31yGCwuDvGKplkiSzDGi0ULrs+boFbLs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rpAZwF/stqb3N5vXbrQBAuCEntfH9ArfUhFiAdf+VAPCvFjWvEqgQeXzzqoaWGsdebv3uSsTZVGShv3Cl3IhV88wcOI4fPXe2XoMVSnYslBRf4JITotC5QXSx9Uq28vYKHSUGLXKUvd8YKFF00Ls0ES/4YuT2B020sHL+2+R4rs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TqmfqvC+; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TqmfqvC+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C82851F000E9; Thu, 2 Jul 2026 10:57:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782989853; bh=d3PrJEYo6EGwCzkvfFQ5R60DfgFDmz0F0m10vWtiT2k=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=TqmfqvC+IEHBTTBkKYKWz3tEFcgGl/MSEhDBtY/KfZMi8WPEkqpULrjQDFodvr4Oe 8Kw++yp5HXUGXMm+Yp67hLdIHsM4+Ec7CNWKzjFRgnnp6Wd8xWI/SYQmW5AV453CvC rh3CikNoUc9b2qQRP6RHCRJ8QnwmCFS7+xk7b7oTnakqsb1Ak7JfNALenECwA/NBfL 8PjC/mllBn2dXq4EpXXhln13eTCMYvIGLrqLOzB5e1Q4uTNoVKK0ueLzhQGKN1yjII K5B3ebJ3yES8Ntkh4oRvTZqfEdlfe7q95H81lZ0kmxHErfHaMIG20gEQyeZXxEG5zD APxaECGJY84yQ== Date: Thu, 2 Jul 2026 11:57:30 +0100 From: Lee Jones To: Pengpeng Hou Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] mfd: sm501: unwind common init failures Message-ID: <20260702105730.GJ2108533@google.com> References: <20260616004159.90144-1-pengpeng@iscas.ac.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260616004159.90144-1-pengpeng@iscas.ac.cn> Can you consider these please. Also, we don't allow forward declarations. /* Sashiko Automation: Reviewed (2 Findings) */ On Tue, 16 Jun 2026, Pengpeng Hou wrote: > sm501_init_dev() creates the debug sysfs file and can register child > devices before the final clock-source sanity check. If that check fails, > the caller tears down the parent mapping but the children and debug file > remain published. The PCI probe path also ignored the return value from > sm501_init_dev(). > > Unwind the common SM501 registrations before returning the clock-check > failure, and make the PCI probe path propagate sm501_init_dev() errors. > > Signed-off-by: Pengpeng Hou > --- > drivers/mfd/sm501.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c > index 0ee6d8940e69..b21b4fc18e87 100644 > --- a/drivers/mfd/sm501.c > +++ b/drivers/mfd/sm501.c > @@ -1249,6 +1249,8 @@ static unsigned int sm501_mem_local[] = { > [5] = 2*1024*1024, > }; > > +static void sm501_dev_remove(struct sm501_devdata *sm); > + > /* sm501_init_dev > * > * Common init code for an SM501 > @@ -1321,6 +1323,7 @@ static int sm501_init_dev(struct sm501_devdata *sm) > if (ret) { > dev_err(sm->dev, "M1X and M clocks sourced from different " > "PLLs\n"); > + sm501_dev_remove(sm); [Severity: High] This isn't a bug introduced by this patch, but can this error path unwinding lead to a Use-After-Free? When sm501_dev_remove() unregisters the child platform devices in sm501_remove_sub(), the devres framework automatically frees the memory allocated for the GPIO lookup table. However, since gpiod_remove_lookup_table() is never called to remove it from the global gpio_lookup_list, the freed memory remains linked. Will any subsequent GPIO lookup system-wide traverse this corrupted list, resulting in a Use-After-Free? [Severity: High] This is another pre-existing issue, but does calling devm_kzalloc() on an uninitialized platform device trigger a kernel panic here? Earlier in initialization, sm501_register_gpio_i2c_instance() allocates the platform device using kzalloc() and then immediately calls devm_kzalloc() to allocate the GPIO lookup table: drivers/mfd/sm501.c:sm501_register_gpio_i2c_instance() { ... pdev = sm501_create_subdev(sm, "i2c-gpio", 0, sizeof(struct i2c_gpio_platform_data)); ... lookup = devm_kzalloc(&pdev->dev, struct_size(lookup, table, 3), GFP_KERNEL); ... } Because device_initialize() hasn't been called on pdev yet, pdev->dev.devres_head is completely uninitialized. When devres attempts to attach the node, wouldn't it call list_add_tail() on an uninitialized list head and dereference a NULL pointer? > return -EINVAL; > } > > @@ -1583,9 +1586,14 @@ static int sm501_pci_probe(struct pci_dev *dev, > goto err4; > } > > - sm501_init_dev(sm); > + err = sm501_init_dev(sm); > + if (err) > + goto err5; > + > return 0; > > + err5: > + iounmap(sm->regs); > err4: > release_mem_region(sm->io_res->start, 0x100); > err3: > -- > 2.50.1 (Apple Git-155) > -- Lee Jones