On Tue, Aug 15, 2017 at 08:10:49AM -0700, Stephen Hemminger wrote: > On Sat, 12 Aug 2017 14:04:24 +0200 > Phil Sutter <p...@nwl.cc> wrote: > > > can_state_names array contains at most CAN_STATE_MAX fields, so allowing > > an index to it to be equal to that number is wrong. While here, also > > make sure the array is indeed that big so nothing bad happens if > > CAN_STATE_MAX ever increases. > > No more speculative bug fixes.
I don't think a bit of speculation regarding forwards-compatibility is a bad thing per se. In this case it is about the possibility for kernel code to add a new state to enum can_state. Older ip binaries will allow an index of CAN_STATE_MAX and therefore access data beyond end of can-state_names array. If you update linux headers but forget to add the new state to can_state_names array, the same will happen even if the sanity check for 'state' value is being fixed as by my patch. By specifying the size of can_state_names array upon definition, can_print_opt() will just print a null pointer which printf() can handle. Cheers, Phil
