Buffer overflow bug in MIKMIDISystemExclusiveCommand.manufacturerID

[snej]

The implementation of MIKMIDISystemExclusiveCommand.manufacturerID has a couple of problems:

    NSUInteger manufacturerIDLocation = _has3ByteManufacturerID ? 2 : 1;
    NSUInteger manufacturerIDLength = _has3ByteManufacturerID ? 2 : 1;
    NSData *idData = [self.internalData subdataWithRange:NSMakeRange(manufacturerIDLocation, manufacturerIDLength)];
    return *(UInt32 *)[idData bytes];

First is that it creates a 1- or 2-byte NSData object and then reads 4 bytes from its buffer, which is guaranteed to overrun the buffer. If you're lucky the bytes past the end will be zeroes and the result will be correct. If not, the result will be garbage. Worst case, you fall off the end of mapped memory and crash. (Also, while I haven't tried it, this is probably guaranteed to trigger the Address Sanitizer.)

The second problem is that it assumes the number is stored in the CPU's native byte order. I don't know the MIDI spec, but most cross-platform data formats/protocols use big-endian encoding, while all current Macs and iOS devices use little-endian.

Since all that needs to be read is at most a 2-byte number, I suggest just reading the individual bytes (as uint8_t) and combining them with a shift and OR.

[armadsen]

Fixed by 784a9c4. Thanks!