From: James Clark <james.clark@linaro.org>
To: Kuan-Wei Chiu <visitorckw@gmail.com>, suzuki.poulose@arm.com
Cc: mike.leach@linaro.org, alexander.shishkin@linux.intel.com,
pratikp@codeaurora.org, mathieu.poirier@linaro.org,
gregkh@linuxfoundation.org, jserv@ccns.ncku.edu.tw,
marscheng@google.com, ericchancf@google.com,
milesjiang@google.com, nickpan@google.com,
coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] coresight: etm3x: Fix buffer overwrite in cntr_val_show()
Date: Fri, 21 Nov 2025 09:50:03 +0000 [thread overview]
Message-ID: <172ca2d9-4a6f-4498-bdfd-8aa7428581ce@linaro.org> (raw)
In-Reply-To: <20251121002350.1166758-1-visitorckw@gmail.com>
On 21/11/2025 12:23 am, Kuan-Wei Chiu wrote:
> The cntr_val_show() function is meant to display the values of all
> available counters. However, the sprintf() call inside the loop was
> always writing to the beginning of the buffer, causing the output of
> previous iterations to be overwritten. As a result, only the value of
> the last counter was actually returned to the user.
>
> Fix this by using the return value of sprintf() to calculate the
> correct offset into the buffer for the next write, ensuring that all
> counter values are appended sequentially.
>
> Fixes: a939fc5a71ad ("coresight-etm: add CoreSight ETM/PTM driver")
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> ---
> Build tested only. I do not have the hardware to run the etm3x driver,
> so I would be grateful if someone could verify this on actual hardware.
>
> I noticed this issue while browsing the coresight code after attending
> a technical talk on the subject. This code dates back to the initial
> driver submission over 10 years ago, so I was surprised it hadn't been
> caught earlier. Although I cannot perform runtime testing, the logic
> error seems obvious to me, so I still decided to submit this patch.
Nice find. I think the point that it wasn't caught changes how we fix
it. Either nobody used it ever - so we can just delete it. Or someone
was using it and they expect it to always return a single entry with the
value of the last counter and this is a potentially breaking change. So
maybe instead of fixing this we should add a new cntr_vals_show() which
works correctly. But then again if nobody is using it we shouldn't do
that either.
The interface isn't even that great, it should be a separate file per
counter. You don't want to be parsing strings and colons to try to read
a single value, especially in C. Separate files allows you to read it
directly without any hassle.
>
> drivers/hwtracing/coresight/coresight-etm3x-sysfs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> index 762109307b86..312033e74b7a 100644
> --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> @@ -725,7 +725,7 @@ static ssize_t cntr_val_show(struct device *dev,
> if (!coresight_get_mode(drvdata->csdev)) {
> spin_lock(&drvdata->spinlock);
> for (i = 0; i < drvdata->nr_cntr; i++)
> - ret += sprintf(buf, "counter %d: %x\n",
> + ret += sprintf(buf + ret, "counter %d: %x\n",
> i, config->cntr_val[i]);
> spin_unlock(&drvdata->spinlock);
> return ret;
> @@ -733,7 +733,7 @@ static ssize_t cntr_val_show(struct device *dev,
>
> for (i = 0; i < drvdata->nr_cntr; i++) {
> val = etm_readl(drvdata, ETMCNTVRn(i));
> - ret += sprintf(buf, "counter %d: %x\n", i, val);
> + ret += sprintf(buf + ret, "counter %d: %x\n", i, val);
> }
>
> return ret;
next prev parent reply other threads:[~2025-11-21 9:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-21 0:23 Kuan-Wei Chiu
2025-11-21 9:50 ` James Clark [this message]
2025-11-21 17:02 ` Kuan-Wei Chiu
2025-11-24 16:12 ` James Clark
2025-11-26 10:49 ` Mike Leach
2025-11-26 10:57 ` James Clark
2025-11-27 8:44 ` Kuan-Wei Chiu
2025-11-27 9:17 ` James Clark
2025-11-27 9:22 ` Leo Yan
2025-11-27 9:30 ` James Clark
2025-11-27 9:57 ` Leo Yan
2025-11-27 14:30 ` Mike Leach
2025-11-26 12:09 ` Leo Yan
2025-11-26 12:11 ` James Clark
2025-11-26 12:31 ` Leo Yan
2025-11-26 13:42 ` Mike Leach
2025-11-26 15:33 ` James Clark
2025-11-26 16:14 ` Mike Leach
2025-11-27 9:29 ` Leo Yan
2025-11-28 14:53 ` James Clark
2025-11-28 15:14 ` Al Grant
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=172ca2d9-4a6f-4498-bdfd-8aa7428581ce@linaro.org \
--to=james.clark@linaro.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=coresight@lists.linaro.org \
--cc=ericchancf@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=jserv@ccns.ncku.edu.tw \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marscheng@google.com \
--cc=mathieu.poirier@linaro.org \
--cc=mike.leach@linaro.org \
--cc=milesjiang@google.com \
--cc=nickpan@google.com \
--cc=pratikp@codeaurora.org \
--cc=suzuki.poulose@arm.com \
--cc=visitorckw@gmail.com \
/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®