CommandExecutor input not being provided to fuzzer if only `arg_input_arg()` was called

[Slava0135]

Describe the bug

// command.rs
            InputLocation::Arg { argnum } => {
                let args = self.command.get_args();
...
                for (i, arg) in args.enumerate() { 
                    if i == *argnum {
                        debug_assert_eq!(arg, "DUMMY");
                        #[cfg(unix)]
                        cmd.arg(OsStr::from_bytes(input.target_bytes().as_slice()));
                        // There is an issue here that the chars on Windows are 16 bit wide.
                        // I can't really test it. Please open a PR if this goes wrong.
                        #[cfg(not(unix))]
                        cmd.arg(OsString::from_vec(input.target_bytes().as_vec()));
                    } else {
                        cmd.arg(arg);
                    }
                }

Because arg_input_arg() function doesn't actually add anything to command args, args size remains the same. If you only have that one argument (as fuzzer input) and nothing else, then args will be empty and the input won't be provided to target when fuzzing:

CommandExecutor::builder()
        .program("CMD")
        .arg_input_arg()
        .arg("DUMMY") // <-- you need this!!!
        .build(...)
        .unwrap();

To Reproduce Steps to reproduce the behavior:

1. Try fuzzing echo using this setup and pass a string as argument. Argument will not be passed.

Expected behavior It should work without using dummy value (or at least write this in doc!!!)

[domenukk]

@tokatoka you commented out the placeholder arg here: https://github.com/AFLplusplus/LibAFL/blame/173a9ad8eab4e9ea6e39a3b2cf40f18ad90943e3/libafl/src/executors/command.rs#L382 In PR #2167

Do you remember why? Can we un-comment it?

[tokatoka]

i don't remember anymore

[tokatoka]

i think i didn't understand the point of that DUMMY and deleted it by mistake. you can put it back

[domenukk]

Added a comment to make it clearer and hopefully avoid removal in the future. Seems like we don't have CI for this part of the code... @Slava0135 feel free to come up with some test and open a PR if you want, but otherwise #2543 should fix this issue. Thanks!