On Mon, 6 Jul 2026 at 23:44, Klaus Jensen <[email protected]> wrote:
>
> From: Jesper Wendel Devantier <[email protected]>
>
> Addresses an issue reported whereby user-provided event type values
> could trigger two issues:
>
> 1. if provided event_type == 0xff -> out-of-bounds access
>
> 2. if provided event_type > 7 -> generate a value too large for the
> u8 event mask.
>
> This patch fixes (1) by correctly adjusting the length of the look-up
> array to be 256 values.
> This patch fixes (2) by:
> a. changing the event_type mask to 64bit, matching
> NvmeRuHandle.event_filter
Hi; this change has caused Coverity to notice another
pre-existing problem in this code (CID 1663674):
> @@ -6492,9 +6488,9 @@ static uint16_t nvme_set_feature_fdp_events(NvmeCtrl
> *n, NvmeNamespace *ns,
> uint8_t noet = (cdw11 >> 16) & 0xff;
> uint16_t ret, ruhid;
> uint8_t enable = le32_to_cpu(cmd->cdw12) & 0x1;
> - uint8_t event_mask = 0;
> + uint64_t event_mask = 0;
event_mask is (now) 64 bits...
> for (i = 0; i < noet; i++) {
> + /*
> + * We ignore requests to enable tracking of unsupported FDP event
> types
> + */
> + uint8_t event_type = events[i];
> + uint8_t shift = nvme_fdp_evf_shifts[event_type];
> + if (!shift && event_type) {
> + continue;
> + }
> event_mask |= (1 << nvme_fdp_evf_shifts[events[i]]);
...but the shift here is done with 32-bit arithmetic.
So for the cases in the table where the shift count is
32 or 33 we will shift the 1 bit off the top of the
value and lose it.
Using "1ULL << ..." fixes this.
thanks
-- PMM
