OpenSBI mpxy: base_attr_id + attr_count can wrap and bypass range checks

[neosys007]

Title: OpenSBI mpxy: base_attr_id + attr_count can wrap and bypass range checks

Current upstream OpenSBI master (checked in a local clone at 6d5b2b9 on 2026-03-21) still computes attribute end IDs in u32 and then uses the result for range checks:

• lib/sbi/sbi_mpxy.c: sbi_mpxy_read_attrs() and sbi_mpxy_write_attrs()
• lib/utils/mpxy/fdt_mpxy_rpmi_mbox.c: mpxy_mbox_read_attributes() and mpxy_mbox_write_attributes()

The core pattern is:

u32 end_id = base_attr_id + attr_count - 1;
if (end_id >= MAX_ID)
    return SBI_EBAD_RANGE;

or equivalent. The problem is that both base_attr_id and attr_count are caller-controlled u32 values. When base_attr_id is close to UINT32_MAX and attr_count is greater than 1, the addition wraps before the range check runs. That can make end_id look small even though the requested range is actually huge. In the mpxy helpers, the code then uses attr_id2index(base_attr_id) and copies attributes from or to the array starting at that wrapped index, so the overflowed range check can lead to out-of-bounds access in the message-protocol attribute array.

The current sanity check only validates that attr_count is non-zero and not larger than the shared-memory size in units of ATTR_SIZE. It does not prevent wraparound in base_attr_id + attr_count - 1, so the bug is still present in current head.

Expected behavior: the range calculation should use overflow-safe arithmetic, or the code should explicitly check base_attr_id > MAX - (attr_count - 1) before adding.

Actual behavior: the u32 addition can wrap and allow a bogus range to pass the bounds check, which then drives out-of-bounds attribute indexing/copying.

This looks like a security-relevant memory-safety bug in the OpenSBI mpxy path.