Messages in this thread | | | Date | Sun, 31 May 2009 16:27:42 +0800 | From | Li Zefan <> | Subject | Re: [PATCH 2/2] tracing/filters: use strcmp() instead of strncmp() |
| |
Frederic Weisbecker wrote: > On Sat, May 30, 2009 at 05:06:39PM +0800, Li Zefan wrote: >> Frédéric Weisbecker wrote: >>> 2009/5/29 Li Zefan <lizf@cn.fujitsu.com>: >>>> Trace filter is not working normally: >>>> >>>> # echo 'name == et' > tracing/events/irq/irq_handler_entry/filter >>>> # echo 1 > tracing/events/irq/irq_handler_entry/enable >>>> # cat trace_pipe >>>> <idle>-0 [001] 1363.423175: irq_handler_entry: irq=18 handler=eth0 >>>> <idle>-0 [001] 1363.934528: irq_handler_entry: irq=18 handler=eth0 >>>> ... >>>> >>>> It's because we pass to trace_define_field() the information of >>>> __str_loc_##item, but not the actual string, so pred->str_len == field->size >>>> == sizeof(unsigned short), thus it always compare at most 2 bytes when >>>> filtering on __string() field. >>> >>> Weird, I was about sure I set the size of each string() to FILTER_MAX_STRING (or >>> something like that). >>> >>> Anyway this patch looks good but it does more than just fixing the >>> issue, it removes >>> the string len boundary security we had with strncmp() for every >>> string (static and >>> dynamic size). >>> >>> The potential side effect that comes along this patch would disappear if >>> you just turn strncmp into strcmp only in filter_pred_strloc(). >>> >>> If you do that also for fixed size strings, then it should be done in >>> a second patch, >>> although I guess turning anything here into strcmp is fine because the >>> strings given >>> by the user are always limited in their size. But we never know... >>> >> I don't think there's any security issue. It's irrelevant how big the user-input >> strings are. The point is those strings are guaranteed to be NULL-terminated. >> Am I missing something? >> >> And I don't think it's necessary to make 2 patches that each patch converts >> one strncmp to strcmp. But maybe it's better to improve this changelog? > > Hmm, you must be right, indeed they seem to be guaranted beeing NULL-terminated > strings. >
Sorry, I was wrong. :(
Though the user-input strings are guaranted to be NULL-terminated, strings generated by TRACE_EVENT might not.
We define static strings this way: TP_struct( __array(char, foo, LEN) ) But foo is not necessarily a string, though I doubt someone will use it as non-string char array.
Dynamic string is fine, because assign_str() makes it NULL-terminated.
So we can use strcmp() for dynamic strings, but we'd better use strncmp() for static string.
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |