On Wed, Oct 10, 2018 at 11:12:15AM +0200, [email protected] wrote: > From: Bhargava Shastry <[email protected]> > > This patch fixes a bug in the following test harnesses > - odp_target.c > - expr_parse_target.c > > The bug is as follows: > > We expect the fuzzed input to be a C string that does not contain a new > line character. This is because, the test code in OvS is built on > expecting string to not have a newline character (see for instance, > calls to ds_get_line() in test-odp.c etc.). > > The way we ensure fuzzed data is such a C string is as follows: > - Check size > 1 AND > - Check data[size - 1] is '\0' (NUL termination) AND > - Check that there is no '\n' in the C string that starts at data > > The third check is implemented using strchr. Our earlier logic was that, > were the C string to contain '\n', strchr would have a non-zero return > that can then be used to bail out early. > > The problem with this logic is that it does not consider the corner case > when data actually points to two or more C strings, like so: > \x01\x00\x0a\0x00 > > For this data sequence, strchr correctly returns "there is no newline > character" (in the first C string that is part of the sequence). > > But the data that is eventually passed to the fuzzed API > is the entire sequence of strings that may contain a new line in > between. > > This patch fixes the bug by adding an additional check: > - Check length of C string pointed to by data is actually equal to one > less than (due to NUL termination) size. > > This ensures that we are passing one and only one C string not > containing new line character to the fuzzed APIs. > > Signed-off-by: Bhargava Shastry <[email protected]>
Thanks, applied to master. I made minor style changes to make it better match how we usually write code. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
