On 10/06/2013 08:37 AM, Chen Gang wrote: > On 10/06/2013 01:45 AM, Richard Weinberger wrote: >> Am 05.10.2013 19:06, schrieb Chen Gang: >>> On 10/06/2013 12:50 AM, Chen Gang wrote: >>>> On 10/06/2013 12:08 AM, Richard Weinberger wrote: >>>>> On Sat, Oct 5, 2013 at 5:46 PM, Chen Gang <gang.c...@asianux.com> wrote: >>>>>> On 10/05/2013 11:41 PM, Joe Perches wrote: >>>>>>> On Sat, 2013-10-05 at 23:19 +0800, Chen Gang wrote: >>>>>>>> Theoretically, the maximize size of "%d" or "%u" is 11 (10 + '\0'), so >>>>>>>> need set MAX_NAMELEN 11 instead of 10. >>>>>>> >>>>>>> %d can be negative. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Oh, really, it is incorrect. Al Viro succeeds once. :-( >>>>>> >>>>>> And I should send patch v2 for it. >>>>> >>>>> irq is in both register_irq_proc() and unregister_irq_proc() an unsigned >>>>> int. >>>>> Therefore %d makes not really sense. Both should use %u. >>>>> IMHO sprintf() should also get replaced by snprintf() but that's a >>>>> matter of taste. >>>>> >>> >>> Oh, commonly, snprintf() are used for the string which can be truncated, >>> and can not be used for the string which contents must not be truncated. >>> >>> In our case, the name string must be not truncated (or may not unique, >>> theoretically), so we have to still use sprintf(). >> >> Of course you would have to check the return value of snprintf() to detect >> a truncation and abort... >> > > OK, thanks, that sounds reasonable to me, so I feel that's not a matter > of taste. >
Hmm... does 'taste' means: "for string which can not be truncated, if maximized length is obvious (e.g. our case 11 for "%u"), sprintf() is more clearer than snprintf() for both readers and writers"? BTW: when MAX_NAMELEN is defined as 128, is it suitable to check the return value of snprintf() in register_handler_proc(), and WARN_ON() if it is not less than 128? Thanks. > In my opinion, when we know the maximized length, we need always use > s(c)nprintf instead of sprintf, if the string can be truncated, use > scnprintf, else use snprintf and also check the return value. > > sprintf is 'dangrous', need try to use s(c)nprintf instead of. We can > scan whole kernel, I guess quite a few of sprintf may be related with > memory overflow 'theoretically' (welcome any members to give a check). > > > Thanks. > >> Thanks, >> //richard >> >> >> > -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
