lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aKxByRMFizjnhgn4@smile.fi.intel.com>
Date: Mon, 25 Aug 2025 13:58:17 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Zhang Heng <zhangheng@...inos.cn>
Cc: axboe@...nel.dk, phasta@...nel.org, broonie@...nel.org,
	lizetao1@...wei.com, viro@...iv.linux.org.uk,
	fourier.thomas@...il.com, anuj20.g@...sung.com,
	linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] block: mtip32xx: Prioritize state cleanup over memory
 freeing in the mtip_pci_probe error path.

On Mon, Aug 25, 2025 at 01:56:55PM +0300, Andy Shevchenko wrote:
> On Sat, Aug 23, 2025 at 04:32:22PM +0800, Zhang Heng wrote:
> > The original sequence kfree(dd); pci_set_drvdata(pdev, NULL); creates a
> > theoretical race condition window. Between these two calls, the pci_dev
> > structure retains a dangling pointer to the already-freed device private
> > data (dd). Any concurrent access to the drvdata (e.g., from an interrupt
> > handler or an unexpected call to remove) would lead to a use-after-free
> > kernel oops.
> > 
> > Changes made:
> > 1. `pci_set_drvdata(pdev, NULL);` - First, atomically sever the link
> > from the pci_dev.
> > 2. `kfree(dd);` - Then, safely free the private memory.
> > 
> > This ensures the kernel state is always consistent before resources
> > are released, adhering to defensive programming principles.

...

> >  iomap_err:
> > -	kfree(dd);
> >  	pci_set_drvdata(pdev, NULL);
> > -	return rv;
> > +	kfree(dd);
> 
> These two seems to me unrelated. How do you possible have a race? What's racy
> there? (Yes, I have read the commit message, but I fail to see how it may lead
> to anything here. My question in one of the previous patches was about needless
> pci_set_drvdata() call. Do we even need that one?
> 
> >  done:
> >  	return rv;

Also note, 99.99% of the drivers do that cleanup in the driver core whenever it
considers the best to do a such. So if you see an issue in this driver, the commit
message should really explain much more.

-- 
With Best Regards,
Andy Shevchenko



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ