[PATCH] drm/mst: Fix possible NULL pointer dereference in drm_dp_mst_process_up_req()
Souza, Jose
jose.souza at intel.com
Thu Jan 30 20:31:46 UTC 2020
On Thu, 2020-01-30 at 10:49 +0000, Lisovskiy, Stanislav wrote:
> On Wed, 2020-01-29 at 15:24 -0800, José Roberto de Souza wrote:
> > According to DP specification, DP_SINK_EVENT_NOTIFY is also a
> > broadcast message but as this function only handles
> > DP_CONNECTION_STATUS_NOTIFY I will only make the static
> > analyzer that caught this issue happy by not calling
> > drm_dp_get_mst_branch_device_by_guid() with a NULL guid, causing
> > drm_dp_mst_process_up_req() to return in the "if (!mstb)" right
> > bellow.
> >
> > Fixes: 9408cc94eb04 ("drm/dp_mst: Handle UP requests
> > asynchronously")
> > Cc: Lyude Paul <lyude at redhat.com>
> > Cc: Sean Paul <sean at poorly.run>
> > Signed-off-by: José Roberto de Souza <jose.souza at intel.com>
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 23cf46bfef74..a811247cecfe 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -3829,7 +3829,8 @@ drm_dp_mst_process_up_req(struct
> > drm_dp_mst_topology_mgr *mgr,
> > else if (msg->req_type == DP_RESOURCE_STATUS_NOTIFY)
> > guid = msg->u.resource_stat.guid;
> >
> > - mstb = drm_dp_get_mst_branch_device_by_guid(mgr, guid);
> > + if (guid)
> > + mstb =
> > drm_dp_get_mst_branch_device_by_guid(mgr, guid);
> > } else {
> > mstb = drm_dp_get_mst_branch_device(mgr, hdr->lct, hdr-
> > > rad);
> > }
>
> Been fixing something similar in dp mst topology a while ago, was
> also
> similar NULL pointer dereference. Fix seems to be correct, however I
> would still have a look at least, how it affects overall logic then.
> I mean now we don't call drm_dp_get_mst_branch_device_by_guid if guid
> is NULL - that's ok, however it means that mstb will not get
> initialized and how this is going to affect the code flow then?
>
> SHould we may be still try to initialize mstb somehow and check
> guid actually inside of this drm_dp_get_mst_branch_device_by_guid
> function? Or call drm_dp_get_mst_branch_device?
>
> I'm not stating anything here, just asking question to
> make the overall picture bit more clear.
Well it do not matters if it set mstb if on the next block it will only
handle messages of DP_CONNECTION_STATUS_NOTIFY type but for sure we
should handle this two other message types.
>
> Anyways, even wrong logic to me is better than crashing so,
>
> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy at intel.com>
Thanks
>
>
>
More information about the dri-devel
mailing list