Comparisons between types of different widths in a loop condition can cause the loop to behave unexpectedly. about libipt

[markus-metzger]

The uint8_t value is implicitly converted to size_t before performing the relational operation (on size_t). See §6.5.8 and §6.3.1.8 of C11.

[dandurisrihari]

Thank you for the response,

This implicit conversion prevents an overflow in the comparison part of the loop. The value of n is promoted to a larger type (size_t), and then the comparison is made. This means that as long as n is within the range of uint8_t, it will be correctly compared against the value returned by pt_filter_addr_ncfg().

The incrementing of n (++n) still occurs within the bounds of uint8_t. If n reaches 255 and is incremented, it will overflow to 0

Could you test by returning a higher dummy value from pt_filter_addr_ncfg

[markus-metzger]

There are only 4 filter configurations defined by the architecture and we reserve 4 more in the config structure.

If pt_filter_addr_ncfg() returned a big value, the loop would run indefinitely and pt_filter_addr_a/b() would allow accessing the filter configuration object out of bounds. It wouldn't even need to exceed the values supported by uint8_t to cause the latter.

[dandurisrihari]

Thanks. This should be fixed, right?

[markus-metzger]

I see nothing that would need fixing. If pt_filter_addr_ncfg() returned a wrong value, there would be bugs. But it doesn't return a wrong value and it couldn't be tricked into returning a wrong value for some bogus or malicious user input.

The returned type could be narrowed or the argument type of the filter index argument of pt_filter_addr_a/b/cfg() could be widened, but none of that changes the fact that only values that index a filter in struct pt_conf_addr_filter are allowed.