[PATCH v4 4/5] mm/memory-failure: efi: answer whether a range is poisoned

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Adjusting `start` without proportionally shrinking `size` shifts the checked memory range out of bounds, causing false positive poison detection.
--

commit b492314fda14ef47eff8ff738b90a4749a490163
Author: Breno Leitao <leitao at debian.org>

mm/memory-failure: efi: answer whether a range is poisoned

This commit introduces range_contains_poisoned_memory() which allows the
page allocator to query whether a memory block overlaps with regions
recorded as poisoned by an earlier kernel via EFI.

> diff --git a/drivers/firmware/efi/poison.c b/drivers/firmware/efi/poison.c
> index c18edf111c710..e16d43f4438ee 100644
> --- a/drivers/firmware/efi/poison.c
> +++ b/drivers/firmware/efi/poison.c
[ ... ]
> +/* Does the range cover a unit an earlier kernel recorded as bad? */
> +bool range_contains_poisoned_memory(phys_addr_t start, unsigned long size)
> +{
> +	struct linux_efi_poisoned_memory *pm = efi_poisoned_memory();
> +	u64 first, last, nbits;
> +
> +	if (!pm)
> +		return false;
> +
> +	nbits = pm->size * BITS_PER_BYTE;
> +
> +	if (start + size <= pm->phys_base)
> +		return false;
> +	if (start < pm->phys_base)
> +		start = pm->phys_base;
> +
> +	first = (start - pm->phys_base) / pm->unit_size;
> +	if (first >= nbits)
> +		return false;
> +
> +	last = (start + size - 1 - pm->phys_base) / pm->unit_size;

[Severity: High]
When start is clamped to pm->phys_base earlier in this function, size is
not proportionally decreased. Does this result in an end boundary calculation
that exceeds the originally requested range?

If the allocator queries a block that starts before the EFI poisoned memory
table (start < pm->phys_base) but extends into it, the unadjusted size added
to the newly shifted start will push the last bit beyond the intended region. 
Could this out-of-bounds query cause false positive poison detections for
healthy memory that resides just after the requested block?

> +	last = min(last, nbits - 1);
> +
> +	return find_next_bit(pm->bitmap, last + 1, first) <= last;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909-hwpoison-kho-v4-0-359313564495@debian.org?part=4