>> On Wed, Oct 13, 2021 at 03:51:33PM +0800, Anand Jain wrote:
>>> On 13/10/2021 11:28, Qing Wang wrote:
>>>> coccicheck complains about the use of snprintf() in sysfs show functions.
>>>
>>> It looks like the reason is snprintf() unaware of the PAGE_SIZE
>>> max_limit of the buf.
>>>
>>>> Fix the following coccicheck warning:
>>>> fs/btrfs/sysfs.c:335:8-16: WARNING: use scnprintf or sprintf.
>
>IIRC sprintf() is less safe than snprintf().
>Is the check really correct to mention sprintf()?
device_attr_show.cocci metions show() must not use snprintf()
when formatting the value to be returned to user space.
If you can guarantee that an overflow will never happen you
can use sprintf() otherwise you must use scnprintf().
My understanding is this is not only to solve the possible
overflow issue, snprintf() returns the length of the string, not
the length actually written. We can directly use sysfs_emit() here.
Thanks,
Qing
>>>
>>> Hm. We use snprintf() at quite a lot more places in sysfs.c and, I don't
>>> see them getting this fix. Why?
>>
>> I guess the patch is only addressing the warning for snprintf, reading
>> the sources would show how many more conversions could have been done of
>> scnprintf calls.
>>
>>>> Use sysfs_emit instead of scnprintf or sprintf makes more sense.
>>>
>>> Below commit has added it. Nice.
>>>
>>> commit 2efc459d06f1630001e3984854848a5647086232
>>> Date: Wed Sep 16 13:40:38 2020 -0700
>>>
>>> sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs out
>>
>> The conversion to the standard helper is good, but should be done
>> in the entire file.
>>
>
> Yeah, the same idea, all sysfs interface should convert to the new
> interface, not only the snprintf().
>
> Thanks,
> Qu
On 2021/10/13 19:01, 王擎 wrote:
>
>>> On Wed, Oct 13, 2021 at 03:51:33PM +0800, Anand Jain wrote:
>>>> On 13/10/2021 11:28, Qing Wang wrote:
>>>>> coccicheck complains about the use of snprintf() in sysfs show functions.
>>>>
>>>> It looks like the reason is snprintf() unaware of the PAGE_SIZE
>>>> max_limit of the buf.
>>>>
>>>>> Fix the following coccicheck warning:
>>>>> fs/btrfs/sysfs.c:335:8-16: WARNING: use scnprintf or sprintf.
>>
>> IIRC sprintf() is less safe than snprintf().
>> Is the check really correct to mention sprintf()?
>
> device_attr_show.cocci metions show() must not use snprintf()
> when formatting the value to be returned to user space.
> If you can guarantee that an overflow will never happen you
> can use sprintf() otherwise you must use scnprintf().
I totally understand snprintf() has its problem for not returning the
real written size, thus not safe.
But sprintf() is worse, it doesn't even prevent overflow from the beginning.
In fact, for case that could overflow, snprintf() would only overflow if
we have extra bytes to output and doesn't check if the offset is beyond
PAGE_SIZE at snprintf() call.
But for sprintf(), it would cause overflow immediately.
Thus mentioning sprintf() is more problematic.
Only scnprintf() is safe.
But sure, sysfs_emit() and sysfs_emit_at() would be a better solution.
Thanks,
Qu
>
> My understanding is this is not only to solve the possible
> overflow issue, snprintf() returns the length of the string, not
> the length actually written. We can directly use sysfs_emit() here.
>
> Thanks,
>
> Qing
>
>>>>
>>>> Hm. We use snprintf() at quite a lot more places in sysfs.c and, I don't
>>>> see them getting this fix. Why?
>>>
>>> I guess the patch is only addressing the warning for snprintf, reading
>>> the sources would show how many more conversions could have been done of
>>> scnprintf calls.
>>>
>>>>> Use sysfs_emit instead of scnprintf or sprintf makes more sense.
>>>>
>>>> Below commit has added it. Nice.
>>>>
>>>> commit 2efc459d06f1630001e3984854848a5647086232
>>>> Date: Wed Sep 16 13:40:38 2020 -0700
>>>>
>>>> sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs out
>>>
>>> The conversion to the standard helper is good, but should be done
>>> in the entire file.
>>>
>>
>> Yeah, the same idea, all sysfs interface should convert to the new
>> interface, not only the snprintf().
>>
>> Thanks,
>> Qu