Protection fault with 'time' command.

[Rob Landley]

On Friday 19 February 2010 00:03:26 Steven J. Hill wrote:
> Greetings.
>
> I am trying to track down an issue with the 'time' command giving me a
> general protection fault on my uClinux no-MMU ARM platform. I have
> tracked it down to the line in 'run_command' doing the 'execvp' call:
>
>    BB_EXECVP(cmd[0], cmd);
>
> If I run 'time' and do not give it any arguments, I get the fault. I
> decided to print the 'cmd' and 'cmd[0]' values:
>
>   cmd = 0x0x1004ff68
>   cmd[0] = 0x00000000

Let's see, cmd is the first argument to run_command, which is called from line 
414 in time_main where it's passed argv.

About five lines earlier (near the start of miscutils/time.c function 
time_main) we have:

        opt = getopt32(argv, "+vp");
        argv += optind

Except there's no check that there _were_ any any more arguments.  If all 
arguments have been consumed then *argv will then point to the NULL separating 
the command line arguments from the environment variables, which looks like 
what's happening.

I have no idea what the busybox argument parsing infrastructure looks like 
these days, I wrote completely different argument parsing infrastructure for 
toybox that doesn't use the libc getopt() at all.  In toybox I'd just say "<1" 
at the start of the opt definition string to indicate it needs at least one 
argument.  With this stuff I think you need to explicitly check that there are 
arguments remaining.

> However, if I provide just one argument, if it is bogus, then 'cmd[0]'
> has a valid pointer and I do not get the GP fault.

Yeah, because argv += optind would make argv[0] then point to that argument.

> One other thing to
> note is that my root file system is a ROMFS. I guess I'm looking for
> any ideas people might have. I'm not sure whether to blame busybox,
> uClibc, or what at this point. Thanks in advance.

I'd blame busybox.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds