From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757410AbZEaI0f (ORCPT ); Sun, 31 May 2009 04:26:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757045AbZEaI0X (ORCPT ); Sun, 31 May 2009 04:26:23 -0400 Received: from cn.fujitsu.com ([222.73.24.84]:62217 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1756807AbZEaI0T (ORCPT ); Sun, 31 May 2009 04:26:19 -0400 Message-ID: <4A223F7E.3090203@cn.fujitsu.com> Date: Sun, 31 May 2009 16:27:42 +0800 From: Li Zefan User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Frederic Weisbecker CC: Steven Rostedt , Tom Zanussi , Ingo Molnar , LKML Subject: Re: [PATCH 2/2] tracing/filters: use strcmp() instead of strncmp() References: <4A1F9FAC.6020506@cn.fujitsu.com> <4A20F71F.6030703@cn.fujitsu.com> <20090530135236.GB5969@nowhere> In-Reply-To: <20090530135236.GB5969@nowhere> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 : >>>> 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 >>>> -0 [001] 1363.423175: irq_handler_entry: irq=18 handler=eth0 >>>> -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.