All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Dawei Feng" <dawei.feng@seu.edu.cn>, "Timur Tabi" <ttabi@nvidia.com>
Cc: <lyude@redhat.com>, <maarten.lankhorst@linux.intel.com>,
	<mripard@kernel.org>, <simona@ffwll.ch>,
	<dri-devel@lists.freedesktop.org>,
	<nouveau@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
	<jianhao.xu@seu.edu.cn>, <stable@vger.kernel.org>,
	"Zilin Guan" <zilin@seu.edu.cn>
Subject: Re: [PATCH v2] nouveau/firmware: fix memory leak on BL load failure
Date: Sun, 21 Jun 2026 14:57:56 +0200	[thread overview]
Message-ID: <DJEQTPJAR8DW.18CJ2FC7YZPA3@kernel.org> (raw)
In-Reply-To: <20260610025037.4115412-1-dawei.feng@seu.edu.cn>

(Cc: Timur)

On Wed Jun 10, 2026 at 4:50 AM CEST, Dawei Feng wrote:
> 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>

Is Zilin a co-author of the patch?

> 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.

@Timur: Any further comments following up v1?

WARNING: multiple messages have this Message-ID (diff)
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Dawei Feng" <dawei.feng@seu.edu.cn>, "Timur Tabi" <ttabi@nvidia.com>
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	simona@ffwll.ch, dri-devel@lists.freedesktop.org,
	nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	jianhao.xu@seu.edu.cn, stable@vger.kernel.org,
	Zilin Guan <zilin@seu.edu.cn>
Subject: Re: [PATCH v2] nouveau/firmware: fix memory leak on BL load failure
Date: Sun, 21 Jun 2026 14:57:56 +0200	[thread overview]
Message-ID: <DJEQTPJAR8DW.18CJ2FC7YZPA3@kernel.org> (raw)
In-Reply-To: <20260610025037.4115412-1-dawei.feng@seu.edu.cn>

(Cc: Timur)

On Wed Jun 10, 2026 at 4:50 AM CEST, Dawei Feng wrote:
> 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>

Is Zilin a co-author of the patch?

> 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.

@Timur: Any further comments following up v1?

  parent reply	other threads:[~2026-06-21 12:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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
2026-06-21 12:57 ` Danilo Krummrich [this message]
2026-06-21 12:57   ` Danilo Krummrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DJEQTPJAR8DW.18CJ2FC7YZPA3@kernel.org \
    --to=dakr@kernel.org \
    --cc=dawei.feng@seu.edu.cn \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jianhao.xu@seu.edu.cn \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lyude@redhat.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=simona@ffwll.ch \
    --cc=stable@vger.kernel.org \
    --cc=ttabi@nvidia.com \
    --cc=zilin@seu.edu.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.