netdev - Re: [Intel-wired-lan] [PATCH v5 iwl-next] i40e: Use correct buffer size in i40e_dbg_command

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: <bd95de9e-1dcc-4fbd-ba47-9d33c8bdc6fa@amd.com>
Date: Tue, 19 Dec 2023 17:32:18 -0800
From: "Nelson, Shannon" <shannon.nelson@....com>
To: "Pucha, HimasekharX Reddy" <himasekharx.reddy.pucha@...el.com>,
 Kunwu Chan <chentao@...inos.cn>,
 "Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
 "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
 "davem@...emloft.net" <davem@...emloft.net>,
 "edumazet@...gle.com" <edumazet@...gle.com>,
 "kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com"
 <pabeni@...hat.com>,
 "jeffrey.t.kirsher@...el.com" <jeffrey.t.kirsher@...el.com>
Cc: Kunwu Chan <kunwu.chan@...mail.com>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "Lobakin, Aleksander" <aleksander.lobakin@...el.com>,
 "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
 Simon Horman <horms@...nel.org>
Subject: Re: [Intel-wired-lan] [PATCH v5 iwl-next] i40e: Use correct buffer
 size in i40e_dbg_command_read

On 12/17/2023 9:54 PM, Pucha, HimasekharX Reddy wrote:
> 
>> -----Original Message-----
>> From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf Of Kunwu Chan
>> Sent: Friday, December 8, 2023 8:50 AM
>> To: Brandeburg, Jesse <jesse.brandeburg@...el.com>; Nguyen, Anthony L <anthony.l.nguyen@...el.com>; davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org; pabeni@...hat.com; jeffrey.t.kirsher@...el.com; shannon.nelson@....com
>> Cc: Kunwu Chan <chentao@...inos.cn>; Kunwu Chan <kunwu.chan@...mail.com>; netdev@...r.kernel.org; linux-kernel@...r.kernel.org; Lobakin, Aleksander <aleksander.lobakin@...el.com>; intel-wired-lan@...ts.osuosl.org; Simon Horman <horms@...nel.org>
>> Subject: [Intel-wired-lan] [PATCH v5 iwl-next] i40e: Use correct buffer size in i40e_dbg_command_read
>>
>> The size of "i40e_dbg_command_buf" is 256, the size of "name"
>> depends on "IFNAMSIZ", plus a null character and format size,
>> the total size is more than 256.
>>
>> Improve readability and maintainability by replacing a hardcoded string
>> allocation and formatting by the use of the kasprintf() helper.
>>
>> Fixes: 02e9c290814c ("i40e: debugfs interface")
>> Suggested-by: Simon Horman <horms@...nel.org>
>> Suggested-by: Alexander Lobakin <aleksander.lobakin@...el.com>
>> Suggested-by: Tony Nguyen <anthony.l.nguyen@...el.com>
>> Cc: Kunwu Chan <kunwu.chan@...mail.com>
>> Signed-off-by: Kunwu Chan <chentao@...inos.cn>
>> ---
>> v2
>>     - Update the size calculation with IFNAMSIZ and sizeof(i40e_dbg_command_buf)
>> v3
>>     - Use kasprintf to improve readability and maintainability
>> v4
>>     - Fix memory leak in error path
>> v5
>>     - Change the order of labels
>> ---
>>   .../net/ethernet/intel/i40e/i40e_debugfs.c    | 20 ++++++++++---------
>>   1 file changed, 11 insertions(+), 9 deletions(-)
>>
> 
> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@...el.com> (A Contingent worker at Intel)
> 

Much of this debugfs command code was an early driver hack that probably 
never should have gone upstream in the form that it did.  The 
i40e_dbg_command_buf itself was originally meant as a scratchpad to put 
the 'last command processed', which was not really very useful, and as a 
static global that might be written by any number of instances of i40e 
devices, was problematic from the beginning.  Now, unless I'm mistaken, 
it looks like nothing is writing to the buffer at all anymore, so the 
buffer and the i40e_dbg_command_read() callback probably should just all 
go away rather than trying to pretty up some useless code.

sln