Re: [PATCH net] ixgbevf: fix use-after-free in VEPA multicast source pruning

Simon Horman
2026-04-16T17:13:53Z

On Wed, Apr 15, 2026 at 12:30:45PM -0400, Michael Bommarito wrote:
> On Wed, Apr 15, 2026 at 12:17 PM Simon Horman <horms@kernel.org> wrote:
> > Sashiko flags a number of issues in the same function that
> > do not seem related to your patch.
> >
> > I'd suggest looking over them if you are interested in
> > follow-up work in this area.
>
> Sure, I'd be happy to keep going here if you're open to more hardening
> patches.

Speaking for myself: I'm happy to review patches that correct bugs.

I'm also happy to review patches that otherwise improve the code.
But I think the Intel people might be able to provide better guidance here.

Please be aware of the Netdev guidance on cleanups:

>
> Two Qs for you:
>
> 1. Do you want smaller patches for each or bigger method-level patches?

The general rule of thumb is one patch per problem.
Personally, I prefer small patches.

>
> 2. Anything on my list below that you would *not* want me touching?
> I'll combine with anything I can find from your Sashiko items

...

> 3. line 2769
> rule: semgrep signed-int-as-size-param-kmalloc
> match: q_vector = kzalloc(size, GFP_KERNEL) (signed size)
> status: untriaged
>
> 4. line 3452
> rule: semgrep signed-int-as-size-param-kmalloc
> match: tx_ring->tx_buffer_info = vmalloc(size) (signed size)
> status: untriaged
>
> 5. line 3530
> rule: semgrep signed-int-as-size-param-kmalloc
> match: rx_ring->rx_buffer_info = vmalloc(size) (signed size)
> status: untriaged

I didn't look closely, but: I am a little skeptical that these signed size
problems are worth fixing; while the other items on your list look worth
fixing to me.

...