linux-kernel - Re: [PATCH v2 1/7] dmaengine: idxd: fix memory leak in error handling path of idxd_setup

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: <98327a4d-7684-4908-9d67-5dfcaa229ae1@web.de>
Date: Sat, 15 Feb 2025 12:00:34 +0100
From: Markus Elfring <Markus.Elfring@....de>
To: Shuai Xue <xueshuai@...ux.alibaba.com>, dmaengine@...r.kernel.org,
 Dave Jiang <dave.jiang@...el.com>,
 Vinicius Costa Gomes <vinicius.gomes@...el.com>,
 Vinod Koul <vkoul@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Fenghua Yu <fenghua.yu@...el.com>,
 Nikhil Rao <nikhil.rao@...el.com>
Subject: Re: [PATCH v2 1/7] dmaengine: idxd: fix memory leak in error handling
 path of idxd_setup_wqs()

> Memory allocated for wqs is not freed if an error occurs during
> idxd_setup_wqs(). To fix it, free the allocated memory in the reverse
> order of allocation before exiting the function in case of an error.
>
> Fixes: a8563a33a5e2 ("dmanegine: idxd: reformat opcap output to match bitmap_parse() input")
…

Will a “stable tag” become relevant also for this patch series?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/stable-kernel-rules.rst?h=v6.14-rc2#n3


> +++ b/drivers/dma/idxd/init.c
> @@ -169,8 +169,8 @@ static int idxd_setup_wqs(struct idxd_device *idxd)
…
> @@ -204,6 +205,7 @@ static int idxd_setup_wqs(struct idxd_device *idxd)
>  		wq->wqcfg = kzalloc_node(idxd->wqcfg_size, GFP_KERNEL, dev_to_node(dev));
>  		if (!wq->wqcfg) {
>  			put_device(conf_dev);
> +			kfree(wq);
>  			rc = -ENOMEM;
>  			goto err;
>  		}
…

I got the impression that more common exception handling code could be moved
to additional jump targets at the end of such function implementations.
Will further adjustment opportunities be taken into account for
the affected resource management?

Regards,
Markus