Re: [PATCH 1/2] hwmon: (coretemp) replace hardcoded core count with dynamic value

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] If `topology_num_cores_per_package()` evaluates to 0, an integer underflow occurs leading to an out-of-bounds write and kernel panic.
- [High] Using the global `topology_num_cores_per_package()` limits the per-package array size, preventing sensor initialization on heterogeneous packages or during CPU hot-add.
--

commit d686b3577dd2107e7452adf6a949cc0720d2213a
Author: Roman Bakshansky <bakshansky.lists@gmail.com>

hwmon: (coretemp) replace hardcoded core count with dynamic value

This commit replaces the hardcoded limit of 512 cores per package with
a dynamic value. It uses topology_num_cores_per_package() to allocate
only the needed amount of memory for core_data.

> diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
> index 6a0d94711eadb..c722b1d8e4804 100644
> --- a/drivers/hwmon/coretemp.c
> +++ b/drivers/hwmon/coretemp.c

[ ... ]

> @@ -485,13 +484,7 @@ init_temp_data(struct platform_data *pdata, unsigned int cpu, int pkg_flag)
>  	struct temp_data *tdata;
>  
>  	if (!pdata->core_data) {
> -		/*
> -		 * TODO:
> -		 * The information of actual possible cores in a package is broken for now.
> -		 * Will replace hardcoded NUM_REAL_CORES with actual per package core count
> -		 * when this information becomes available.
> -		 */
> -		pdata->nr_cores = NUM_REAL_CORES;
> +		pdata->nr_cores = topology_num_cores_per_package();

Since topology_num_cores_per_package() returns a global value that is set
once during boot, could this prevent sensor initialization on heterogeneous
packages or during CPU hot-add?

In asymmetric multi-package architectures where a secondary package has more
cores than the primary, or when virtual CPUs are hot-added, pdata->nr_cores
would be capped at the primary package's boot core count. When initializing
extra cores, ida_alloc_max() would enforce this bound and return -ENOSPC,
silently dropping temperature sensors for valid cores.

Additionally, could topology_num_cores_per_package() return 0 if the CPU
topology is broken or misconfigured by a hypervisor?

> +		pdata->core_data = kzalloc_objs(struct temp_data *,
> +						pdata->nr_cores);
>  		if (!pdata->core_data)
>  			return NULL;

If pdata->nr_cores is 0, kzalloc_objs() will allocate 0 bytes and return the
kernel's ZERO_SIZE_PTR instead of NULL, bypassing this error check.

Later in this function, the index is allocated:

	} else {
		tdata->index = ida_alloc_max(&pdata->ida, pdata->nr_cores - 1, GFP_KERNEL);

If pdata->nr_cores is 0, the maximum bound (0 - 1) evaluates to -1, which
implicitly casts to UINT_MAX. ida_alloc_max() would accept this large bound
and return a valid index.

		if (tdata->index < 0) {
			kfree(tdata);
			return NULL;
		}
		pdata->core_data[tdata->index] = tdata;

Could this result in an attempt to write to the ZERO_SIZE_PTR address,
causing an unhandled page fault and kernel panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260516114253.5466-1-bakshansky.lists@gmail.com?part=1