Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 8 Oct 2005 01:04:08 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Nate Lawson <nate@root.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/libkern strtok.c src/sys/sys libkern.h  src/sys/conf files
Message-ID:  <20051008005134.Q58005@delplex.bde.org>
In-Reply-To: <4345607F.1080804@root.org>
References:  <20051006111026.BA71016A452@hub.freebsd.org> <4345607F.1080804@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 6 Oct 2005, Nate Lawson wrote:

> Pawel Jakub Dawidek wrote:
>> pjd         2005-10-06 11:10:10 UTC
>> 
>>   FreeBSD src repository
>> 
>>   Modified files:
>>     sys/sys              libkern.h     sys/conf             files   Added 
>> files:
>>     sys/libkern          strtok.c   Log:
>>   Add strtok() and strtok_r() function to libkern.
>>     MFC after:      2 weeks
>>     Revision  Changes    Path
>>   1.1055    +1 -0      src/sys/conf/files
>>   1.1       +98 -0     src/sys/libkern/strtok.c (new)
>>   1.51      +2 -0      src/sys/sys/libkern.h
>
> Why is the kernel parsing strings?  Seems like a good way to introduce 
> security flaws.

sscanf() is a similar older mistake in the kernel.  sscanf() is only
slightly more useable than gets(), since its behaviour on overflow is
undefined and input that is not parsed in other ways can easily cause
overflow.  (Its actual behaviour is to blindly truncate results.)  In
the kernel, more than half (by sscanf count) of its abuses are for %d
or %x formats which can easily be handled right using strto[u]l().

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051008005134.Q58005>