On 11/24/25 3:01 PM, Michael S. Tsirkin wrote:
> On Wed, Nov 19, 2025 at 01:15:16PM -0600, Daniel Jurgens wrote:
>> When probing a virtnet device, attempt to read the flow filter
>> + for (i = 0; i < ff->ff_mask->count; i++) {
>> + if (sel->length > MAX_SEL_LEN) {
>> + WARN_ON_ONCE(true);
>> + err = -EINVAL;
>> + goto err_ff_action;
>> + }
>> + real_ff_mask_size += sizeof(struct virtio_net_ff_selector) +
>> sel->length;
>> + if (real_ff_mask_size > ff_mask_size) {
>> + WARN_ON_ONCE(true);
>> + err = -EINVAL;
>> + goto err_ff_action;
>> + }
>> + sel = (void *)sel + sizeof(*sel) + sel->length;
>> + }
>
>
> I am trying to figure out whether this is safe with
> a buggy/malicious device which passes count > VIRTIO_NET_FF_MASK_TYPE_MAX
It should be safe. The count is u8, so it's bounded at a low number of
iterations. We shouldn't overrun the allocated memory with the existing
checks.
>
>
> In fact, what if a future device supports more types?
> There does not need to be a negotiation about what driver
> needs, right?
>
I think I should a check of the type, check that each type is only set
once. And break if I hit a type >= VIRTIO_NET_FF_MASK_TYPE.
I think that should be sufficient. If the spec is ever expanded to
include more selector types it would have to insist they come after the
existing ones. The MAX_SEL_LEN check will come after the break on unkown
type.
Then it should be able to maintain compatibility with newer controllers.
>
>> +
