linux-kernel - Re: [PATCH v2] drm/amdkfd: fix a memory leak in device_queue_manager

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: <cc24a955-f5b2-43e6-a4fd-ff446d699fce@amd.com>
Date: Thu, 8 Jan 2026 18:02:04 -0500
From: Felix Kuehling <felix.kuehling@....com>
To: Markus Elfring <Markus.Elfring@....de>,
 Haoxiang Li <lihaoxiang@...c.iscas.ac.cn>, amd-gfx@...ts.freedesktop.org,
 dri-devel@...ts.freedesktop.org, Alex Deucher <alexander.deucher@....com>,
 Christian König <christian.koenig@....com>,
 David Airlie <airlied@...il.com>, Oak Zeng <ozeng@....com>,
 Simona Vetter <simona@...ll.ch>
Cc: stable@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] drm/amdkfd: fix a memory leak in
 device_queue_manager_init()

On 2026-01-06 04:30, Markus Elfring wrote:
> …
>> Move deallocate_hiq_sdma_mqd() up to ensure proper function
>> visibility at the point of use.
> …
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
>> @@ -2919,6 +2919,14 @@ static int allocate_hiq_sdma_mqd(struct device_queue_manager *dqm)
>>   	return retval;
>>   }
>>   
>> +static void deallocate_hiq_sdma_mqd(struct kfd_node *dev,
>> +				    struct kfd_mem_obj *mqd)
>> +{
>> +	WARN(!mqd, "No hiq sdma mqd trunk to free");
>> +
>> +	amdgpu_amdkfd_free_gtt_mem(dev->adev, &mqd->gtt_mem);
>> +}
> Is there also a need to reconsider the implementation of the applied
> null pointer check here?

Yeah, we have a WARN if mqd is NULL but then we still call 
amdgpu_amdkfd_free_gtt_mem. There is a NULL pointer check in 
amdgpu_amdkfd_free_gtt_mem, but &mqd->gtt_mem won't be NULL because it's 
not at the start of struct kfd_mem_obj. So you'd get a kernel oops if 
mqd is ever NULL here.

That said, I've never seen anyone complain about this WARN and a 
subsequent kernel oops.

The only other place that calls deallocate_hiq_sdma_mqd is 
device_queue_manager_uninit (only if not using MES). It can only be 
called with a valid dqm if device_queue_manager_init succeeded, which 
always ends with a valid dqm->hiq_sdma_mqd if not using MES.

My conclusion is that this WARN is just unnecessary. But it's also harmless.

Regards,
   Felix

>
> Regards,
> Markus