[ovs-dev] [PATCH] ossfuzz: Bug fix in odp and expr parse targets
Ben Pfaff
blp at ovn.org
Wed Oct 10 18:36:57 UTC 2018
On Wed, Oct 10, 2018 at 11:12:15AM +0200, bshastry at sect.tu-berlin.de wrote:
> From: Bhargava Shastry <bshastry at sect.tu-berlin.de>
>
> 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 <bshastry at sect.tu-berlin.de>
Thanks, applied to master. I made minor style changes to make it better
match how we usually write code.
More information about the dev
mailing list