linux-kernel - Re: [PATCH v9 3/5] arm64: amu: Delay allocating cpumask for AMU FIE support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <d44f53b1-c028-45c9-b3e9-cc0afd9925f2@linux.microsoft.com>
Date: Fri, 24 Jan 2025 10:18:08 +0530
From: Prasanna Kumar T S M <ptsm@...ux.microsoft.com>
To: Beata Michalska <beata.michalska@....com>, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-pm@...r.kernel.org,
 ionela.voinescu@....com, sudeep.holla@....com, will@...nel.org,
 catalin.marinas@....com, rafael@...nel.org, viresh.kumar@...aro.org
Cc: sumitg@...dia.com, yang@...amperecomputing.com,
 vanshikonda@...amperecomputing.com, lihuisong@...wei.com,
 zhanjie9@...ilicon.com
Subject: Re: [PATCH v9 3/5] arm64: amu: Delay allocating cpumask for AMU FIE
 support


On 21-01-2025 14:14, 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 theoretical risk of UAF for CPUMASK_OFFSTACK cases.
> To make things sound, delay allocating said cpumask
> (for CPUMASK_OFFSTACK) avoiding otherwise nasty sanitising case failing
> to register the cpufreq policy notifications.
>
> Signed-off-by: Beata Michalska <beata.michalska@....com>
> ---
>   arch/arm64/kernel/topology.c | 22 ++++++++++------------
>   1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> index 1a2c72f3e7f8..cb180684d10d 100644
> --- a/arch/arm64/kernel/topology.c
> +++ b/arch/arm64/kernel/topology.c
> @@ -194,12 +194,19 @@ static void amu_fie_setup(const struct cpumask *cpus)
>   	int cpu;
>   
>   	/* We are already set since the last insmod of cpufreq driver */
> -	if (unlikely(cpumask_subset(cpus, amu_fie_cpus)))
> +	if (cpumask_available(amu_fie_cpus) &&
> +	    unlikely(cpumask_subset(cpus, amu_fie_cpus)))
>   		return;
>   
> -	for_each_cpu(cpu, cpus) {
> +	for_each_cpu(cpu, cpus)
>   		if (!freq_counters_valid(cpu))
>   			return;
> +
> +	if (!cpumask_available(amu_fie_cpus) &&
> +	    !zalloc_cpumask_var(&amu_fie_cpus, GFP_KERNEL)) {
> +		WARN_ONCE(1, "Failed to allocate FIE cpumask for CPUs[%*pbl]\n",
> +			  cpumask_pr_args(cpus));
> +		return;
>   	}
>   
>   	cpumask_or(amu_fie_cpus, amu_fie_cpus, cpus);
> @@ -237,17 +244,8 @@ static struct notifier_block init_amu_fie_notifier = {
>   
>   static int __init init_amu_fie(void)
>   {
> -	int ret;
> -
> -	if (!zalloc_cpumask_var(&amu_fie_cpus, GFP_KERNEL))
> -		return -ENOMEM;
> -
> -	ret = cpufreq_register_notifier(&init_amu_fie_notifier,
> +	return cpufreq_register_notifier(&init_amu_fie_notifier,
>   					CPUFREQ_POLICY_NOTIFIER);
> -	if (ret)
> -		free_cpumask_var(amu_fie_cpus);
> -
> -	return ret;
>   }
>   core_initcall(init_amu_fie);
>   

This patch appears useful, irrespective of the feature introduced by 
this series. Isn't it? Can you please carve out this into an individual 
patch?

The change looks good to me.

Reviewed-by: Prasanna Kumar T S M <ptsm@...ux.microsoft.com>.

Please feel free to add my reviewed-by tag even if you are carving this 
patch out.