netdev - Re: [ovs-dev] [PATCH v2] net: openvswitch: fix possible memory leak in ovs_meter_cmd_set()

Open Source and information security mailing list archives

Message-ID: <Y+TR3sB4X5Yt79Tx@corigine.com>
Date:   Thu, 9 Feb 2023 11:58:38 +0100
From:   Simon Horman <simon.horman@...igine.com>
To:     Hangyu Hua <hbh25y@...il.com>
Cc:     pshelar@....org, davem@...emloft.net, edumazet@...gle.com,
        kuba@...nel.org, pabeni@...hat.com, xiangxia.m.yue@...il.com,
        echaudro@...hat.com, dev@...nvswitch.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [ovs-dev] [PATCH v2] net: openvswitch: fix possible memory leak
 in ovs_meter_cmd_set()

On Thu, Feb 09, 2023 at 05:32:40PM +0800, Hangyu Hua wrote:
> old_meter needs to be free after it is detached regardless of whether
> the new meter is successfully attached.
> 
> Fixes: c7c4c44c9a95 ("net: openvswitch: expand the meters supported number")
> Signed-off-by: Hangyu Hua <hbh25y@...il.com>
> ---
> 
> v2: use goto label and free old_meter outside of ovs lock.
> 
>  net/openvswitch/meter.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/net/openvswitch/meter.c b/net/openvswitch/meter.c
> index 6e38f68f88c2..9b680f0894f1 100644
> --- a/net/openvswitch/meter.c
> +++ b/net/openvswitch/meter.c
> @@ -417,6 +417,7 @@ static int ovs_meter_cmd_set(struct sk_buff *skb, struct genl_info *info)
>  	int err;
>  	u32 meter_id;
>  	bool failed;
> +	bool locked = true;
>  
>  	if (!a[OVS_METER_ATTR_ID])
>  		return -EINVAL;
> @@ -448,11 +449,13 @@ static int ovs_meter_cmd_set(struct sk_buff *skb, struct genl_info *info)
>  		goto exit_unlock;
>  
>  	err = attach_meter(meter_tbl, meter);
> -	if (err)
> -		goto exit_unlock;
>  
>  	ovs_unlock();
>  
> +	if (err) {
> +		locked = false;
> +		goto exit_free_old_meter;
> +	}
>  	/* Build response with the meter_id and stats from
>  	 * the old meter, if any.
>  	 */
> @@ -472,8 +475,11 @@ static int ovs_meter_cmd_set(struct sk_buff *skb, struct genl_info *info)
>  	genlmsg_end(reply, ovs_reply_header);
>  	return genlmsg_reply(reply, info);
>  
> +exit_free_old_meter:
> +	ovs_meter_free(old_meter);
>  exit_unlock:
> -	ovs_unlock();
> +	if (locked)
> +		ovs_unlock();

I see where you are going here, but is the complexity of the
locked variable worth the benefit of freeing old_meter outside
the lock?

>  	nlmsg_free(reply);
>  exit_free_meter:
>  	kfree(meter);
> -- 
> 2.34.1
> 
> _______________________________________________
> dev mailing list
> dev@...nvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> 

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives