Re: [PATCH] rocker: Fix memory leak in ofdpa_port_fdb()

[Jacob Keller <jacob.e.keller@intel.com>]

On 6/15/2026 6:32 PM, Ziran Zhang wrote:
> In ofdpa_port_fdb(), the hash_del() only unlinks the node from
> hash table, but does not free it.
> 
> Fix this by adding kfree(found) after the !found == removing check,
> where the pointer value is no longer needed.
> 
> Found by Coccinelle kfree script.
> 
> Signed-off-by: Ziran Zhang <zhangcoder@yeah.net>
> ---
>  drivers/net/ethernet/rocker/rocker_ofdpa.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/ethernet/rocker/rocker_ofdpa.c b/drivers/net/ethernet/rocker/rocker_ofdpa.c
> index 66a8ae67c..15d19a8a1 100644
> --- a/drivers/net/ethernet/rocker/rocker_ofdpa.c
> +++ b/drivers/net/ethernet/rocker/rocker_ofdpa.c
> @@ -1924,6 +1924,9 @@ static int ofdpa_port_fdb(struct ofdpa_port *ofdpa_port,
>  		flags |= OFDPA_OP_FLAG_REFRESH;
>  	}
>  
> +	if (found && removing)
> +		kfree(found);
> +
>  	return ofdpa_port_fdb_learn(ofdpa_port, flags, addr, vlan_id);
>  }
>  

I looked at the surrounding code and I can't find any other place that
would have released the found entry, so this does indeed look like a
memory leak.

You could potentially verify it using the slab allocator stats and
setting up a test where you add and remove port fdb in succession and
see if the allocation of the correct size continue to grow.

This whole flow is somewhat confusing by combining both the add and
remove into a single functional flow. I guess it is intended to reduce
code duplication but it sure makes the processes difficult to follow.

I suspect the original code mistook freeing the searched entry as
freeing the found entry.

Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>