linux-kernel - Re: [Intel-wired-lan] [PATCH net-next v3] ice: Adjust over allocation of memory in ice_sched_add_root_node() and ice_sched_add

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 for Android: free password hash cracker in your pocket

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

Message-ID: <99fcfba3-7cac-42c8-9113-2340d5a485f8@t-argos.ru>
Date: Tue, 9 Jul 2024 14:35:29 +0300
From: Aleksandr Mishin <amishin@...rgos.ru>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>, Paul Menzel
	<pmenzel@...gen.mpg.de>
CC: <lvc-project@...uxtesting.org>, Tony Nguyen <anthony.l.nguyen@...el.com>,
	<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>, Eric Dumazet
	<edumazet@...gle.com>, <intel-wired-lan@...ts.osuosl.org>, Simon Horman
	<horms@...nel.org>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>, "David S. Miller" <davem@...emloft.net>
Subject: Re: [Intel-wired-lan] [PATCH net-next v3] ice: Adjust over allocation
 of memory in ice_sched_add_root_node() and ice_sched_add_node()



On 09.07.2024 13:25, Przemek Kitszel wrote:
> On 7/9/24 11:50, Paul Menzel wrote:
>> Dear Przemek,
>>
>>
>> Thank you for your quick reply.
>>
>>
>> Am 09.07.24 um 11:11 schrieb Przemek Kitszel:
>>> On 7/9/24 10:54, Paul Menzel wrote:
>>>> [Cc: -anirudh.venkataramanan@...el.com (Address rejected)]
>>>>
>>>> Am 09.07.24 um 10:49 schrieb Paul Menzel:
>>
>>>>> Am 08.07.24 um 20:27 schrieb Aleksandr Mishin:
>>>>>> In ice_sched_add_root_node() and ice_sched_add_node() there are 
>>>>>> calls to
>>>>>> devm_kcalloc() in order to allocate memory for array of pointers to
>>>>>> 'ice_sched_node' structure. But incorrect types are used as sizeof()
>>>>>> arguments in these calls (structures instead of pointers) which 
>>>>>> leads to
>>>>>> over allocation of memory.
>>>>>
>>>>> If you have the explicit size at hand, it’d be great if you added 
>>>>> those to the commit message.

One pointer instance size is 8 bytes.
One structure instance size is (approximately) 104 bytes. I'm not quite 
sure for that number, because structure is complex and includes another 
structure, which includes another etc. So I could make a mistake in 
calculation.
Memory allocation is performed for multiple instances, so this ~96 bytes 
should be multiplied by a number of instances to get final memory 
overhead size.

>>>>>
>>>>>> Adjust over allocation of memory by correcting types in 
>>>>>> devm_kcalloc()
>>>>>> sizeof() arguments.
>>>>>>
>>>>>> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>>>>>
>>>>> Maybe mention, that Coverity found that too, and the warning was 
>>>>> disabled, and use that commit in Fixes: tag? That’d be commit 
>>>>> b36c598c999c (ice: Updates to Tx scheduler code), different from 
>>>>> the one you used.
>>>
>>> this version does not have any SHA mentioned :)
>>
>> Sorry, I don’t understand your answer. What SHA do you mean?
> 
> there is no commit cited by Aleksandr in v3, IIRC there was one in v1
> 
> I agree that mention would be valuable, and we still want v4 with my
> Suggested-by dropped anyway :)

I'm working on v4, but I must wait 24 hours from v3 according to netdev 
rules: https://docs.kernel.org/process/maintainer-netdev.html.

In v4 I'll drop "Suggested-by" :)

But I'm a little confused whether to include "Fixes" tag into v4, 
because this is not an issue for the users as Simon and Przemek wrote?

I would be grateful if you could tell me what else to change to avoid 
later v5 release :)

> 
>>
>>>>> `Documentation/process/submitting-patches.rst` says:
>>>>>
>>>>>> A Fixes: tag indicates that the patch fixes an issue in a previous
>>>>>> commit. It is used to make it easy to determine where a bug
>>>>>> originated, which can help review a bug fix. This tag also assists
>>>>>> the stable kernel team in determining which stable kernel versions
>>>>>> should receive your fix. This is the preferred method for indicating
>>>>>> a bug fixed by the patch.
>>>
>>> so, this is not a "fix" per definition of a fix: "your patch changes
>>> observable misbehavior"
>>> If the over-allocation would be counted in megabytes, then it will
>>> be a different case.
>>
>> The quoted text just talks about “an issue”. What definition do you 
>> refer to?
> 
> I mean that there is no issue (for the users), thus no fix.
> Example of recently merged "not fix", with more links to other "non-
> fixes":
> https://lore.kernel.org/all/b836eb8ca8abf2f64478da48d250405bb1d90ad5.camel@sipsolutions.net/T/
> 
>>
>>
>> Kind regards,
>>
>> Paul
> 

-- 
Kind regards
Aleksandr