linux-kernel - Re: [PATCH v2 1/4] i2c: smbus: only limit max banks to eight

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: <1ef2f602-e12a-4fd5-a106-003412cc34bf@gmail.com>
Date: Fri, 5 Jul 2024 09:26:58 +0200
From: Heiner Kallweit <hkallweit1@...il.com>
To: Thomas Weißschuh <thomas@...ch.de>,
 Andi Shyti <andi.shyti@...nel.org>
Cc: Thomas Weißschuh <linux@...ssschuh.net>,
 Jean Delvare <jdelvare@...e.com>, linux-i2c@...r.kernel.org,
 linux-kernel@...r.kernel.org, Guenter Roeck <linux@...ck-us.net>,
 Wolfram Sang <wsa+renesas@...g-engineering.com>
Subject: Re: [PATCH v2 1/4] i2c: smbus: only limit max banks to eight

On 05.07.2024 07:55, Thomas Weißschuh wrote:
> Jul 4, 2024 23:57:36 Andi Shyti <andi.shyti@...nel.org>:
> 
>> Hi Thomas,
>>
>> On Thu, Jun 27, 2024 at 07:48:11PM GMT, Thomas Weißschuh wrote:
>>> If there are less than eight slots in total,
>>> only probe those.
>>> Now the code matches the comment "..., then limit slots to 8".
>>>
>>> Fixes: 8821c8376993 ("i2c: smbus: Prepare i2c_register_spd for usage on muxed segments")
>>> Signed-off-by: Thomas Weißschuh <linux@...ssschuh.net>
>>
>> I don't see the need for the Fixes here... was there a bug that
>> has been fixed?
> 
> More addresses are probed than are possible.

Later in the function there's the following:

for (n = 0; n < slot_count && dimm_count; n++) {

With dimm_count being decremented with each instantiated DIMM module.
If a system has less than 8 slots, then it also has less than 8 modules
and we finish once all modules have been instantiated.
Having said that I don't see any excess probing.

> Which is a change from the old behavior and also
> contradicts the comment.
> IMO it's a bug. Probably not a big one and I'm not sure if user-observable.
> Surely nothing for stable.
> 
> But I'm not hung up on it and will drop that tag in the next revision.