RE: [Intel-wired-lan] [PATCH net] ixgbevf: fix use-after-free in VEPA multicast source pruning

[Romanowski, Rafal]

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@xxxxxxxxxx> On Behalf Of Simon
> Horman
> Sent: Thursday, April 16, 2026 7:14 PM
> To: Michael Bommarito <michael.bommarito@xxxxxxxxx>
> Cc: intel-wired-lan@xxxxxxxxxxxxxxxx; Nguyen, Anthony L
> <anthony.l.nguyen@xxxxxxxxx>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@xxxxxxxxx>; Andrew Lunn <andrew+netdev@xxxxxxx>;
> David S. Miller <davem@xxxxxxxxxxxxx>; Eric Dumazet
> <edumazet@xxxxxxxxxx>; Jakub Kicinski <kuba@xxxxxxxxxx>; Paolo Abeni
> <pabeni@xxxxxxxxxx>; netdev@xxxxxxxxxxxxxxx; stable@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx
> Subject: Re: [Intel-wired-lan] [PATCH net] ixgbevf: fix use-after-free in VEPA
> multicast source pruning
> 
> 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@xxxxxxxxxx> 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.
> 
> ...

Tested-by: Rafal Romanowski <rafal.romanowski@xxxxxxxxx>