linux-kernel - Re: [PATCH] drm/msm/dp: populate connector of struct dp

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

Date:   Tue, 28 Dec 2021 10:50:42 -0800
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Kuogee Hsieh <quic_khsieh@...cinc.com>
Cc:     robdclark@...il.com, sean@...rly.run, swboyd@...omium.org,
        vkoul@...nel.org, daniel@...ll.ch, airlied@...ux.ie,
        agross@...nel.org, dmitry.baryshkov@...aro.org,
        quic_abhinavk@...cinc.com, aravindh@...eaurora.org,
        quic_sbillaka@...cinc.com, freedreno@...ts.freedesktop.org,
        dri-devel@...ts.freedesktop.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/msm/dp: populate connector of struct  dp_panel

On Tue 28 Dec 09:51 PST 2021, Kuogee Hsieh wrote:

> There is kernel crashed happen due to unable to handle kernel NULL

It would be wonderful, for my understanding today, as well as people in
the coming months to be able to search for the callstack etc on the
mailing list, if you could provide some details about the crash.

E.g. a callstack or description of when it happens.

> pointer dereference  of dp_panel->connector while running DP link
> layer compliance test case 4.2.2.6 (EDIDCorruption Detection).
> This patch will fixed the problem by populating connector of dp_panel.
> 
> Fixes: 7948fe12d47 ("drm/msm/dp: return correct edid checksum after corrupted edid checksum read")
> Signed-off-by: Kuogee Hsieh <quic_khsieh@...cinc.com>
> ---
>  drivers/gpu/drm/msm/dp/dp_panel.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c b/drivers/gpu/drm/msm/dp/dp_panel.c
> index 71db10c..6a938a2 100644
> --- a/drivers/gpu/drm/msm/dp/dp_panel.c
> +++ b/drivers/gpu/drm/msm/dp/dp_panel.c
> @@ -197,6 +197,8 @@ int dp_panel_read_sink_caps(struct dp_panel *dp_panel,
>  	kfree(dp_panel->edid);
>  	dp_panel->edid = NULL;
>  
> +	dp_panel->connector = connector;

So you have a dp_display_private object with a panel and a connector
allocated, but before you manage to associate the two you get a HPD
event and call this function, so you decide to stitch the two together
just here in some piece of code unrelated to the initialization of your
objects?

It sounds like we're lacking synchronization between the initialization
and the HPD interrupts and this would not be the correct solution.

Regards,
Bjorn

> +
>  	dp_panel->edid = drm_get_edid(connector,
>  					      &panel->aux->ddc);
>  	if (!dp_panel->edid) {
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>