{"affected":[],"cveId":"CVE-2022-50778","cwes":[],"description":"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.","epss":null,"exploits":[],"kev":null,"metrics":[],"modifiedAt":1794312600177,"publishedAt":1766582164640,"references":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"url":"https://git.kernel.org/stable/c/5d59ad2bfb35fccfe2ad5e8bb8801f6224d3f7d4"},{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"url":"https://git.kernel.org/stable/c/d07c0acb4f41cc42a0d97530946965b3e4fa68c1"},{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"url":"https://git.kernel.org/stable/c/ed42391164e6839a48aaf4c53eefda516835e799"}],"remediation":[],"revision":"c1440c808498fa559bd62f1ccc04bec93d391d7409fe6de45b132a6628324252","sources":[{"modifiedAt":1794312600177,"name":"NVD","retrievedAt":1794313085159,"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50778"}],"ssvc":null,"status":"published","title":"CVE-2022-50778","updatedAt":1794313085159}