The number of feature args could be incorrect

[waltdisgrace]

If the user-provided number of feature args is incorrect, then the call to the parse_feature_args function, which utilizes this number, could lead to an out-of-bounds error that fails the program at runtime.

[mulkieran]

@waltdisgrace Please generalize this issue so it covers the general case where the value for the number of feature args can be incorrect and lead to an out-of-bounds error. It describes the code in most, or possibly all, of the targets implemented.

[mulkieran]

Some notes:

What you really want to look for are parse::<Type> lines, as with: https://github.com/stratis-storage/devicemapper-rs/blob/master/src/lineardev.rs#L438. Note that this in the method from_raw_table. This is where the entire table is parsed from the test result returned by the ioctl. The method parse, exists because LinearDevTargetParams implements FromStr: https://github.com/stratis-storage/devicemapper-rs/blob/master/src/lineardev.rs#L362. This method invokes parse twice, one for FlakeyTargetParams and one for LinearTargetParams. LinearTargetParams implements FromStr but is too simple to have features. FlakeyTargetParams implements FromStr, and does have features. At https://github.com/stratis-storage/devicemapper-rs/blob/master/src/lineardev.rs#L302 the first argument parsed is the number of features args. The problems is that then we trust that number unhesitatingly. In particular, we use that number to select a slice from the remaining list of items. If that number is actually longer than the list of items, our code will crash. You can try that easily, with the Rust playground, using something like this:

fn main() {
    let v = vec![1, 2, 3, 4];
    let d = &v[2..5];
}

You will find that the same problem shows up in most but maybe not all of our implmentations of FromStr for other devices. For example:

https://github.com/stratis-storage/devicemapper-rs/blob/master/src/thinpooldev.rs#L92