netdev - Re: [PATCH net-next v6 05/12] virtio_net: Query and set flow filter caps

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e4ac7f20-2643-4f3b-8f85-5b11cd3ab606@nvidia.com>
Date: Thu, 30 Oct 2025 09:03:20 -0500
From: Dan Jurgens <danielj@...dia.com>
To: Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, mst@...hat.com,
 jasowang@...hat.com, alex.williamson@...hat.com
Cc: virtualization@...ts.linux.dev, parav@...dia.com, shshitrit@...dia.com,
 yohadt@...dia.com, xuanzhuo@...ux.alibaba.com, eperezma@...hat.com,
 shameerali.kolothum.thodi@...wei.com, jgg@...pe.ca, kevin.tian@...el.com,
 kuba@...nel.org, andrew+netdev@...n.ch, edumazet@...gle.com
Subject: Re: [PATCH net-next v6 05/12] virtio_net: Query and set flow filter
 caps

On 10/30/25 6:19 AM, Paolo Abeni wrote:
> On 10/27/25 6:39 PM, Daniel Jurgens wrote:
>> When probing a virtnet device, attempt to read the flow filter
>> capabilities. In order to use the feature the caps must also
>> be set. For now setting what was read is sufficient.
>>
>> Signed-off-by: Daniel Jurgens <danielj@...dia.com>
>> Reviewed-by: Parav Pandit <parav@...dia.com>
>> Reviewed-by: Shahar Shitrit <shshitrit@...dia.com>
>> ---

>> +err_ff_action:
>> +	kfree(ff->ff_actions);
>> +err_ff_mask:
>> +	kfree(ff->ff_mask);
>> +err_ff:
>> +	kfree(ff->ff_caps);
>> +err_cap_list:
>> +	kfree(cap_id_list);
> 
> Minor nit: AFAICS the ff->ff_{caps,mask,actions} pointers can be left !=
> NULL even after free. That should not cause issue at cleanup time, as
> double free is protected by/avoided with 'ff_supported'.
> 
> Still it could foul kmemleak check. I think it would be better to either
> clear such fields here or set such fields only on success (and work with
> local variable up to that point).
> 
> Not a blocker anyway.
> 
> /P
> 

I can do that. Thanks for reviewing.