* [PATCH v2] nouveau/firmware: fix memory leak on BL load failure
@ 2026-06-10 2:50 ` Dawei Feng
0 siblings, 0 replies; 3+ messages in thread
From: Dawei Feng @ 2026-06-10 2:50 UTC (permalink / raw)
To: lyude
Cc: dakr, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
dri-devel, nouveau, linux-kernel, jianhao.xu, ttabi, Dawei Feng,
stable, Zilin Guan
If loading the HS bootloader blob fails, nvkm_falcon_fw_ctor_hs() returns
immediately. This skips the common cleanup path and leaks the firmware
state allocated by nvkm_falcon_fw_ctor() and nvkm_falcon_fw_sign().
Fix this by routing the load failure to the 'done' label so
nvkm_falcon_fw_dtor() can properly clean up the partially initialized
state. Keep the original image firmware in 'blob' until the common
cleanup path, and use a separate 'blob_bl' pointer for the bootloader
firmware so it can be released immediately after the bootloader data has
been copied.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available. Manual inspection confirms that the bug is still present in
v7.1-rc6.
An x86_64 allyesconfig build showed no new warnings. As we do not have a
supported NVIDIA GPU with the required firmware to test this path, no
runtime testing was able to be performed.
Fixes: 2541626cfb79 ("drm/nouveau/acr: use common falcon HS FW code for ACR FWs")
Cc: stable@vger.kernel.org
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
---
Changes in v2:
- Use a separate bootloader firmware pointer instead of reusing 'blob'.
- Keep the original image firmware release in the common cleanup path.
drivers/gpu/drm/nouveau/nvkm/falcon/fw.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c b/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c
index 4e8b3f1c7e25..063469ee462f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c
+++ b/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c
@@ -277,19 +277,20 @@ nvkm_falcon_fw_ctor_hs(const struct nvkm_falcon_fw_func *func, const char *name,
fw->dmem_sign = loc - lhdr->data_dma_base;
if (bl) {
- nvkm_firmware_put(blob);
+ const struct firmware *blob_bl;
- ret = nvkm_firmware_load_name(subdev, bl, "", ver, &blob);
+ ret = nvkm_firmware_load_name(subdev, bl, "", ver, &blob_bl);
if (ret)
- return ret;
+ goto done;
- hdr = nvfw_bin_hdr(subdev, blob->data);
- desc = nvfw_bl_desc(subdev, blob->data + hdr->header_offset);
+ hdr = nvfw_bin_hdr(subdev, blob_bl->data);
+ desc = nvfw_bl_desc(subdev, blob_bl->data + hdr->header_offset);
fw->boot_addr = desc->start_tag << 8;
fw->boot_size = desc->code_size;
- fw->boot = kmemdup(blob->data + hdr->data_offset + desc->code_off,
+ fw->boot = kmemdup(blob_bl->data + hdr->data_offset + desc->code_off,
fw->boot_size, GFP_KERNEL);
+ nvkm_firmware_put(blob_bl);
if (!fw->boot)
ret = -ENOMEM;
} else {
--
2.34.1
^ permalink raw reply related [flat|nested] 3+ messages in thread* [PATCH v2] nouveau/firmware: fix memory leak on BL load failure
@ 2026-06-10 2:50 ` Dawei Feng
0 siblings, 0 replies; 3+ messages in thread
From: Dawei Feng @ 2026-06-10 2:50 UTC (permalink / raw)
To: lyude
Cc: dakr, maarten.lankhorst, mripard, simona, dri-devel, nouveau,
linux-kernel, jianhao.xu, Dawei Feng, stable, Zilin Guan
If loading the HS bootloader blob fails, nvkm_falcon_fw_ctor_hs() returns
immediately. This skips the common cleanup path and leaks the firmware
state allocated by nvkm_falcon_fw_ctor() and nvkm_falcon_fw_sign().
Fix this by routing the load failure to the 'done' label so
nvkm_falcon_fw_dtor() can properly clean up the partially initialized
state. Keep the original image firmware in 'blob' until the common
cleanup path, and use a separate 'blob_bl' pointer for the bootloader
firmware so it can be released immediately after the bootloader data has
been copied.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available. Manual inspection confirms that the bug is still present in
v7.1-rc6.
An x86_64 allyesconfig build showed no new warnings. As we do not have a
supported NVIDIA GPU with the required firmware to test this path, no
runtime testing was able to be performed.
Fixes: 2541626cfb79 ("drm/nouveau/acr: use common falcon HS FW code for ACR FWs")
Cc: stable@vger.kernel.org
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
---
Changes in v2:
- Use a separate bootloader firmware pointer instead of reusing 'blob'.
- Keep the original image firmware release in the common cleanup path.
drivers/gpu/drm/nouveau/nvkm/falcon/fw.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c b/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c
index 4e8b3f1c7e25..063469ee462f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c
+++ b/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c
@@ -277,19 +277,20 @@ nvkm_falcon_fw_ctor_hs(const struct nvkm_falcon_fw_func *func, const char *name,
fw->dmem_sign = loc - lhdr->data_dma_base;
if (bl) {
- nvkm_firmware_put(blob);
+ const struct firmware *blob_bl;
- ret = nvkm_firmware_load_name(subdev, bl, "", ver, &blob);
+ ret = nvkm_firmware_load_name(subdev, bl, "", ver, &blob_bl);
if (ret)
- return ret;
+ goto done;
- hdr = nvfw_bin_hdr(subdev, blob->data);
- desc = nvfw_bl_desc(subdev, blob->data + hdr->header_offset);
+ hdr = nvfw_bin_hdr(subdev, blob_bl->data);
+ desc = nvfw_bl_desc(subdev, blob_bl->data + hdr->header_offset);
fw->boot_addr = desc->start_tag << 8;
fw->boot_size = desc->code_size;
- fw->boot = kmemdup(blob->data + hdr->data_offset + desc->code_off,
+ fw->boot = kmemdup(blob_bl->data + hdr->data_offset + desc->code_off,
fw->boot_size, GFP_KERNEL);
+ nvkm_firmware_put(blob_bl);
if (!fw->boot)
ret = -ENOMEM;
} else {
--
2.34.1
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH v2] nouveau/firmware: fix memory leak on BL load failure
2026-06-10 2:50 ` Dawei Feng
(?)
@ 2026-06-10 3:01 ` sashiko-bot
-1 siblings, 0 replies; 3+ messages in thread
From: sashiko-bot @ 2026-06-10 3:01 UTC (permalink / raw)
To: Dawei Feng; +Cc: dri-devel
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing bounds checking when parsing firmware headers allows out-of-bounds memory accesses.
--
commit 72846afc6e077321cb6e56447e8430295e342e68
Author: Dawei Feng <dawei.feng@seu.edu.cn>
nouveau/firmware: fix memory leak on BL load failure
This patch addresses a memory leak when loading the HS bootloader blob
fails. It routes the failure to the done label so that the partially
initialized firmware state can be properly cleaned up rather than returning
immediately.
> diff --git a/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c b/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c
> --- a/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c
[ ... ]
> @@ -277,19 +277,20 @@ nvkm_falcon_fw_ctor_hs(const struct nvkm_falcon_fw_func *func, const char *name,
> fw->dmem_sign = loc - lhdr->data_dma_base;
>
> if (bl) {
> - nvkm_firmware_put(blob);
> + const struct firmware *blob_bl;
>
> - ret = nvkm_firmware_load_name(subdev, bl, "", ver, &blob);
> + ret = nvkm_firmware_load_name(subdev, bl, "", ver, &blob_bl);
> if (ret)
> - return ret;
> + goto done;
>
> - hdr = nvfw_bin_hdr(subdev, blob->data);
> - desc = nvfw_bl_desc(subdev, blob->data + hdr->header_offset);
> + hdr = nvfw_bin_hdr(subdev, blob_bl->data);
> + desc = nvfw_bl_desc(subdev, blob_bl->data + hdr->header_offset);
>
> fw->boot_addr = desc->start_tag << 8;
> fw->boot_size = desc->code_size;
> - fw->boot = kmemdup(blob->data + hdr->data_offset + desc->code_off,
> + fw->boot = kmemdup(blob_bl->data + hdr->data_offset + desc->code_off,
> fw->boot_size, GFP_KERNEL);
[Severity: High]
This isn't a bug introduced by this patch, but does the firmware parsing
code in nvkm_falcon_fw_ctor_hs() lack bounds checking?
The offsets (such as hdr->header_offset, hdr->data_offset, and
desc->code_off) and sizes (like desc->code_size) are read directly from the
firmware blob. Because functions like nvfw_bin_hdr() and nvfw_bl_desc() do
not take the buffer size as an argument, they cannot perform structural
validation.
Could a malformed or corrupted firmware file cause an out-of-bounds memory
access when kmemdup() tries to copy data, or trigger an unusually large
allocation if desc->code_size is excessively large without being validated
against the total firmware size (blob_bl->size)?
> + nvkm_firmware_put(blob_bl);
> if (!fw->boot)
> ret = -ENOMEM;
> } else {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610025037.4115412-1-dawei.feng@seu.edu.cn?part=1
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-06-10 3:01 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-10 2:50 [PATCH v2] nouveau/firmware: fix memory leak on BL load failure Dawei Feng
2026-06-10 2:50 ` Dawei Feng
2026-06-10 3:01 ` sashiko-bot
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.