* [PATCH] tracing: Fix an off by one in __next() @ 2018-06-20 11:08 ` Dan Carpenter 0 siblings, 0 replies; 6+ messages in thread From: Dan Carpenter @ 2018-06-20 11:08 UTC (permalink / raw) To: Steven Rostedt; +Cc: Ingo Molnar, linux-kernel, kernel-janitors The > should be >= to prevent an off by one bug. From reviewing the code, it seems possible for stack_trace_max.nr_entries to be set to .max_entries and in that case we would be reading one element beyond the end of the stack_dump_trace[] array. If it's not set to .max_entries then the bug doesn't affect runtime. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c index 4237eba4ef20..6e3edd745c68 100644 --- a/kernel/trace/trace_stack.c +++ b/kernel/trace/trace_stack.c @@ -286,7 +286,7 @@ __next(struct seq_file *m, loff_t *pos) { long n = *pos - 1; - if (n > stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX) + if (n >= stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX) return NULL; m->private = (void *)n; ^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH] tracing: Fix an off by one in __next() @ 2018-06-20 11:08 ` Dan Carpenter 0 siblings, 0 replies; 6+ messages in thread From: Dan Carpenter @ 2018-06-20 11:08 UTC (permalink / raw) To: Steven Rostedt; +Cc: Ingo Molnar, linux-kernel, kernel-janitors The > should be >= to prevent an off by one bug. From reviewing the code, it seems possible for stack_trace_max.nr_entries to be set to .max_entries and in that case we would be reading one element beyond the end of the stack_dump_trace[] array. If it's not set to .max_entries then the bug doesn't affect runtime. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c index 4237eba4ef20..6e3edd745c68 100644 --- a/kernel/trace/trace_stack.c +++ b/kernel/trace/trace_stack.c @@ -286,7 +286,7 @@ __next(struct seq_file *m, loff_t *pos) { long n = *pos - 1; - if (n > stack_trace_max.nr_entries || stack_dump_trace[n] = ULONG_MAX) + if (n >= stack_trace_max.nr_entries || stack_dump_trace[n] = ULONG_MAX) return NULL; m->private = (void *)n; ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] tracing: Fix an off by one in __next() 2018-06-20 11:08 ` Dan Carpenter @ 2018-11-27 18:44 ` Steven Rostedt -1 siblings, 0 replies; 6+ messages in thread From: Steven Rostedt @ 2018-11-27 18:44 UTC (permalink / raw) To: Dan Carpenter; +Cc: Ingo Molnar, linux-kernel, kernel-janitors Doing the sweep of my INBOX, I came across this patch (it was sent while I was in the Alps :-) On Wed, 20 Jun 2018 14:08:00 +0300 Dan Carpenter <dan.carpenter@oracle.com> wrote: > The > should be >= to prevent an off by one bug. Well, not really. > > >From reviewing the code, it seems possible for > stack_trace_max.nr_entries to be set to .max_entries and in that case we > would be reading one element beyond the end of the stack_dump_trace[] > array. If it's not set to .max_entries then the bug doesn't affect > runtime. > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> > > diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c > index 4237eba4ef20..6e3edd745c68 100644 > --- a/kernel/trace/trace_stack.c > +++ b/kernel/trace/trace_stack.c > @@ -286,7 +286,7 @@ __next(struct seq_file *m, loff_t *pos) > { > long n = *pos - 1; > > - if (n > stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX) > + if (n >= stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX) We have: static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES+1] = { [0 ... (STACK_TRACE_ENTRIES)] = ULONG_MAX }; And struct stack_trace stack_trace_max = { .max_entries = STACK_TRACE_ENTRIES - 1, .entries = &stack_dump_trace[0], }; And nr_entries is set as this, and we have after that this: stack_trace_max.nr_entries = x; for (; x < i; x++) stack_dump_trace[x] = ULONG_MAX; Where we set stack_dump_trace[nr_entries] to ULONG_MAX. Thus, nr_entries will not go pass the size of stack_dump_trace. That said, if n == nr_entries, the second part of that if will always be true. And this is a bit subtle, so I will apply the patch. But it is not an off by one bug ;-) Thanks! -- Steve > return NULL; > > m->private = (void *)n; ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] tracing: Fix an off by one in __next() @ 2018-11-27 18:44 ` Steven Rostedt 0 siblings, 0 replies; 6+ messages in thread From: Steven Rostedt @ 2018-11-27 18:44 UTC (permalink / raw) To: Dan Carpenter; +Cc: Ingo Molnar, linux-kernel, kernel-janitors Doing the sweep of my INBOX, I came across this patch (it was sent while I was in the Alps :-) On Wed, 20 Jun 2018 14:08:00 +0300 Dan Carpenter <dan.carpenter@oracle.com> wrote: > The > should be >= to prevent an off by one bug. Well, not really. > > >From reviewing the code, it seems possible for > stack_trace_max.nr_entries to be set to .max_entries and in that case we > would be reading one element beyond the end of the stack_dump_trace[] > array. If it's not set to .max_entries then the bug doesn't affect > runtime. > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> > > diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c > index 4237eba4ef20..6e3edd745c68 100644 > --- a/kernel/trace/trace_stack.c > +++ b/kernel/trace/trace_stack.c > @@ -286,7 +286,7 @@ __next(struct seq_file *m, loff_t *pos) > { > long n = *pos - 1; > > - if (n > stack_trace_max.nr_entries || stack_dump_trace[n] = ULONG_MAX) > + if (n >= stack_trace_max.nr_entries || stack_dump_trace[n] = ULONG_MAX) We have: static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES+1] { [0 ... (STACK_TRACE_ENTRIES)] = ULONG_MAX }; And struct stack_trace stack_trace_max = { .max_entries = STACK_TRACE_ENTRIES - 1, .entries = &stack_dump_trace[0], }; And nr_entries is set as this, and we have after that this: stack_trace_max.nr_entries = x; for (; x < i; x++) stack_dump_trace[x] = ULONG_MAX; Where we set stack_dump_trace[nr_entries] to ULONG_MAX. Thus, nr_entries will not go pass the size of stack_dump_trace. That said, if n = nr_entries, the second part of that if will always be true. And this is a bit subtle, so I will apply the patch. But it is not an off by one bug ;-) Thanks! -- Steve > return NULL; > > m->private = (void *)n; ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] tracing: Fix an off by one in __next() 2018-11-27 18:44 ` Steven Rostedt @ 2018-11-27 20:04 ` Dan Carpenter -1 siblings, 0 replies; 6+ messages in thread From: Dan Carpenter @ 2018-11-27 20:04 UTC (permalink / raw) To: Steven Rostedt; +Cc: Ingo Molnar, linux-kernel, kernel-janitors On Tue, Nov 27, 2018 at 01:44:12PM -0500, Steven Rostedt wrote: > > Doing the sweep of my INBOX, I came across this patch (it was sent > while I was in the Alps :-) > > > On Wed, 20 Jun 2018 14:08:00 +0300 > Dan Carpenter <dan.carpenter@oracle.com> wrote: > > > The > should be >= to prevent an off by one bug. > > Well, not really. > > > > > >From reviewing the code, it seems possible for > > stack_trace_max.nr_entries to be set to .max_entries and in that case we > > would be reading one element beyond the end of the stack_dump_trace[] > > array. If it's not set to .max_entries then the bug doesn't affect > > runtime. > > > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> > > > > diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c > > index 4237eba4ef20..6e3edd745c68 100644 > > --- a/kernel/trace/trace_stack.c > > +++ b/kernel/trace/trace_stack.c > > @@ -286,7 +286,7 @@ __next(struct seq_file *m, loff_t *pos) > > { > > long n = *pos - 1; > > > > - if (n > stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX) > > + if (n >= stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX) > > We have: > > static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES+1] = > { [0 ... (STACK_TRACE_ENTRIES)] = ULONG_MAX }; > > And > > struct stack_trace stack_trace_max = { > .max_entries = STACK_TRACE_ENTRIES - 1, > .entries = &stack_dump_trace[0], > }; > > > And nr_entries is set as this, and we have after that this: > > stack_trace_max.nr_entries = x; > for (; x < i; x++) > stack_dump_trace[x] = ULONG_MAX; > > Where we set stack_dump_trace[nr_entries] to ULONG_MAX. > > Thus, nr_entries will not go pass the size of stack_dump_trace. > > That said, if n == nr_entries, the second part of that if will always > be true. And this is a bit subtle, so I will apply the patch. But it is > not an off by one bug ;-) Ah, yes. I follow that now. Thanks for taking the time to review this patch. I am optimistic that eventually I will fix how Smatch handles loops so it maybe will be able to figure out that "x <= STACK_TRACE_ENTRIES - 1" but that's probably some time off. regards, dan carpenter ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] tracing: Fix an off by one in __next() @ 2018-11-27 20:04 ` Dan Carpenter 0 siblings, 0 replies; 6+ messages in thread From: Dan Carpenter @ 2018-11-27 20:04 UTC (permalink / raw) To: Steven Rostedt; +Cc: Ingo Molnar, linux-kernel, kernel-janitors On Tue, Nov 27, 2018 at 01:44:12PM -0500, Steven Rostedt wrote: > > Doing the sweep of my INBOX, I came across this patch (it was sent > while I was in the Alps :-) > > > On Wed, 20 Jun 2018 14:08:00 +0300 > Dan Carpenter <dan.carpenter@oracle.com> wrote: > > > The > should be >= to prevent an off by one bug. > > Well, not really. > > > > > >From reviewing the code, it seems possible for > > stack_trace_max.nr_entries to be set to .max_entries and in that case we > > would be reading one element beyond the end of the stack_dump_trace[] > > array. If it's not set to .max_entries then the bug doesn't affect > > runtime. > > > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> > > > > diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c > > index 4237eba4ef20..6e3edd745c68 100644 > > --- a/kernel/trace/trace_stack.c > > +++ b/kernel/trace/trace_stack.c > > @@ -286,7 +286,7 @@ __next(struct seq_file *m, loff_t *pos) > > { > > long n = *pos - 1; > > > > - if (n > stack_trace_max.nr_entries || stack_dump_trace[n] = ULONG_MAX) > > + if (n >= stack_trace_max.nr_entries || stack_dump_trace[n] = ULONG_MAX) > > We have: > > static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES+1] > { [0 ... (STACK_TRACE_ENTRIES)] = ULONG_MAX }; > > And > > struct stack_trace stack_trace_max = { > .max_entries = STACK_TRACE_ENTRIES - 1, > .entries = &stack_dump_trace[0], > }; > > > And nr_entries is set as this, and we have after that this: > > stack_trace_max.nr_entries = x; > for (; x < i; x++) > stack_dump_trace[x] = ULONG_MAX; > > Where we set stack_dump_trace[nr_entries] to ULONG_MAX. > > Thus, nr_entries will not go pass the size of stack_dump_trace. > > That said, if n = nr_entries, the second part of that if will always > be true. And this is a bit subtle, so I will apply the patch. But it is > not an off by one bug ;-) Ah, yes. I follow that now. Thanks for taking the time to review this patch. I am optimistic that eventually I will fix how Smatch handles loops so it maybe will be able to figure out that "x <= STACK_TRACE_ENTRIES - 1" but that's probably some time off. regards, dan carpenter ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-11-27 20:04 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-06-20 11:08 [PATCH] tracing: Fix an off by one in __next() Dan Carpenter 2018-06-20 11:08 ` Dan Carpenter 2018-11-27 18:44 ` Steven Rostedt 2018-11-27 18:44 ` Steven Rostedt 2018-11-27 20:04 ` Dan Carpenter 2018-11-27 20:04 ` Dan Carpenter
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.