linux-kernel - Re: btrfs: add btrfs_read_policy_to_enum helper and refactor read, policy store

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: <e271e5e3-8101-416a-b2a6-5f52bef6dc75@oracle.com>
Date: Fri, 20 Dec 2024 01:00:22 +0530
From: Anand Jain <anand.jain@...cle.com>
To: "Colin King (gmail)" <colin.i.king@...il.com>,
        David Sterba <dsterba@...e.com>
Cc: Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
        "linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: btrfs: add btrfs_read_policy_to_enum helper and refactor read,
 policy store



On 20/12/24 00:38, Colin King (gmail) wrote:
> On 19/12/2024 18:59, Anand Jain wrote:
>>
>> Hi,
>>
>>   The changes have already been submitted and will be included in the 
>> next re-roll.
> 
> Thanks for the update.
> 
> I noticed the fix was:
> 
> strncpy(param, str, 31);
> 
> perhaps that should be based on the sizeof param, e.g. sizeof(param) - 1 
> rather than a hard-coded 31 just in case the size of param is changed in 
> the future.
> 

  Good point, I should have used sizeof(param) - 1.

Thx, Anand

> Colin
> 
>>
>>   https://patchwork.kernel.org/project/linux-btrfs/ 
>> patch/9fcc9f01bdab846db231b427f98fbb3e9df7c7a5.1734370092.git.anand.jain@...cle.com/#26168805
>>
>>
>> Thanks,
>> Anand
>>
>> On 19/12/24 21:10, Colin King (gmail) wrote:
>>> Hi,
>>>
>>> Static analysis on linux-next today has found a potential buffer 
>>> overflow in fs/btrfs/sysfs.c in function btrfs_read_policy_to_enum()
>>>
>>> The strcpy to string param has no length checks on str and hence if 
>>> str is longer than param a buffer overflow on the stack occurs. This 
>>> can potentially occur when a user writes a long string to the btrfs 
>>> sysfs file read_policy via btrfs_read_policy_store()
>>>
>>> int btrfs_read_policy_to_enum(const char *str, s64 *value)
>>> {
>>>          char param[32] = {'\0'};
>>>          char *__maybe_unused value_str;
>>>          int index;
>>>          bool found = false;
>>>
>>>          if (!str || strlen(str) == 0)
>>>                  return 0;
>>>
>>>          strcpy(param, str);   /* issue here */
>>>
>>>      ....
>>> }
>>>
>>> Colin
>>
>