linux-kernel - [BUG] drm/amd/display: possible null-pointer dereference or redundant null check in amdgpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <65fe0dd4-e7bb-40d1-9b89-7b330984268a@gmail.com>
Date: Thu, 17 Oct 2024 16:43:04 +0800
From: Tuo Li <islituo@...il.com>
To: harry.wentland@....com, sunpeng.li@....com, Rodrigo.Siqueira@....com,
 alexander.deucher@....com, christian.koenig@....com, Xinhui.Pan@....com,
 airlied@...il.com, simona@...ll.ch, alex.hung@....com,
 hamza.mahfooz@....com, Roman.Li@....com, chiahsuan.chung@....com,
 aurabindo.pillai@....com, Wayne.Lin@....com, hersenxs.wu@....com
Cc: amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, baijiaju1990@...il.com
Subject: [BUG] drm/amd/display: possible null-pointer dereference or redundant
 null check in amdgpu_dm.c

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