Re: Comparison of different-width ints in ixg(4)

[Mario Campos <mario.andres.campos%gmail.com@localhost>]

On Sat, Oct 8, 2022 at 1:00 PM Taylor R Campbell
<campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
>
> > Date: Sat, 8 Oct 2022 10:58:58 -0500
> > From: Mario Campos <mario.andres.campos%gmail.com@localhost>
> >
> > I ran a SAST tool, CodeQL, against trunk and found a couple of
> > instances (below) where the 16-bit integer `i` is compared to the
> > 32-bit integer `max_rx_queues` or `max_tx_queues` in ixg(4). If
> > `max_rx_queues` (or `max_tx_queues`) is sufficiently large, it could
> > lead to an infinite loop.
> >
> > sys/dev/pci/ixgbe/ixgbe_vf.c:280
> > sys/dev/pci/ixgbe/ixgbe_vf.c:284
> > sys/dev/pci/ixgbe/ixgbe_common.c:1158
> > sys/dev/pci/ixgbe/ixgbe_common.c:1162
>
> Cool.  I don't think this case is a bug because the quantities in
> question are bounded by IXGBE_VF_MAX_TX/RX_QUEUES, which are both 8.
> But it would be reasonable to use u32 or even just unsigned for this.
> Did this tool turn anything else up?

Ah, great! I also think it would still be an improvement, if only as a
means of defensive programming should IXGBE_VF_MAX_TX/RX_QUEUES ever
be increased.

There were actually over 3400+ results -- though I haven't sifted
through all of it yet. If anyone is interested in reading the report,
I can share it as a SARIF (basically, JSON) file. Or I can grant
access to my GitHub repo, mario-campos/netbsd, where I performed the
scan. Of course, a third option is to replicate my work (in the repo)
and reproduce the results.