All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Gregory Price" <gourry@gourry.net>
Cc: linux-cxl@vger.kernel.org, nvdimm@lists.linux.dev
Subject: Re: [PATCH v5 1/9] mm/memory: add memory_block_aligned_range() helper
Date: Wed, 24 Jun 2026 15:08:31 +0000	[thread overview]
Message-ID: <20260624150832.AE15F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260624145744.3532049-2-gourry@gourry.net>

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 <gourry@gourry.net>

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/20260624145744.3532049-1-gourry@gourry.net?part=1

  reply	other threads:[~2026-06-24 15:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-24 14:57 [PATCH v5 0/9] dax/kmem: atomic whole-device hotplug via sysfs Gregory Price
2026-06-24 14:57 ` [PATCH v5 1/9] mm/memory: add memory_block_aligned_range() helper Gregory Price
2026-06-24 15:08   ` sashiko-bot [this message]
2026-06-24 14:57 ` [PATCH v5 2/9] mm/memory_hotplug: pass online_type to online_memory_block() via arg Gregory Price
2026-06-24 16:28   ` Gupta, Pankaj
2026-06-24 14:57 ` [PATCH v5 3/9] mm/memory_hotplug: export mhp_get_default_online_type Gregory Price
2026-06-24 14:57 ` [PATCH v5 4/9] mm/memory_hotplug: add __add_memory_driver_managed() with online_type arg Gregory Price
2026-06-24 16:41   ` Gupta, Pankaj
2026-06-24 14:57 ` [PATCH v5 5/9] mm/memory_hotplug: offline_and_remove_memory_ranges() Gregory Price
2026-06-24 15:11   ` sashiko-bot
2026-06-24 14:57 ` [PATCH v5 6/9] dax: plumb hotplug online_type through dax Gregory Price
2026-06-24 15:12   ` sashiko-bot
2026-06-24 14:57 ` [PATCH v5 7/9] dax/kmem: extract hotplug/hotremove helper functions Gregory Price
2026-06-24 15:09   ` sashiko-bot
2026-06-24 14:57 ` [PATCH v5 8/9] dax/kmem: add sysfs interface for atomic whole-device hotplug Gregory Price
2026-06-24 15:11   ` sashiko-bot
2026-06-24 14:57 ` [PATCH v5 9/9] selftests/dax: add dax/kmem hotplug sysfs regression test Gregory Price
2026-06-24 15:12   ` sashiko-bot
2026-06-24 18:59 ` [PATCH v5 0/9] dax/kmem: atomic whole-device hotplug via sysfs Gregory Price

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260624150832.AE15F1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=gourry@gourry.net \
    --cc=linux-cxl@vger.kernel.org \
    --cc=nvdimm@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.