linux-kernel - Re: [Intel-wired-lan] [PATCH v3] net: ethernet: fix uninitialized pointers with free attribute

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: <dd88462f-19cb-4fde-b1f0-5caf7e6c6ce6@intel.com>
Date: Mon, 17 Nov 2025 15:37:30 +0100
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Dan Carpenter <dan.carpenter@...aro.org>
CC: Ally Heev <allyheev@...il.com>, Tony Nguyen <anthony.l.nguyen@...el.com>,
	Przemek Kitszel <przemyslaw.kitszel@...el.com>, Andrew Lunn
	<andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, "Eric
 Dumazet" <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>, "K. Y. Srinivasan" <kys@...rosoft.com>, Haiyang Zhang
	<haiyangz@...rosoft.com>, Wei Liu <wei.liu@...nel.org>, Dexuan Cui
	<decui@...rosoft.com>, Aleksandr Loktionov <aleksandr.loktionov@...el.com>,
	<intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-hyperv@...r.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH v3] net: ethernet: fix uninitialized
 pointers with free attribute

From: Dan Carpenter <dan.carpenter@...aro.org>
Date: Mon, 17 Nov 2025 16:11:32 +0300

> On Thu, Nov 06, 2025 at 03:07:26PM +0100, Alexander Lobakin wrote:
>>> diff --git a/drivers/net/ethernet/intel/ice/ice_flow.c b/drivers/net/ethernet/intel/ice/ice_flow.c
>>> index 6d5c939dc8a515c252cd2b77d155b69fa264ee92..3590dacf3ee57879b3809d715e40bb290e40c4aa 100644
>>> --- a/drivers/net/ethernet/intel/ice/ice_flow.c
>>> +++ b/drivers/net/ethernet/intel/ice/ice_flow.c
>>> @@ -1573,12 +1573,13 @@ ice_flow_set_parser_prof(struct ice_hw *hw, u16 dest_vsi, u16 fdir_vsi,
>>>  			 struct ice_parser_profile *prof, enum ice_block blk)
>>>  {
>>>  	u64 id = find_first_bit(prof->ptypes, ICE_FLOW_PTYPE_MAX);
>>> -	struct ice_flow_prof_params *params __free(kfree);
>>>  	u8 fv_words = hw->blk[blk].es.fvw;
>>>  	int status;
>>>  	int i, idx;
>>>  
>>> -	params = kzalloc(sizeof(*params), GFP_KERNEL);
>>> +	struct ice_flow_prof_params *params __free(kfree) =
>>> +		kzalloc(sizeof(*params), GFP_KERNEL);
>>
>> Please don't do it that way. It's not C++ with RAII and
>> declare-where-you-use.
>> Just leave the variable declarations where they are, but initialize them
>> with `= NULL`.
>>
>> Variable declarations must be in one block and sorted from the longest
>> to the shortest.
>>
> 
> These days, with __free the trend is to say yes this is RAII and we
> should declare it where you use it.  I personally don't have a strong

Sorta, but we can't "declare it where you use it" since we don't allow
declaration-after-statement in the kernel.

> opinion on this either way, but other maintainers do and will NAK the
> `= NULL` approach.
> 
> The documentation says you should do it that way and avoid the `= NULL`
> as well.  The issue is with lock ordering.  It's a FILO ordering, so if
> we require a specific unlock order then declaring variables at the top
> could mess things up.
> 
> The counter argument is that if you declare a variable after a goto
> then that's undefined behavior as well.  Clang will detect that bug so
> it be detected before it hits actual users.
> 
> regards,
> dan carpenter

Thanks,
Olek