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:   Fri, 3 Jun 2022 10:55:08 +0000
From:   Vinod Polimera <vpolimer@....qualcomm.com>
To:     "dmitry.baryshkov@...aro.org" <dmitry.baryshkov@...aro.org>,
        "Vinod Polimera (QUIC)" <quic_vpolimer@...cinc.com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "freedreno@...ts.freedesktop.org" <freedreno@...ts.freedesktop.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "robdclark@...il.com" <robdclark@...il.com>,
        "dianders@...omium.org" <dianders@...omium.org>,
        "vpolimer@...cinc.com" <vpolimer@...cinc.com>,
        "swboyd@...omium.org" <swboyd@...omium.org>,
        "Kalyan Thota (QUIC)" <quic_kalyant@...cinc.com>
Subject: RE: [v1] drm/msm: add null checks for drm device to avoid crash
 during probe defer



> -----Original Message-----
> From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> Sent: Friday, June 3, 2022 3:07 PM
> To: Vinod Polimera (QUIC) <quic_vpolimer@...cinc.com>; dri-
> devel@...ts.freedesktop.org; linux-arm-msm@...r.kernel.org;
> freedreno@...ts.freedesktop.org; devicetree@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org; robdclark@...il.com;
> dianders@...omium.org; vpolimer@...cinc.com; swboyd@...omium.org;
> kalyant@...cinc.com
> Subject: Re: [v1] drm/msm: add null checks for drm device to avoid crash
> during probe defer
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> On 03/06/2022 12:22, Vinod Polimera wrote:
> > During probe defer, drm device is not initialized and an external
> > trigger to shutdown is trying to clean up drm device leading to crash.
> > Add checks to avoid drm device cleanup in such cases.
> >
> > BUG: unable to handle kernel NULL pointer dereference at virtual
> > address 00000000000000b8
> >
> > Call trace:
> >
> > drm_atomic_helper_shutdown+0x44/0x144
> > msm_pdev_shutdown+0x2c/0x38
> > platform_shutdown+0x2c/0x38
> > device_shutdown+0x158/0x210
> > kernel_restart_prepare+0x40/0x4c
> > kernel_restart+0x20/0x6c
> > __arm64_sys_reboot+0x194/0x23c
> > invoke_syscall+0x50/0x13c
> > el0_svc_common+0xa0/0x17c
> > do_el0_svc_compat+0x28/0x34
> > el0_svc_compat+0x20/0x70
> > el0t_32_sync_handler+0xa8/0xcc
> > el0t_32_sync+0x1a8/0x1ac
> >
> > Signed-off-by: Vinod Polimera <quic_vpolimer@...cinc.com>
> 
> Fixes ?
- Added fixes tag in v2.
> 
> > ---
> >   drivers/gpu/drm/msm/msm_drv.c | 6 +++++-
> >   1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c
> b/drivers/gpu/drm/msm/msm_drv.c
> > index 4448536..d62ac66 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > @@ -142,6 +142,9 @@ static void msm_irq_uninstall(struct drm_device
> *dev)
> >       struct msm_drm_private *priv = dev->dev_private;
> >       struct msm_kms *kms = priv->kms;
> >
> > +     if (!irq_has_action(kms->irq))
> > +             return;
> > +
> 
> Is this part required with
> https://patchwork.freedesktop.org/patch/485422/?series=103702&rev=1?
Yes, I feel like this is a better approach than maintaining a new variable. I see a couple of drivers following similar approach to safeguard uninstall without being install called.
> 
> >       kms->funcs->irq_uninstall(kms);
> >       if (kms->irq_requested)
> >               free_irq(kms->irq, dev);
> > @@ -259,6 +262,7 @@ static int msm_drm_uninit(struct device *dev)
> >
> >       ddev->dev_private = NULL;
> >       drm_dev_put(ddev);
> > +     priv->dev = NULL;
> 
> What are you trying to protect here?
If we get a shutdown call after probe defer, there can be stale pointer in priv->dev which is invalid that needs to be cleared.
> 
> >
> >       destroy_workqueue(priv->wq);
> >
> > @@ -1167,7 +1171,7 @@ void msm_drv_shutdown(struct platform_device
> *pdev)
> >       struct msm_drm_private *priv = platform_get_drvdata(pdev);
> >       struct drm_device *drm = priv ? priv->dev : NULL;
> >
> > -     if (!priv || !priv->kms)
> > +     if (!priv || !priv->kms || !drm)
> >               return;
> >
> >       drm_atomic_helper_shutdown(drm);
> 
> 
> --
> With best wishes
> Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ