Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:
- [Medium] Un-ratelimited `dev_warn` on invalid CXL device input can lead to 
log flooding and Denial of Service.
--

commit 2eb192d0644cd71e7046e47b82d5b1422081590e
Author: Ira Weiny <[email protected]>

cxl/mem: Drop misaligned DCD extent groups

This commit adds an alignment check to cxl_add_pending() to ensure that
extents in a tag group are aligned to the dax region's mapping granularity.
Misaligned extents now cause the entire group to be dropped.

> diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
> index 08f51b8807c06..14ba263044f08 100644
> --- a/drivers/cxl/core/mbox.c
> +++ b/drivers/cxl/core/mbox.c

[ ... ]

> @@ -1395,11 +1410,38 @@ static int cxl_realize_group(struct cxl_memdev_state 
> *mds, const uuid_t *tag,
>       return group_cnt;
>  }
>  
> +/*
> + * Validate a tag @group before realizing it.  Returns 0 if the group may be
> + * added, or a negative errno if it must be dropped.  Further gates layer in
> + * here in later commits.
> + */
> +static int cxl_validate_group(struct cxl_memdev_state *mds, const uuid_t 
> *tag,
> +                           struct list_head *group)
> +{
> +     struct device *dev = mds->cxlds.dev;
> +     struct cxl_extent_list_node *pos;
> +
> +     /* Alignment gate — drop the group if any member fails */
> +     list_for_each_entry(pos, group, list) {
> +             if (!cxl_extent_dcd_aligned(pos->extent)) {
> +                     dev_warn(dev,
> +                              "Tag %pUb: dropping group, extent DPA:%#llx 
> LEN:%#llx not %#llx-aligned\n",
> +                              tag,
> +                              le64_to_cpu(pos->extent->start_dpa),
> +                              le64_to_cpu(pos->extent->length),
> +                              (u64)PMD_SIZE);

[Severity: Medium]
Could this un-ratelimited dev_warn() lead to log flooding?

If a malfunctioning or compromised CXL device rapidly sends DCD_ADD_CAPACITY
events with misaligned extents, it appears this could spam the kernel log
and cause high CPU overhead.

Should this use dev_warn_ratelimited() instead, since it is driven by
untrusted device input?

> +                     return -EINVAL;
> +             }
> +     }
> +
> +     return 0;
> +}

-- 
Sashiko AI review · 
https://sashiko.dev/#/patchset/[email protected]?part=15

Reply via email to