Hello,
Our static analysis tool has identified a potential null-pointer dereference or
redundant null check related to the wait-completion synchronization mechanism in
amdgpu_dm.c in Linux 6.11.
Consider the following execution scenario:
dmub_aux_setconfig_callback() //731
if (adev->dm.dmub_notify) //734
complete(&adev->dm.dmub_aux_transfer_done); //737
The variable adev->dm.dmub_notify is checked by an if statement at Line 734,
which indicates that adev->dm.dmub_notify can NULL. Then, complete() is called
at Line 737 which wakes up the wait_for_completion().
Consider the wait_for_completion()
amdgpu_dm_process_dmub_aux_transfer_sync() //12271
p_notify = adev->dm.dmub_notify; //12278
wait_for_completion_timeout(&adev->dm.dmub_aux_transfer_done, ...); // 12287
if (p_notify->result != AUX_RET_SUCCESS) //12293
The value of adev->dm.dmub_notify is assigned to p_notify at Line 12278. If
adev->dm.dmub_notify at Line 734 is checked to be NULL, the value p_notify after
the wait_for_completion_timeout() at Line 12278 can also be NULL. However, it is
dereferenced at Line 12293 without rechecking, causing a possible null dereference.
In fact, dmub_aux_setconfig_callback() is registered only if
adev->dm.dmub_notify is checked to be not NULL:
adev->dm.dmub_notify = kzalloc(...); //2006
if (!adev->dm.dmub_notify) { //2007
......
goto error; //2009
} //2010
......
register_dmub_notify_callback(..., dmub_aux_setconfig_callback, ...) //2019
I am not sure if adev->dm.dmub_notify is assigned with NULL elsewhere. If not,
the if check at Line 734 can be redundant.
Any feedback would be appreciated, thanks!
Sincerely,
Tuo Li
