You will have noticed above that the execv system call takes the name of the command to be executed as its first argument, rather than extracting it from the first element in the argv vector.
As a matter of fact, argv[0] and the name of the program being executed are not related in any way. There is a convention that argv[0] should be the name of the program - but nothing in the whole wide Unix world enforces that convention. Nothing keeps an attacker from running e.g. sendmail with argv[0] set to "/tmp/exploit".
Now sendmail, when it notices that it isn't able to deliver a message to the final recipient, will invoke a second sendmail process in order to create the error message and send it out. In several versions, it would create the new sendmail process by forking and then calling execv(argv[0], argv).
Which had interesting implications when invoked with argv[0] set to /tmp/exploit: instead of starting another sendmail process, this would run the exploit script - with effective root privilege.
This would have been merely a bizarre anecdote if this bug hadn't ocurred more often. For instance, a very similar problem existed in some versions of kvt, a setuid root terminal application in KDE 1.
The moral of this story? If you want to run another instance of your program, make sure the installation path is compiled into the program, rather than relying on argv[0].