{"id":"CVE-2022-50778","summary":"fortify: Fix __compiletime_strlen() under UBSAN_BOUNDS_LOCAL","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nfortify: Fix __compiletime_strlen() under UBSAN_BOUNDS_LOCAL\n\nWith CONFIG_FORTIFY=y and CONFIG_UBSAN_LOCAL_BOUNDS=y enabled, we observe\na runtime panic while running Android's Compatibility Test Suite's (CTS)\nandroid.hardware.input.cts.tests. This is stemming from a strlen()\ncall in hidinput_allocate().\n\n__compiletime_strlen() is implemented in terms of __builtin_object_size(),\nthen does an array access to check for NUL-termination. A quirk of\n__builtin_object_size() is that for strings whose values are runtime\ndependent, __builtin_object_size(str, 1 or 0) returns the maximum size\nof possible values when those sizes are determinable at compile time.\nExample:\n\n  static const char *v = \"FOO BAR\";\n  static const char *y = \"FOO BA\";\n  unsigned long x (int z) {\n      // Returns 8, which is:\n      // max(__builtin_object_size(v, 1), __builtin_object_size(y, 1))\n      return __builtin_object_size(z ? v : y, 1);\n  }\n\nSo when FORTIFY_SOURCE is enabled, the current implementation of\n__compiletime_strlen() will try to access beyond the end of y at runtime\nusing the size of v. Mixed with UBSAN_LOCAL_BOUNDS we get a fault.\n\nhidinput_allocate() has a local C string whose value is control flow\ndependent on a switch statement, so __builtin_object_size(str, 1)\nevaluates to the maximum string length, making all other cases fault on\nthe last character check. hidinput_allocate() could be cleaned up to\navoid runtime calls to strlen() since the local variable can only have\nliteral values, so there's no benefit to trying to fortify the strlen\ncall site there.\n\nPerform a __builtin_constant_p() check against index 0 earlier in the\nmacro to filter out the control-flow-dependant case. Add a KUnit test\nfor checking the expected behavioral characteristics of FORTIFY_SOURCE\ninternals.","modified":"2026-04-02T08:28:45.537746Z","published":"2025-12-24T13:06:07.182Z","database_specific":{"cna_assigner":"Linux","osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/50xxx/CVE-2022-50778.json"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/5d59ad2bfb35fccfe2ad5e8bb8801f6224d3f7d4"},{"type":"WEB","url":"https://git.kernel.org/stable/c/d07c0acb4f41cc42a0d97530946965b3e4fa68c1"},{"type":"WEB","url":"https://git.kernel.org/stable/c/ed42391164e6839a48aaf4c53eefda516835e799"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/50xxx/CVE-2022-50778.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50778"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"3009f891bb9f328945ebd5b71e12df7e2467f3dd"},{"fixed":"ed42391164e6839a48aaf4c53eefda516835e799"},{"fixed":"5d59ad2bfb35fccfe2ad5e8bb8801f6224d3f7d4"},{"fixed":"d07c0acb4f41cc42a0d97530946965b3e4fa68c1"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2022-50778.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"5.16.0"},{"fixed":"5.19.17"}]},{"type":"ECOSYSTEM","events":[{"introduced":"5.20.0"},{"fixed":"6.0.3"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2022-50778.json"}}],"schema_version":"1.7.5"}