Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] This problem wasn't introduced by this patch, but elevating the math into a generic helper codifies a vulnerability: boundary calculations in `memory_block_aligned_range()` can mathematically underflow or overflow, bypassing the recommended validity check and producing massive invalid ranges. -- commit 6ed2cd40240e54e5a9638798bd15e535e425a3da Author: Gregory Price <[email protected]> mm/memory: add memory_block_aligned_range() helper Memory hotplug operations require ranges aligned to memory block boundaries. This is a generic operation for hotplug. Add memory_block_aligned_range() as a common helper in <linux/memory.h> that aligns the start address up and end address down to memory block boundaries. Update dax/kmem to use this helper. > diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c > index a18e2b968e4da..592171ec10f49 100644 > --- a/drivers/dax/kmem.c > +++ b/drivers/dax/kmem.c [ ... ] > @@ -33,9 +33,7 @@ static int dax_kmem_range(struct dev_dax *dev_dax, int i, > struct range *r) > struct dev_dax_range *dax_range = &dev_dax->ranges[i]; > struct range *range = &dax_range->range; > > - /* memory-block align the hotplug range */ > - r->start = ALIGN(range->start, memory_block_size_bytes()); > - r->end = ALIGN_DOWN(range->end + 1, memory_block_size_bytes()) - 1; > + *r = memory_block_aligned_range(range); > if (r->start >= r->end) { > r->start = range->start; > r->end = range->end; [ ... ] > diff --git a/include/linux/memory.h b/include/linux/memory.h > index 463dc02f6cff0..9f5ef0309f773 100644 > --- a/include/linux/memory.h > +++ b/include/linux/memory.h [ ... ] > @@ -100,6 +101,27 @@ int arch_get_memory_phys_device(unsigned long start_pfn); > unsigned long memory_block_size_bytes(void); > int set_memory_block_size_order(unsigned int order); > > +/** > + * memory_block_aligned_range - align a physical address range to memory > blocks > + * @range: the input range to align > + * > + * Aligns the start address up and the end address down to memory block > + * boundaries. This is required for memory hotplug operations which must > + * operate on memory-block aligned ranges. > + * > + * Returns the aligned range. Callers should check that the returned > + * range is valid (aligned.start < aligned.end) before using it. > + */ > +static inline struct range memory_block_aligned_range(const struct range > *range) > +{ > + struct range aligned; > + > + aligned.start = ALIGN(range->start, memory_block_size_bytes()); > + aligned.end = ALIGN_DOWN(range->end + 1, memory_block_size_bytes()) - 1; [Severity: High] This isn't a bug introduced by this patch, but elevating the math into a generic helper codifies an issue. Could this boundary calculation underflow and produce massive invalid ranges? If a caller provides an unaligned physical address range that falls entirely before the first memory block boundary, for example when range->end + 1 < memory_block_size_bytes(), the ALIGN_DOWN calculation evaluates to 0. Subtracting 1 then causes aligned.end to underflow to U64_MAX. While it is physically unlikely for a DAX device to be located below 128MB, an edge case near physical address 0 triggers this underflow. When this happens, the invalid range check in dax_kmem_range() is bypassed: drivers/dax/kmem.c:dax_kmem_range() { ... *r = memory_block_aligned_range(range); if (r->start >= r->end) { ... } Because r->end evaluates to U64_MAX and aligned.start aligns up to 128MB (if range->start > 0), the check 128MB >= U64_MAX is false. This incorrectly signals the empty range as valid and aligned. In contrast, an empty range in a higher memory block correctly fails this check. If this underflowed range is then passed to hotplug APIs like __add_memory_driver_managed(), could it cause an immediate OOM and kernel crash as the system attempts to allocate tracking structures for millions of memory blocks? > + > + return aligned; > +} -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
