Re: [PATCH] Fix ps -l buffer overflow problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- "Jeff Moyer" <jmoyer@xxxxxxxxxx> wrote:

> Bernhard Walle <bwalle@xxxxxxx> writes:
> 
> > That should also go mainline.
> >
> >
> > Signed-off-by : Sachin Sant <sachinp@xxxxxxxxxx>
> > Acked-by: Bernhard Walle <bwalle@xxxxxxx>
> >
> >
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > task.c |    2 +-
> >
> >
> > That should also go mainline.
> >
> >
> > Signed-off-by : Sachin Sant <sachinp@xxxxxxxxxx>
> > Acked-by: Bernhard Walle <bwalle@xxxxxxx>
> >
> > diff --git a/task.c b/task.c
> > --- a/task.c
> > +++ b/task.c
> > @@ -2902,7 +2902,7 @@
> >  {
> >  	int i, c;
> >  	struct task_context *tcp;
> > -	char format[10];
> > +	char format[15];
> 
> 
>         c = strlen(buf);
>         sprintf(format, "[%c%dll%c]  ", '%', c,
>                 pc->output_radix == 10 ? 'u' : 'x');
> 
> Looks like it should be 11, no?  You have 6 characters + '\0' + the %d,
> which can be up to 1500 (BUFSIZE).  Of course, it wouldn't kill us to
> use snprintf, either.

You're right, it can only be a maximum of 11 bytes, i.e., either "[%20llu]  "
(decimal) or "[%16llx]  " (hex), plus their trailing NULLs.  It's apparently
worked OK by dumb luck by putting the NULL either in the stack variable location
of the preceding "tcp" pointer or the "buf[BUFSIZE]" array (I guess???), which
as it turns out, is safe to do. 

Anyway I'll bump it up...

Thanks,
  Dave
 

 

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility

[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux