linux-kernel - Re: [PATCH] drm/msm/dpu: avoid uninitialized variable use

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <76680ece-f88c-4960-a263-b96f64c35bbf@app.fastmail.com>
Date: Thu, 07 Aug 2025 17:08:31 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Dmitry Baryshkov" <dmitry.baryshkov@....qualcomm.com>,
 "Arnd Bergmann" <arnd@...nel.org>
Cc: "Rob Clark" <robin.clark@....qualcomm.com>,
 "Dmitry Baryshkov" <lumag@...nel.org>, "Dave Airlie" <airlied@...il.com>,
 "Simona Vetter" <simona@...ll.ch>, "Nathan Chancellor" <nathan@...nel.org>,
 "Abhinav Kumar" <quic_abhinavk@...cinc.com>,
 "Abhinav Kumar" <abhinav.kumar@...ux.dev>,
 "Jessica Zhang" <jessica.zhang@....qualcomm.com>,
 "Sean Paul" <sean@...rly.run>,
 "Marijn Suijten" <marijn.suijten@...ainline.org>,
 "Nick Desaulniers" <nick.desaulniers+lkml@...il.com>,
 "Bill Wendling" <morbo@...gle.com>, "Justin Stitt" <justinstitt@...gle.com>,
 "Antonino Maniscalco" <antomani103@...il.com>,
 "Konrad Dybcio" <konrad.dybcio@....qualcomm.com>,
 "Jun Nie" <jun.nie@...aro.org>, linux-arm-msm@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH] drm/msm/dpu: avoid uninitialized variable use

On Thu, Aug 7, 2025, at 10:09, Dmitry Baryshkov wrote:
> On Thu, Aug 07, 2025 at 09:19:48AM +0200, Arnd Bergmann wrote:
>>
>> The bug is real, but the suggestion from clang to set it to NULL is
>> unfortunately just as harmful as dereferencing a NULL pointer is little
>> better than uninitialized data.
>
>
> Having no plane->crtc is a valid setting and it is handled inside
> drm_atomic_helper_check_plane_state() by setting plane_state->visible =
> false and returning early. Setting crtc_state to NULL is a correct fix.
> Could you please send it?

Ah, I see. I saw the crtc_state dereference in

  WARN_ON(plane_state->crtc && plane_state->crtc != crtc_state->crtc);

but that is indeed guarded by the plane_state->crtc check.

Nathan's patch is sufficient then.

    Arnd