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.
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:
The core pattern is:
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.