All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Michael Bommarito <michael.bommarito@gmail.com>
Cc: intel-wired-lan@lists.osuosl.org,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, stable@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH net] ixgbevf: fix use-after-free in VEPA multicast source pruning
Date: Thu, 16 Apr 2026 18:13:49 +0100	[thread overview]
Message-ID: <20260416171349.GC863718@horms.kernel.org> (raw)
In-Reply-To: <CAJJ9bXwQyd-cZ0h_FCNj29GZYpXyCBu444VhLGLZkf1bWYqoKQ@mail.gmail.com>

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.

...

WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Michael Bommarito <michael.bommarito@gmail.com>
Cc: intel-wired-lan@lists.osuosl.org,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, stable@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] ixgbevf: fix use-after-free in VEPA multicast source pruning
Date: Thu, 16 Apr 2026 18:13:49 +0100	[thread overview]
Message-ID: <20260416171349.GC863718@horms.kernel.org> (raw)
In-Reply-To: <CAJJ9bXwQyd-cZ0h_FCNj29GZYpXyCBu444VhLGLZkf1bWYqoKQ@mail.gmail.com>

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.

...

  reply	other threads:[~2026-04-16 17:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-13 18:24 [Intel-wired-lan] [PATCH net] ixgbevf: fix use-after-free in VEPA multicast source pruning Michael Bommarito
2026-04-13 18:24 ` Michael Bommarito
2026-04-15 16:17 ` [Intel-wired-lan] " Simon Horman
2026-04-15 16:17   ` Simon Horman
2026-04-15 16:30   ` [Intel-wired-lan] " Michael Bommarito
2026-04-15 16:30     ` Michael Bommarito
2026-04-16 17:13     ` Simon Horman [this message]
2026-04-16 17:13       ` Simon Horman
2026-05-11  9:40       ` [Intel-wired-lan] " Romanowski, Rafal
2026-05-11  9:40         ` Romanowski, Rafal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260416171349.GC863718@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.bommarito@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.