linux-kernel - Re: [PATCH RESEND] dmaengine: ti-dma-crossbar: Fix error handling in ti_am335x_xbar_route

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] [day] [month] [year] [list]

Message-ID: <aUFNoIzaGjAi_4SP@vaman>
Date: Tue, 16 Dec 2025 17:46:32 +0530
From: Vinod Koul <vkoul@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Ma Ke <make24@...as.ac.cn>, peter.ujfalusi@...il.com,
	dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, stable@...r.kernel.org
Subject: Re: [PATCH RESEND] dmaengine: ti-dma-crossbar: Fix error handling in
 ti_am335x_xbar_route_allocate

On 15-12-25, 12:52, Krzysztof Kozlowski wrote:
> On 15/12/2025 02:42, Ma Ke wrote:
> > ti_am335x_xbar_route_allocate() calls of_find_device_by_node() which
> > increments the reference count of the platform device, but fails to
> > call put_device() to decrement the reference count before returning.
> > This could cause a reference count leak each time the function is
> > called, preventing the platform device from being properly cleaned up
> > and leading to memory leakage.
> > 
> > Add proper put_device() calls in all exit paths to fix the reference
> > count imbalance.
> > 
> > Found by code review.
> > 
> > Cc: stable@...r.kernel.org
> > Fixes: 42dbdcc6bf96 ("dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx")
> > Signed-off-by: Ma Ke <make24@...as.ac.cn>
> > ---
> >  drivers/dma/ti/dma-crossbar.c | 24 ++++++++++++++++++------
> >  1 file changed, 18 insertions(+), 6 deletions(-)
> > 
> 
> 
> Just a note, author sends and resends same patches without addressing
> feedback. At least one case was very dubious or just incorrect code, and
> author just ignored it and sent it again to hide the previous
> discussion, so I suspect LLM generated content.
> 
> I did not review the code here, but please carefully review all patches
> from this author before applying and simply do not trust that this looks
> like a fix.

Right, I am very skeptical of random fixes coming in. Sometimes they
just follow a boilerplate pattern and fix, not attempt seems to be made
to check the environment and logic of fix..

> 
> Best regards,
> Krzysztof

-- 
~Vinod