From: Frederic Weisbecker <fweisbec@gmail.com>
To: Li Zefan <lizf@cn.fujitsu.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Tom Zanussi <tzanussi@gmail.com>, Ingo Molnar <mingo@elte.hu>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] tracing/filters: use strcmp() instead of strncmp()
Date: Sat, 30 May 2009 15:52:37 +0200 [thread overview]
Message-ID: <20090530135236.GB5969@nowhere> (raw)
In-Reply-To: <4A20F71F.6030703@cn.fujitsu.com>
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.
But at least improve your changelog to explain why your solution is
safe.
Thanks,
Frederic.
> >
> > Thanks,
> > Frederic.
> >
> >
> >> Since __string() is dynamic size, we are not able to set field->size to
> >> string length. Thus this patch uses strcmp() instead of strncmp().
> >>
> >> [ Impact: make filter facility working normally for __string() field ]
> >>
> >> Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
> >> ---
next prev parent reply other threads:[~2009-05-30 13:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-29 8:41 [PATCH 2/2] tracing/filters: use strcmp() instead of strncmp() Li Zefan
2009-05-29 13:51 ` Frédéric Weisbecker
2009-05-30 9:06 ` Li Zefan
2009-05-30 13:52 ` Frederic Weisbecker [this message]
2009-05-31 8:27 ` Li Zefan
2009-05-31 13:28 ` Frederic Weisbecker
2009-06-01 5:45 ` Li Zefan
2009-06-01 13:09 ` Frederic Weisbecker
2009-06-02 0:55 ` Li Zefan
2009-09-08 3:03 ` Steven Rostedt
2009-09-09 1:21 ` Li Zefan
2009-09-09 2:00 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090530135236.GB5969@nowhere \
--to=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=tzanussi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.