Re: [RFC PATCH v1 1/1] acpi/hmat: preserve hmat_adist_nb notifier block

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Integer overflow during the ACPI HMAT locality table size calculation bypasses bounds checking and allows out-of-bounds memory reads.
--

commit 69d5452dda77c729836d9ff08f4b38f9cff8d91b
Author: Alejandro Lucero <alucerop@amd.com>

acpi/hmat: preserve hmat_adist_nb notifier block

Remove __meminitdata from hmat_adist_nb declaration preserving it even
when CONFIG_MEMORY_HOTPLUG is not set. Otherwise further notifier
registrations using register_mt_adistance_algorithm() will find a
notifier chain likely corrupted. This is the case when a CXL Type2
driver will load after kernel initialization and a CXL region created from
its committed HDM decoders registers an mt_adistance_algorithm notifier.

> diff --git a/drivers/acpi/numa/hmat.c b/drivers/acpi/numa/hmat.c
> index 9792dc3947561..3006789ae31fe 100644
> --- a/drivers/acpi/numa/hmat.c
> +++ b/drivers/acpi/numa/hmat.c

[ ... ]

[Severity: High]
This is a pre-existing issue, but I noticed a regression where an integer
overflow during the ACPI HMAT locality table size calculation could bypass
bounds checking.

When parsing the locality table, total_size is declared as a 32-bit unsigned
integer:

drivers/acpi/numa/hmat.c:hmat_parse_locality() {
	...
	unsigned int init, targ, total_size, ipds, tpds;
	...
	ipds = hmat_loc->number_of_initiator_Pds;
	tpds = hmat_loc->number_of_target_Pds;
	total_size = sizeof(*hmat_loc) + sizeof(*entries) * ipds * tpds +
		     sizeof(*inits) * ipds + sizeof(*targs) * tpds;
	if (hmat_loc->header.length < total_size) {
		pr_notice("Unexpected locality header length:%u, minimum required:%u\n",
			 hmat_loc->header.length, total_size);
		return -EINVAL;
	}
	...

If abnormally large values are provided for ipds and tpds, could the
intermediate arithmetic be truncated when assigned to total_size?

If this wraps around 32-bit boundaries, wouldn't it result in a small
total_size that bypasses the hmat_loc->header.length check?

Later loops use the unbounded ipds and tpds variables:

drivers/acpi/numa/hmat.c:hmat_parse_locality() {
	...
	for (init = 0; init < ipds; init++) {
		alloc_memory_initiator(inits[init]);
		for (targ = 0; targ < tpds; targ++) {
			value = hmat_normalize(entries[init * tpds + targ],
					       hmat_loc->entry_base_unit,
					       type);
	...
}

Does this lead to out-of-bounds memory reads if the total_size calculation
overflows?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630143507.30193-1-alejandro.lucero-palau@amd.com?part=1