DBTR: avoid unsigned range-check wraparound in sbi_dbtr_read_trig()

Problem

sbi_dbtr_read_trig() currently validates the requested trigger range with:

if (trig_idx_base >= hs->total_trigs ||
    trig_idx_base + trig_count >= hs->total_trigs)
        return SBI_ERR_INVALID_PARAM;

Both trig_idx_base and trig_count are unsigned values. Their addition can wrap before the comparison, allowing an out-of-range request to pass the guard.

The function then uses trig_count for shared-memory mapping and entry iteration.

Observed result

In a local RV64 QEMU virt test with DBTR enabled, the normal control case returned successfully. An overflow-inducing boundary case passed the range check and subsequently caused an M-mode store access fault while writing DBTR shared memory.

Expected result

A request whose range exceeds hs->total_trigs, or whose endpoint cannot be represented, should be rejected before shared-memory mapping or iteration.

Suggested fix

Avoid forming the unchecked sum. After validating trig_idx_base, compare trig_count against hs->total_trigs - trig_idx_base, or use an equivalent checked-add helper.

The endpoint comparison should also be kept consistent with the intended DBTR specification semantics.

Scope

I have validated the firmware fault behavior on QEMU. I am not claiming a broader impact beyond this memory-safety and availability issue.

Start at sbi_dbtr_read_trig() and inspect how its range validation feeds shared-memory mapping and entry iteration. Run the local RV64 QEMU virt test with DBTR enabled, including the normal and overflow-inducing boundary cases. Done means requests beyond hs->total_trigs or with an unrepresentable endpoint are rejected before mapping or iteration, with endpoint semantics consistent with the DBTR specification.