From: Beata Michalska <beata.michalska@arm.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, ionela.voinescu@arm.com,
vanshikonda@os.amperecomputing.com, will@kernel.org,
catalin.marinas@arm.com, vincent.guittot@linaro.org,
sumitg@nvidia.com, yang@os.amperecomputing.com,
lihuisong@huawei.com, viresh.kumar@linaro.org
Subject: Re: [PATCH v5 2/5] arm64: amu: Rule out potential use after free
Date: Thu, 18 Apr 2024 17:55:43 +0200 [thread overview]
Message-ID: <ZiFCfwEvdJxg6Hth@arm.com> (raw)
In-Reply-To: <20240418105052.zvkomz5yeayie4ph@bogus>
On Thu, Apr 18, 2024 at 11:50:52AM +0100, Sudeep Holla wrote:
> On Wed, Apr 17, 2024 at 10:38:45AM +0100, Beata Michalska wrote:
> > For the time being, the amu_fie_cpus cpumask is being exclusively used
> > by the AMU-related internals of FIE support and is guaranteed to be
> > valid on every access currently made. Still the mask is not being
> > invalidated on one of the error handling code paths, which leaves
> > a soft spot with potential risk of uaf for CPUMASK_OFFSTACK cases.
> > To make things sound, set the cpumaks pointer explicitly to NULL upon
> > failing to register the cpufreq notifier.
> > Note that, due to the quirks of CPUMASK_OFFSTACK, this change needs to
> > be wrapped with grim ifdefing (it would be better served by
> > incorporating this into free_cpumask_var ...)
> >
>
> Yes it doesn't look neat.
>
> > Signed-off-by: Beata Michalska <beata.michalska@arm.com>
> > ---
> > arch/arm64/kernel/topology.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> > index 1a2c72f3e7f8..3c814a278534 100644
> > --- a/arch/arm64/kernel/topology.c
> > +++ b/arch/arm64/kernel/topology.c
> > @@ -244,8 +244,12 @@ static int __init init_amu_fie(void)
> >
> > ret = cpufreq_register_notifier(&init_amu_fie_notifier,
> > CPUFREQ_POLICY_NOTIFIER);
> > - if (ret)
> > + if (ret) {
> > free_cpumask_var(amu_fie_cpus);
> > +#ifdef CONFIG_CPUMASK_OFFSTACK
> > + amu_fie_cpus = NULL;
> > +#endif
> > + }
>
> Instead of this #ifdeffery, I was wondering if we can actually do the
> allocation in init_amu_fie_callback() the first time it gets called
> checking if amu_fie_cpus is NULL. init_amu_fie_callback() must get called
> only if the cpufreq_register_notifier() succeeds right ?
>
Delayed allocation ... I guess this will do the trick.
> Also I don't see anyone calling amu_fie_setup(), so where do you think
> the possible use after free could occur for amu_fie_cpus. Just thinking
> out loud to check if I missed anything.
>
You haven't missed anything. Currently the uaf is purely theoretical as the code
that relies on that mask will only be executed if we have succeeded to register
the amu fie support: so far so good.
This change is required for following patches, where that mask is being used to
determine if given CPU has been setup with AMU counters, and as such there needs
to be a safe way to validate it (at any time) by arch_freq_get_on_cpu and
arch_cpu_idle_enter (patches 3/5 & 4/5): both will be called from outside the
FIE. Without this change, if cpufreq_register_notifier fails in init_amu_fie,
we will have amu_fie_cpus pointing to released memory.
Hope that makes things more clear.
---
BR
Beata
> --
> Regards,
> Sudeep
next prev parent reply other threads:[~2024-04-18 15:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 9:38 [PATCH v5 0/5] Add support for AArch64 AMUv1-based arch_freq_get_on_cpu Beata Michalska
2024-04-17 9:38 ` [PATCH v5 1/5] arch_topology: init capacity_freq_ref to 0 Beata Michalska
2024-04-18 10:50 ` Sudeep Holla
2024-04-17 9:38 ` [PATCH v5 2/5] arm64: amu: Rule out potential use after free Beata Michalska
2024-04-18 10:50 ` Sudeep Holla
2024-04-18 15:55 ` Beata Michalska [this message]
2024-04-24 10:25 ` Sudeep Holla
2024-04-25 14:27 ` Beata Michalska
2024-05-07 7:24 ` Ionela Voinescu
2024-04-17 9:38 ` [PATCH v5 3/5] arm64: Provide an AMU-based version of arch_freq_get_on_cpu Beata Michalska
2024-04-18 1:39 ` Vanshidhar Konda
2024-04-26 10:50 ` Beata Michalska
2024-04-17 9:38 ` [PATCH v5 4/5] arm64: Update AMU-based frequency scale factor on entering idle Beata Michalska
2024-04-17 9:38 ` [PATCH v5 5/5] cpufreq: Use arch specific feedback for cpuinfo_cur_freq Beata Michalska
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=ZiFCfwEvdJxg6Hth@arm.com \
--to=beata.michalska@arm.com \
--cc=catalin.marinas@arm.com \
--cc=ionela.voinescu@arm.com \
--cc=lihuisong@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sudeep.holla@arm.com \
--cc=sumitg@nvidia.com \
--cc=vanshikonda@os.amperecomputing.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=will@kernel.org \
--cc=yang@os.amperecomputing.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