linux-kernel - Re: [PATCH v2] block: mtip32xx: Prioritize state cleanup over memory freeing in the mtip_pci

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aKxBd1uFldjopX3T@smile.fi.intel.com>
Date: Mon, 25 Aug 2025 13:56:55 +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 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;

-- 
With Best Regards,
Andy Shevchenko