[PATCH net-next] net: airoha: Validate egress gdm port in airoha_ppe_foe_entry_prepare()

[Lorenzo Bianconi]

> On Wed, Mar 12, 2025 at 05:22:47PM +0100, Lorenzo Bianconi wrote:
> > > On Wed, Mar 12, 2025 at 03:54:21PM +0100, Lorenzo Bianconi wrote:
> > > > > On Wed, Mar 12, 2025 at 12:31:46PM +0100, Lorenzo Bianconi wrote:
> > > > > > The system occasionally crashes dereferencing a NULL pointer when it is
> > > > > > forwarding constant, high load bidirectional traffic.
> 
> [...]
> 
> > > 
> > > > 
> > > > > 
> > > > > > +		if (!eth->ports[i])
> > > > > > +			continue;
> > > > > 
> > > > > Isn't this NULL check redundant?
> > > > > In the second check you compare the table element to a real pointer.
> > > > 
> > > > Can netdev_priv() be NULL? If not, I guess we can remove this check.
> > > 
> > > I guess it shouldn't be NULL since "devm_alloc_etherdev_mqs()" was
> > > called, but I'm not 100% sure if there are any special cases for the "airoha"
> > > driver. Maybe in such cases it would be better to check for the netdev_priv?
> > > Anyway, such checks seem a bit too defensive to me.
> > 
> > the dev pointer can be allocated even outside of airoha_eth driver.
> > This pointer is provided by the flowtable.
> > I guess we can drop the NULL pointer check above, and do something like:
> > 
> > 	if (port && eth->ports[i] == port)
> > 		return 0;
> > 
> > what do you think?
> > 
> > Regards,
> > Lorenzo
> > 
> 
> I think if there's a risk that 'port' can be NULL, it looks like a
> reasonable solution and I'm OK with that.

I guess you are right. I do not think netdev_priv pointer can be NULL since,
even if size_priv is 0, it will just point to the end of the netdevice struct.
I will repost just doing:

	if (eth->ports[i] == port)
		return 0;

Regards,
Lorenzo

> 
> Thanks,
> Michal
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20250313/3c7bf57b/attachment.sig>