CVE-2022-50778

In the Linux kernel, the following vulnerability has been resolved:

fortify: Fix _compiletimestrlen() under UBSANBOUNDSLOCAL

With CONFIGFORTIFY=y and CONFIGUBSANLOCALBOUNDS=y enabled, we observe a runtime panic while running Android's Compatibility Test Suite's (CTS) android.hardware.input.cts.tests. This is stemming from a strlen() call in hidinput_allocate().

__compiletime_strlen() is implemented in terms of __builtinobjectsize(), then does an array access to check for NUL-termination. A quirk of __builtinobjectsize() is that for strings whose values are runtime dependent, __builtinobjectsize(str, 1 or 0) returns the maximum size of possible values when those sizes are determinable at compile time. Example:

static const char *v = "FOO BAR"; static const char *y = "FOO BA"; unsigned long x (int z) { // Returns 8, which is: // max(__builtinobjectsize(v, 1), __builtinobjectsize(y, 1)) return __builtinobjectsize(z ? v : y, 1); }

So when FORTIFY_SOURCE is enabled, the current implementation of _compiletimestrlen() will try to access beyond the end of y at runtime using the size of v. Mixed with UBSANLOCALBOUNDS we get a fault.

hidinput_allocate() has a local C string whose value is control flow dependent on a switch statement, so _builtinobjectsize(str, 1) evaluates to the maximum string length, making all other cases fault on the last character check. hidinputallocate() could be cleaned up to avoid runtime calls to strlen() since the local variable can only have literal values, so there's no benefit to trying to fortify the strlen call site there.

Perform a _builtinconstantp() check against index 0 earlier in the macro to filter out the control-flow-dependant case. Add a KUnit test for checking the expected behavioral characteristics of FORTIFYSOURCE internals.