On Thu, Feb 12 2015, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Thu, Feb 12, 2015 at 3:16 AM, Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: >> Ok. I made a few small changes and pushed it to http://repo.or.cz. >> >> Kees might like this. It warns about stuff like: >> >> sound/usb/mixer_quirks.c:102 snd_create_std_mono_ctl_offset() >> warn: call of 'snprintf' with non-constant format argument >> >> It still has quite a few false positives, so you need to use the >> --spammy flag. ~/smatch/smatch_scripts/test_kernel.sh --spammy >> We'll probably be able to cut down on some of the false positives. > > Heh. Yeah, that's one gcc warns about too. I have it fixed in my > format-security tree, just to keep noise down: > > - snprintf(kctl->id.name, sizeof(kctl->id.name), name); > + strlcpy(kctl->id.name, name, sizeof(kctl->id.name)); > > As it happens, all the callers are safe, but there's no reason for > snprintf there. https://github.com/Villemoes/linux-cocci/tree/master/printf_abuse might be of interest. > Is this less spammy than gcc's -Wformat-security? Not really, but maybe a little: gcc doesn't seem to do type checking if the argument is const char*const, only if it is const char[]. I've finally gotten around to supporting both. Dan, please see if you can merge the last few patches. That also includes a somewhat more elegant way of handling ?:, which should also handle nested conditionals (not that I think there are any currently). There are quite a few places where it's not very hard eliminate the warning, and often one can also save a little .rodata in the process. Examples: http://thread.gmane.org/gmane.linux.kernel/1887300 http://thread.gmane.org/gmane.linux.kernel.wireless.general/134418 I think it might be worthwhile to try to fix the easy instances when one stumbles upon them, so that there's less noise the next time someone decides to take a look. Rasmus -- To unsubscribe from this list: send the line "unsubscribe smatch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
