In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix type of second parameter in odneditdpm_table() callback
With clang's kernel control flow integrity (kCFI, CONFIGCFICLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals:
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/amdgpusmu.c:3008:29: error: incompatible function pointer types initializing 'int (*)(void *, uint32t, long , uint32_t)' (aka 'int ()(void *, unsigned int, long *, unsigned int)') with an expression of type 'int (void *, enum PPODDPMTABLECOMMAND, long *, uint32t)' (aka 'int (void *, enum PPODDPMTABLECOMMAND, long *, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict] .odneditdpmtable = smuodeditdpmtable, ^~~~~~~~~~~~~~~~~~~~~ 1 error generated.
There are only two implementations of ->odneditdpmtable() in 'struct amdpmfuncs': smuodeditdpmtable() and ppodneditdpmtable(). One has a second parameter type of 'enum PPODDPMTABLECOMMAND' and the other uses 'u32'. Ultimately, smuodeditdpmtable() calls ->odeditdpmtable() from 'struct pptablefuncs' and ppodneditdpmtable() calls ->odneditdpmtable() from 'struct pphwmgrfunc', which both have a second parameter type of 'enum PPODDPMTABLECOMMAND'.
Update the type parameter in both the prototype in 'struct amdpmfuncs' and ppodneditdpmtable() to 'enum PPODDPMTABLECOMMAND', which cleans up the warning.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/50xxx/CVE-2022-50844.json",
"cna_assigner": "Linux"
}