linux-kernel - Re: [PATCH v2] driver core: Fix size calculation of symlink name for devlink_(add|remove)

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] [day] [month] [year] [list]

Message-ID: <97c10434-daf0-4e98-977b-0dff3a330930@icloud.com>
Date: Wed, 10 Jul 2024 19:54:33 +0800
From: Zijun Hu <zijun_hu@...oud.com>
To: Saravana Kannan <saravanak@...gle.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 "Rafael J. Wysocki" <rafael@...nel.org>, linux-kernel@...r.kernel.org,
 Zijun Hu <quic_zijuhu@...cinc.com>
Subject: Re: [PATCH v2] driver core: Fix size calculation of symlink name for
 devlink_(add|remove)_symlinks()

On 2024/7/10 02:03, Saravana Kannan wrote:
> On Tue, Jul 9, 2024 at 7:13 AM Zijun Hu <zijun_hu@...oud.com> wrote:
>>
>> From: Zijun Hu <quic_zijuhu@...cinc.com>
>>
>> devlink_(add|remove)_symlinks() kzalloc() memory to save symlink name
>> for both supplier and consumer, but do not explicitly take into account
>> consumer's prefix "consumer:", so cause wrong algorithm for calculating
>> memory size, fixed by taking into account consumer's prefix as well.
> 
> Again, this makes it sound like you are fixing some bug. No "wrong
> algorithm" is happening here. You are improving readability. So, just
> say that?
> 
okay, thanks for code review. what about below comments?

devlink_(add|remove)_symlinks() kzalloc() memory to save symlink name
for both supplier and consumer, but do not explicitly take into account
consumer's prefix "consumer:", so cause disadvantages listed below:
1) it seems wrong for the algorithm to calculate memory size
2) readers maybe need to count characters one by one of both prefix
   strings to confirm calculated memory size
3) it is relatively easy to introduce new bug if any prefix string
   is modified in future
solved by taking into account consumer's prefix as well.

you maybe correct it, i would like to use that corrected.

> -Saravana
> 
>>
>> Signed-off-by: Zijun Hu <quic_zijuhu@...cinc.com>
>> ---
>> Changes in v2:
>> - Correct commit message and add inline comments
>> - Remove fix tag
>> - Link to v1: https://lore.kernel.org/r/20240707-devlink_fix-v1-1-623acb431cd8@quicinc.com
>> ---
>>  drivers/base/core.c | 8 ++++++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/base/core.c b/drivers/base/core.c
>> index 2b4c0624b704..51209db7ff84 100644
>> --- a/drivers/base/core.c
>> +++ b/drivers/base/core.c
>> @@ -572,7 +572,11 @@ static int devlink_add_symlinks(struct device *dev)
>>         len = max(strlen(dev_bus_name(sup)) + strlen(dev_name(sup)),
>>                   strlen(dev_bus_name(con)) + strlen(dev_name(con)));
>>         len += strlen(":");
>> -       len += strlen("supplier:") + 1;
>> +       /*
>> +        * we kzalloc() memory for symlink name of both supplier and
>> +        * consumer, so explicitly take into account both prefix.
>> +        */
>> +       len += max(strlen("supplier:"), strlen("consumer:")) + 1;
>>         buf = kzalloc(len, GFP_KERNEL);
>>         if (!buf)
>>                 return -ENOMEM;
>> @@ -623,7 +627,7 @@ static void devlink_remove_symlinks(struct device *dev)
>>         len = max(strlen(dev_bus_name(sup)) + strlen(dev_name(sup)),
>>                   strlen(dev_bus_name(con)) + strlen(dev_name(con)));
>>         len += strlen(":");
>> -       len += strlen("supplier:") + 1;
>> +       len += max(strlen("supplier:"), strlen("consumer:")) + 1;
>>         buf = kzalloc(len, GFP_KERNEL);
>>         if (!buf) {
>>                 WARN(1, "Unable to properly free device link symlinks!\n");
>>
>> ---
>> base-commit: c6653f49e4fd3b0d52c12a1fc814d6c5b234ea15
>> change-id: 20240707-devlink_fix-0fa46dedfe95
>>
>> Best regards,
>> --
>> Zijun Hu <quic_zijuhu@...cinc.com>
>>