mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Maulik Shah <maulik.shah@oss.qualcomm.com>
To: Abel Vesa <abel.vesa@oss.qualcomm.com>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
	Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>,
	Mark Brown <broonie@kernel.org>,
	Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Sashiko <sashiko-bot@kernel.org>
Subject: Re: [PATCH] soc: qcom: rpmh: Fix use-after-free on timed out blocking requests
Date: Fri, 13 Nov 2026 10:03:32 +0530	[thread overview]
Message-ID: <50103867-1f03-4346-8174-b7301ba3ddf5@oss.qualcomm.com> (raw)
In-Reply-To: <20261102-rpmh-timeout-uaf-v1-1-f1fe9d38f1b8@oss.qualcomm.com>



On 02-11-2026 16:16, Abel Vesa wrote:
> rpmh_write(), rpmh_read() and the ACTIVE_ONLY path of rpmh_write_batch()
> hand a request to the RSC controller and wait for it to complete with
> wait_for_completion_timeout(). If the wait times out, they return to the
> caller, while the request is still owned by the TCS it was written to.
> For rpmh_write() and rpmh_read(), both the request and the completion
> live on the stack, while rpmh_write_batch() frees them on its way out.
>
> If the hardware completes the request after the timeout, tcs_tx_done()
> fetches the stale request from the TCS, passes it to the tracepoint and
> to rpmh_tx_done(), which then signals a completion that no longer
> exists. For reads, the response data is also written into the stale
> request first. This corrupts the stack of whatever the timed out caller
> went on to do, or freed memory. rpmh_write_batch() even documents this
> with a "Better hope they never finish" comment.
> Fix this by giving every request handed to the controller a reference
> count and by embedding the completion into the request. 

I would prefer to use BUG_ON() instead of WARN_ON() whenever timeout happens
just like downstream does rather than to handle the timeout cases.

In cases where interrupt never arrives, already HW is stuck with no way to recover,
so current implementation of having a WARN_ON() and allowing to continue to run
will eventually end up in BUG() or crash somewhere else.

Given the RPMH_TIMEOUT_MS is 10 seconds large and RPMH hardware transactions
expected to finish quick (within milli seconds), In cases where interrupts arrives but
CPU handling it after 10 seconds, there is something wrong. 

I have a series to print debug info when timeout happens at [1]
I can update WARN_ON() to BUG_ON() in v4.

[1] https://lore.kernel.org/linux-arm-msm/20260812-rpmh-timeout-debug-v1-v3-3-68c0a40dce23@oss.qualcomm.com/ <https://lore.kernel.org/linux-arm-msm/20260812-rpmh-timeout-debug-v1-v3-3-68c0a40dce23@oss.qualcomm.com/>

Thanks,
Maulik

      reply	other threads:[~2026-11-13  4:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-02 10:46 Abel Vesa
2026-11-13  4:33 ` Maulik Shah [this message]

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=50103867-1f03-4346-8174-b7301ba3ddf5@oss.qualcomm.com \
    --to=maulik.shah@oss.qualcomm.com \
    --cc=abel.vesa@oss.qualcomm.com \
    --cc=andersson@kernel.org \
    --cc=broonie@kernel.org \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=kamal.wadhwa@oss.qualcomm.com \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=konradybcio@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sashiko-bot@kernel.org \
    /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

all inboxes | Powered by JetHome®