From: sashiko-bot@kernel.org
To: "Wentao Liang" <vulab@iscas.ac.cn>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] firmware/sysfb: Fix device reference count leak in sysfb_disable()
Date: Wed, 16 Sep 2026 07:48:57 +0000 [thread overview]
Message-ID: <20260916074858.535EE1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260916073815.1972045-1-vulab@iscas.ac.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] sysfb: kill-switch bypass when parent device query returns an error
--
commit cea5d6870e1a5b4277264d29fe9056b6df3310b7
Author: Wentao Liang <vulab@iscas.ac.cn>
firmware/sysfb: Fix device reference count leak in sysfb_disable()
This commit addresses a device reference count leak in sysfb_disable(). It
adds a check to ensure the parent device is not an error pointer and releases
the reference using put_device() before returning.
> diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
> --- a/drivers/firmware/sysfb.c
> +++ b/drivers/firmware/sysfb.c
> @@ -71,9 +71,12 @@ void sysfb_disable(struct device *dev)
>
> mutex_lock(&disable_lock);
> parent = sysfb_parent_dev(si);
> - if (!dev || !parent || dev == parent) {
> - sysfb_unregister();
> - disabled = true;
> + if (!IS_ERR(parent)) {
[Severity: High]
Will wrapping the unregistration logic in !IS_ERR(parent) bypass the global
kill-switch when the parent device query returns an error?
Graphics drivers use sysfb_disable(NULL) as a global kill-switch to
unconditionally disable the generic firmware framebuffer before native DRM
drivers take over.
sysfb_parent_dev() can return an ERR_PTR (like -ENODEV) if the PCI device
exists but its memory decoding is not enabled. If this happens during early
boot or driver probe, this new check skips the block entirely, silently
bypassing the kill-switch and leaving the disabled flag as false.
If a built-in native DRM driver disables sysfb and subsequently enables PCI
memory decoding, could a later execution of sysfb_init() see disabled == false
and incorrectly register the generic framebuffer on top of the already-running
native driver? This concurrent access could lead to resource conflicts or kernel
panics.
> + if (!dev || !parent || dev == parent) {
> + sysfb_unregister();
> + disabled = true;
> + }
> + put_device(parent);
> }
> mutex_unlock(&disable_lock);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260916073815.1972045-1-vulab@iscas.ac.cn?part=1
next prev parent reply other threads:[~2026-09-16 7:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 7:38 [PATCH] firmware/sysfb: Fix device reference count leak in sysfb_disable() Wentao Liang
2026-09-16 7:48 ` sashiko-bot [this message]
2026-09-16 21:06 ` Deucher, Alexander
2026-09-17 6:50 ` Thomas Zimmermann
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=20260916074858.535EE1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vulab@iscas.ac.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.