From: sashiko-bot@kernel.org
To: "Esben Haabendal" <esben@geanix.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/3] drm/bridge: nwl-dsi: Limit LCDIF specific sync override
Date: Fri, 10 Jul 2026 14:09:10 +0000 [thread overview]
Message-ID: <20260710140910.6C6F01F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260710-nwl-dsi-fixes-v1-1-927d918a86ad@geanix.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Dangling pointer `dsi->xfer` leads to stack Use-After-Free if a timeout or clock error occurs during transfer.
--
--- Patch [1]: [PATCH 1/3] drm/bridge: nwl-dsi: Limit LCDIF specific sync override ---
commit 36a9bfa60fd8b6568d59af4e95e04fc059970758
Author: Esben Haabendal <esben@geanix.com>
drm/bridge: nwl-dsi: Limit LCDIF specific sync override
When using DCSS with NWL, overriding the mode flags to enforce active high
sync is preventing the use of active low with downstream bridges, such as
ti-sn65dsi83, which will not see such mode flags set by the panel.
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
> index 3c9ae93c4f671..915e1bdc73c80 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -110,6 +110,8 @@ struct nwl_dsi {
> int error;
>
> struct nwl_dsi_transfer *xfer;
[Severity: High]
This is a pre-existing issue, but could this pointer lead to a stack
use-after-free if a timeout or clock error occurs during a transfer?
In nwl_dsi_host_transfer(), dsi->xfer is assigned the address of a local stack
variable:
struct nwl_dsi_transfer xfer;
...
dsi->xfer = &xfer;
If clk_prepare_enable(dsi->rx_esc_clk) fails, or if the DSI transfer times out
(wait_for_completion_timeout() returns 0), the function returns without
clearing dsi->xfer.
If a delayed or spurious hardware interrupt later triggers
nwl_dsi_irq_handler(), it will call nwl_dsi_finish_transmission() which
dereferences the dangling dsi->xfer pointer:
xfer->status = xfer->tx_len;
complete(&xfer->completed);
Because xfer was originally on the stack of the returned function, could this
overwrite arbitrary stack memory of whatever thread happens to be running at
the time of the interrupt?
> +
> + unsigned int endpoint;
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-nwl-dsi-fixes-v1-0-927d918a86ad@geanix.com?part=1
next prev parent reply other threads:[~2026-07-10 14:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 13:53 [PATCH 0/3] drm/bridge: nwl-dsi: Various fixes Esben Haabendal
2026-07-10 13:53 ` [PATCH 1/3] drm/bridge: nwl-dsi: Limit LCDIF specific sync override Esben Haabendal
2026-07-10 14:09 ` sashiko-bot [this message]
2026-07-10 13:53 ` [PATCH 2/3] drm/bridge: nwl-dsi: Correct auto-insert EOTP behavior Esben Haabendal
2026-07-10 13:53 ` [PATCH 3/3] drm/bridge: nwl-dsi: Correct MIPI DSI horizontal sync timing Esben Haabendal
2026-07-10 14:27 ` sashiko-bot
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=20260710140910.6C6F01F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=esben@geanix.com \
--cc=sashiko-reviews@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox