DBTR: validate trig_count before mapping shared memory in sbi_dbtr_install_trig()

[GraceDyer]

Problem

sbi_dbtr_install_trig() uses the caller-provided trig_count to compute the shared-memory range length before checking whether that count is reasonable:

sbi_hart_protection_map_range((unsigned long)shmem_base,
                              trig_count * sizeof(*entry));

The same trig_count * sizeof(*entry) expression is also used on several cleanup paths. On RV64, a sufficiently large trig_count can make this byte-size calculation wrap, so the mapped range can be smaller than the later loop expects.

The function does check hs->available_trigs < trig_count, but that happens only after the shared-memory mapping and after the first validation loop has already iterated over entries using trig_count.

Observed result

In a local QEMU virt test with DBTR shared memory set up first, the normal control case returned successfully. The overflow case then hit an M-mode trap and did not return before timeout.

Suggested fix

Validate trig_count before using it in the byte-size calculation or in the trigger-entry loop. For example, reject counts larger than the implementation limit before mapping:

if (trig_count > RV_MAX_TRIGGERS)
        return SBI_ERR_INVALID_PARAM;

Scope

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