From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: coresight@lists.linaro.org, saiprakash.ranjan@codeaurora.org,
linux-arm-kernel@lists.infradead.org,
Mike Leach <mike.leach@linaro.org>
Subject: Re: [PATCH] coresight: etm4x: Fix use-after-free of per-cpu etm drvdata
Date: Fri, 8 May 2020 11:56:32 -0600 [thread overview]
Message-ID: <20200508175632.GA3181@xps15> (raw)
In-Reply-To: <20200506155312.1777481-1-suzuki.poulose@arm.com>
On Wed, May 06, 2020 at 04:53:12PM +0100, Suzuki K Poulose wrote:
> etm probe could be deferred due to the dependency in the trace
> path chain and may be retried. We need to clear the per-cpu
> etmdrvdata entry for the etm in case of a failure to avoid
> use-after-free cases as reported below:
>
> KASAN use-after-free bug in etm4_cpu_pm_notify():
>
> [ 8.574566] coresight etm0: CPU0: ETM v4.2 initialized
> [ 8.581920] BUG: KASAN: use-after-free in etm4_cpu_pm_notify+0x580/0x2024
> [ 8.581925] Read of size 8 at addr ffffff813304f8c8 by task swapper/3/0
> [ 8.581927]
> [ 8.581934] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G S W 5.4.28 #314
> [ 8.587775] coresight etm1: CPU1: ETM v4.2 initialized
> [ 8.594195] Call trace:
> [ 8.594205] dump_backtrace+0x0/0x188
> [ 8.594209] show_stack+0x20/0x2c
> [ 8.594216] dump_stack+0xdc/0x144
> [ 8.594227] print_address_description+0x3c/0x494
> [ 8.594232] __kasan_report+0x144/0x168
> [ 8.601598] coresight etm2: CPU2: ETM v4.2 initialized
> [ 8.602563] kasan_report+0x10/0x18
> [ 8.602568] check_memory_region+0x1a4/0x1b4
> [ 8.602572] __kasan_check_read+0x18/0x24
> [ 8.602577] etm4_cpu_pm_notify+0x580/0x2024
> [ 8.665945] notifier_call_chain+0x5c/0x90
> [ 8.670166] __atomic_notifier_call_chain+0x90/0xf8
> [ 8.675182] cpu_pm_notify+0x40/0x6c
> [ 8.678858] cpu_pm_enter+0x38/0x80
> [ 8.682451] psci_enter_idle_state+0x34/0x70
> [ 8.686844] cpuidle_enter_state+0xb8/0x20c
> [ 8.691143] cpuidle_enter+0x38/0x4c
> [ 8.694820] call_cpuidle+0x3c/0x68
> [ 8.698408] do_idle+0x1a0/0x280
> [ 8.701729] cpu_startup_entry+0x24/0x28
> [ 8.705768] secondary_start_kernel+0x15c/0x170
> [ 8.710423]
> [ 8.711972] Allocated by task 242:
> [ 8.715473] __kasan_kmalloc+0xf0/0x1ac
> [ 8.719426] kasan_slab_alloc+0x14/0x1c
> [ 8.723375] __kmalloc_track_caller+0x23c/0x388
> [ 8.728040] devm_kmalloc+0x38/0x94
> [ 8.731632] etm4_probe+0x48/0x3c8
> [ 8.735140] amba_probe+0xbc/0x158
> [ 8.738645] really_probe+0x144/0x408
> [ 8.742412] driver_probe_device+0x70/0x140
> [ 8.746716] __device_attach_driver+0x9c/0x110
> [ 8.751287] bus_for_each_drv+0x90/0xd8
> [ 8.755236] __device_attach+0xb4/0x164
> [ 8.759188] device_initial_probe+0x20/0x2c
> [ 8.763490] bus_probe_device+0x34/0x94
> [ 8.767436] device_add+0x34c/0x3e0
> [ 8.771029] amba_device_try_add+0x68/0x440
> [ 8.775332] amba_deferred_retry_func+0x48/0xc8
> [ 8.779997] process_one_work+0x344/0x648
> [ 8.784127] worker_thread+0x2ac/0x47c
> [ 8.787987] kthread+0x128/0x138
> [ 8.791313] ret_from_fork+0x10/0x18
> [ 8.794993]
> [ 8.796532] Freed by task 242:
> [ 8.799684] __kasan_slab_free+0x15c/0x22c
> [ 8.803897] kasan_slab_free+0x10/0x1c
> [ 8.807761] kfree+0x25c/0x4bc
> [ 8.810913] release_nodes+0x240/0x2b0
> [ 8.814767] devres_release_all+0x3c/0x54
> [ 8.818887] really_probe+0x178/0x408
> [ 8.822661] driver_probe_device+0x70/0x140
> [ 8.826963] __device_attach_driver+0x9c/0x110
> [ 8.831539] bus_for_each_drv+0x90/0xd8
> [ 8.835487] __device_attach+0xb4/0x164
> [ 8.839431] device_initial_probe+0x20/0x2c
> [ 8.843732] bus_probe_device+0x34/0x94
> [ 8.847678] device_add+0x34c/0x3e0
> [ 8.851274] amba_device_try_add+0x68/0x440
> [ 8.855576] amba_deferred_retry_func+0x48/0xc8
> [ 8.860240] process_one_work+0x344/0x648
> [ 8.864366] worker_thread+0x2ac/0x47c
> [ 8.868228] kthread+0x128/0x138
> [ 8.871557] ret_from_fork+0x10/0x18
> [ 8.875231]
> [ 8.876782] The buggy address belongs to the object at ffffff813304f800
> [ 8.876782] which belongs to the cache kmalloc-1k of size 1024
> [ 8.889632] The buggy address is located 200 bytes inside of
> [ 8.889632] 1024-byte region [ffffff813304f800, ffffff813304fc00)
> [ 8.901761] The buggy address belongs to the page:
> [ 8.906695] page:ffffffff04ac1200 refcount:1 mapcount:0 mapping:ffffff8146c03800 index:0x0 compound_mapcount: 0
> [ 8.917047] flags: 0x4000000000010200(slab|head)
> [ 8.921799] raw: 4000000000010200 dead000000000100 dead000000000122 ffffff8146c03800
> [ 8.929753] raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
> [ 8.937703] page dumped because: kasan: bad access detected
> [ 8.943433]
> [ 8.944974] Memory state around the buggy address:
> [ 8.949903] ffffff813304f780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [ 8.957320] ffffff813304f800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [ 8.964742] >ffffff813304f880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [ 8.972157] ^
> [ 8.977886] ffffff813304f900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [ 8.985298] ffffff813304f980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [ 8.992713] ==================================================================
>
> Fixes: f188b5e76aae9 ( "coresight: etm4x: Save/restore state across CPU low power states ")
> Reported-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Mike Leach <mike.leach@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-etm4x.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> index 0b2c7c7efacb..d7e19d91ff17 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> @@ -1516,6 +1516,7 @@ static int etm4_probe(struct amba_device *adev, const struct amba_id *id)
> return 0;
>
> err_arch_supported:
> + etmdrvdata[drvdata->cpu] = NULL;
KASAN is once again proving its usefulness - finding a code path like that is
impossible by just looking at the code.
Applied - thanks,
Mathieu
> if (--etm4_count == 0) {
> etm4_cpu_pm_unregister();
>
> --
> 2.24.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2020-05-08 17:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-06 15:53 [PATCH] coresight: etm4x: Fix use-after-free of per-cpu etm drvdata Suzuki K Poulose
2020-05-08 17:56 ` Mathieu Poirier [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=20200508175632.GA3181@xps15 \
--to=mathieu.poirier@linaro.org \
--cc=coresight@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mike.leach@linaro.org \
--cc=saiprakash.ranjan@codeaurora.org \
--cc=suzuki.poulose@arm.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;
as well as URLs for NNTP newsgroup(s).