linux-kernel - Re: [PATCH] kernel/irq/proc.c: set MAX_NAMELEN 11 instead of 10 which express the maximize size of "%d" or "%u".

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: <5250B0E3.3070500@asianux.com>
Date:	Sun, 06 Oct 2013 08:37:55 +0800
From:	Chen Gang <gang.chen@...anux.com>
To:	Richard Weinberger <richard@....at>
CC:	Richard Weinberger <richard.weinberger@...il.com>,
	Joe Perches <joe@...ches.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kernel/irq/proc.c: set MAX_NAMELEN 11 instead of 10 which
 express the maximize size of "%d" or "%u".

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.chen@...anux.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.

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/