linux-kernel - Re: [PATCH 01/15] dmaengine: at_hdmac: fix device leak on of_dma

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: <aRw8fd_CTcybRevq@hovoldconsulting.com>
Date: Tue, 18 Nov 2025 10:29:33 +0100
From: Johan Hovold <johan@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Vinod Koul <vkoul@...nel.org>,
	Ludovic Desroches <ludovic.desroches@...rochip.com>,
	Viresh Kumar <vireshk@...nel.org>,
	Vinicius Costa Gomes <vinicius.gomes@...el.com>,
	Dave Jiang <dave.jiang@...el.com>,
	Vladimir Zapolskiy <vz@...ia.com>,
	Piotr Wojtaszczyk <piotr.wojtaszczyk@...esys.com>,
	Amélie Delaunay <amelie.delaunay@...s.st.com>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Peter Ujfalusi <peter.ujfalusi@...il.com>,
	dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, Yu Kuai <yukuai3@...wei.com>
Subject: Re: [PATCH 01/15] dmaengine: at_hdmac: fix device leak on
 of_dma_xlate()

On Mon, Nov 17, 2025 at 06:08:51PM +0100, Andy Shevchenko wrote:
> On Mon, Nov 17, 2025 at 05:12:43PM +0100, Johan Hovold wrote:
> > Make sure to drop the reference taken when looking up the DMA platform
> > device during of_dma_xlate() when releasing channel resources.
> > 
> > Note that commit 3832b78b3ec2 ("dmaengine: at_hdmac: add missing
> > put_device() call in at_dma_xlate()") fixed the leak in a couple of
> > error paths but the reference is still leaking on successful allocation.
> 
> ...
> 
> > -	kfree(chan->private);
> > -	chan->private = NULL;
> > +	atslave = chan->private;
> > +	if (atslave) {
> > +		put_device(atslave->dma_dev);
> > +		kfree(atslave);
> > +		chan->private = NULL;
> > +	}
> 
> It can also be
> 
> 	atslave = chan->private;
> 	if (atslave)
> 		put_device(atslave->dma_dev);
> 	kfree(chan->private);
> 	chan->private = NULL;
> 
> which makes patch shorter.

Perhaps, but it would be less readable.

> In any case I'm wondering if the asynchronous nature of put_device() can
> collide with chan->private = NULL assignment. I think as long as it's not
> used inside ->release() of the device, we are fine.

It's just another reference to the dma device which is not going away
while it's channels are being tore down (or we would have bigger
problems).

Johan