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 <[email protected]>

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/[email protected]?part=4

Reply via email to