Possible bug in MutInput

[deepaksirone]

Hello, I was looking at the code for tracking the metadata corresponding to the input in fuzzer/src/mut_input/mut_input.rs.

fn push(&mut self, mut ele: Vec<u8>, sign: bool) {
        if ele.len() != 1 && ele.len() != 2 && ele.len() != 4 && ele.len() != 8 {
            for _ in 0..ele.len() {
                self.meta.push(InputMeta::new(sign, self.value.len(), 1));
            }
        } else {
            self.meta
                .push(InputMeta::new(sign, self.value.len(), ele.len()));
        }
        self.value.append(&mut ele);
    }

Shouldn't the for loop for as follows:

            for i in 0..ele.len() {
                self.meta.push(InputMeta::new(sign, self.value.len() + i, 1));
            }

As we are considering each byte individually? In the present implementation it seems that only the first byte ends up being mutated if the number of bytes inserted is not 1, 2, 4 or 8.

[DataCorrupted]

The number of bytes is 1, 2, 4, etc. corresponds to int8_t/uint8_t, int16_t/uint16_t, int32_t/uint32_t, etc. respectively. The intuition is that we want to mutate an integer as a whole instead of a byte-wise mutation. A byte-wise mutation over integers wouldn't make sense.

In mut_input::rw::update_val_in_buf(mut_input/rw.rs:64) you can see how we combine bytes as an integer when mutating.

[deepaksirone]

That makes sense for integer types, but for character arrays which are used in strcmp (and compared with a runtime generated array) bytewise mutation might make sense.

[deepaksirone]

@DataCorrupted Thanks for your answer, I understand that this was a design choice. Closing the issue.