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

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

Message-ID: <aRtWo9CNqMS1EP67@black.igk.intel.com>
Date: Mon, 17 Nov 2025 18:08:51 +0100
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Johan Hovold <johan@...nel.org>
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 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.

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.

-- 
With Best Regards,
Andy Shevchenko