[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <751bd7d9fc65cdd3f1d118814193e9d925e2f56f.1601292571.git.saiprakash.ranjan@codeaurora.org>
Date: Mon, 28 Sep 2020 17:07:08 +0530
From: Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>
To: Mathieu Poirier <mathieu.poirier@...aro.org>,
Suzuki K Poulose <suzuki.poulose@....com>,
Mike Leach <mike.leach@...aro.org>
Cc: coresight@...ts.linaro.org, leo.yan@...aro.org,
alexander.shishkin@...ux.intel.com, peterz@...radead.org,
Stephen Boyd <swboyd@...omium.org>,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>
Subject: [RFC PATCHv2 1/2] coresight: tmc-etf: Fix NULL pointer dereference in tmc_enable_etf_sink_perf()
There was a report of NULL pointer dereference in ETF enable
path for perf CS mode with PID. It is almost 100% reproducible
when the process to monitor is something very active such as
chrome and only with ETF as the sink. Currently in a bid to
find the pid, the owner is dereferenced via task_pid_nr() call
in tmc_enable_etf_sink_perf(). With owner being NULL, we get a
NULL pointer dereference, so check the owner before dereferencing
it to prevent the system crash.
perf record -e cs_etm/@..._etf0/ -N -p <pid>
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000548
Mem abort info:
ESR = 0x96000006
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000006
CM = 0, WnR = 0
Call trace:
tmc_enable_etf_sink+0xe4/0x280
coresight_enable_path+0x168/0x1fc
etm_event_start+0x8c/0xf8
etm_event_add+0x38/0x54
event_sched_in+0x194/0x2ac
group_sched_in+0x54/0x12c
flexible_sched_in+0xd8/0x120
visit_groups_merge+0x100/0x16c
ctx_flexible_sched_in+0x50/0x74
ctx_sched_in+0xa4/0xa8
perf_event_sched_in+0x60/0x6c
perf_event_context_sched_in+0x98/0xe0
__perf_event_task_sched_in+0x5c/0xd8
finish_task_switch+0x184/0x1cc
schedule_tail+0x20/0xec
ret_from_fork+0x4/0x18
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>
---
I am not sure of this incomplete solution hence the RFC. This issue was also
reported when this code was first added [1] but somehow it didn't get much
notice at the time. So the NULL pointer is propagated from as far as
flexible_sched_in() (might even be earlier than this) in events core and
deferenced in ETF code where it crashes. So I am not sure if its a problem
with the core code or the etf driver. Plus it is not reproducible with all
the processes, just something which is quite active ones such as chrome.
This is with 5.4 kernel with all the coresight patches backported, I did
go through events/core code from latest kernel to see if we are missing
any fixes related to this but I couldn't find any so I believe this problem
should also exist on latest kernel as well.
[1] https://lists.linaro.org/pipermail/coresight/2019-March/002278.html
---
drivers/hwtracing/coresight/coresight-tmc-etf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index 44402d413ebb..32f141d943ca 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -242,6 +242,9 @@ static int tmc_enable_etf_sink_perf(struct coresight_device *csdev, void *data)
break;
}
+ if (!handle->event->owner)
+ break;
+
/* Get a handle on the pid of the process to monitor */
pid = task_pid_nr(handle->event->owner);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Powered by blists - more mailing lists