[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAD=FV=UapLj46M7jbyg-_qZN77iUjDD7B3sPdOU6wJazqjLtHQ@mail.gmail.com>
Date: Thu, 22 Aug 2024 07:20:18 -0700
From: Doug Anderson <dianders@...omium.org>
To: cong yang <yangcong5@...qin.corp-partner.google.com>
Cc: Charles Han <hanchunchao@...pur.com>, neil.armstrong@...aro.org,
quic_jesszhan@...cinc.com, maarten.lankhorst@...ux.intel.com,
mripard@...nel.org, tzimmermann@...e.de, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, liuyanming@...system.com
Subject: Re: [PATCH] drm/panel: fix null pointer dereference in hx83102_get_modes
Hi,
On Thu, Aug 22, 2024 at 3:02 AM cong yang
<yangcong5@...qin.corp-partner.google.com> wrote:
>
> Hi,
>
> Charles Han <hanchunchao@...pur.com> 于2024年8月22日周四 17:34写道:
> >
> > In hx83102_get_modes(), the return value of drm_mode_duplicate()
> > is assigned to mode, which will lead to a possible NULL
> > pointer dereference on failure of drm_mode_duplicate(). Add a
> > check to avoid npd.
> >
> > Fixes: 0ef94554dc40 ("drm/panel: himax-hx83102: Break out as separate driver")
> >
> > Signed-off-by: Charles Han <hanchunchao@...pur.com>
Note: please no blank line between "Fixes" and "Signed-off-by". All
tags should be together in the last "paragraph".
> > ---
> > drivers/gpu/drm/panel/panel-himax-hx83102.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-himax-hx83102.c b/drivers/gpu/drm/panel/panel-himax-hx83102.c
> > index 6e4b7e4644ce..7c2a5e9b7fb3 100644
> > --- a/drivers/gpu/drm/panel/panel-himax-hx83102.c
> > +++ b/drivers/gpu/drm/panel/panel-himax-hx83102.c
> > @@ -565,6 +565,10 @@ static int hx83102_get_modes(struct drm_panel *panel,
> > struct drm_display_mode *mode;
> >
> > mode = drm_mode_duplicate(connector->dev, m);
> > + if (!mode) {
> > + dev_err(&ctx->dsi->dev, "bad mode or failed to add mode\n");
> > + return -EINVAL;
> > + }
>
> In my V2 series, Doug suggested:
> "nit: no need for an error message when drm_mode_duplicate() fails.
> It is incredibly unlikely that the allocation will fail and the Linux"
>
> https://lore.kernel.org/all/CAD=FV=V2O2aFDVn5CjbXfgcOLkmNp-G3ChVqQKouB2mDB+NZug@mail.gmail.com/
Sorry for missing that we still need the NULL check and we should
definitely add it in. Cong is right, though, that the error message
here is pointless. The only way the function can fail is if a small
memory allocation fails. Even though such a small allocation failing
is basically impossible, kernel policy is still to check for NULL so
we should add the check. ...but the kernel already adds a WARN_ON
splat for all failed allocations so the extra message here is just
wasteful.
-Doug
Powered by blists - more mailing lists