linux-kernel - Re: [PATCHv4 4/6] drm/omap: fix incorrect union usage

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: <20181116223616.ojoq4qffmj2qo7gk@earth.universe>
Date:   Fri, 16 Nov 2018 23:36:16 +0100
From:   Sebastian Reichel <sre@...nel.org>
To:     Tomi Valkeinen <tomi.valkeinen@...com>
Cc:     Tony Lindgren <tony@...mide.com>, Pavel Machek <pavel@....cz>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        "H. Nikolaus Schaller" <hns@...delico.com>,
        dri-devel@...ts.freedesktop.org, linux-omap@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel@...labora.com
Subject: Re: [PATCHv4 4/6] drm/omap: fix incorrect union usage

Hi Tomi,

On Fri, Nov 16, 2018 at 03:41:24PM +0200, Tomi Valkeinen wrote:
> On 16/11/18 01:06, Sebastian Reichel wrote:
> > The DSI encoder sets dssdev->ops->dsi.set_config, which is stored at the
> > same offset as dssdev->ops->hdmi.set_hdmi_mode. The code in omap_encoder
> > only checks if dssdev->ops->hdmi.set_hdmi_mode is NULL. Due to the way
> > union works, it won't be NULL if dsi.set_config is set. This means
> > dsi_set_config will be called with config=hdmi_mode=false=NULL parameter
> > resulting in a NULL dereference. Also the dereference happens while
> > console is locked, so kernel hangs without any debug output (can be
> > avoided by fbmem's lockless_register_fb=1 parameter).
> > 
> > This fixes the issue by exiting early if the output type definitely
> > has no hdmi_set operations.
> > 
> > Fixes: 83910ad3f51fb ("drm/omap: Move most omap_dss_driver operations to omap_dss_device_ops")
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@...labora.com>
> > ---
> >  drivers/gpu/drm/omapdrm/omap_encoder.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c b/drivers/gpu/drm/omapdrm/omap_encoder.c
> > index 32bbe3a80e7d..ba0099f0644c 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_encoder.c
> > +++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
> > @@ -122,6 +122,14 @@ static void omap_encoder_mode_set(struct drm_encoder *encoder,
> >  
> >  	dssdev = omap_encoder->output;
> >  
> > +	/* The following operations access dssdev->ops->hdmi, which is a union
> > +	 * also used by DSI. This ensures, that the field does not have data
> > +	 * for DSI (or any other future output type).
> > +	 */
> > +	if (dssdev->output_type != OMAP_DISPLAY_TYPE_HDMI &&
> > +	    dssdev->output_type != OMAP_DISPLAY_TYPE_DVI)
> 
> Good catch.
> 
> Why DVI?
> 
> I think the whole code block starting from
> 
> /* Set the HDMI mode and HDMI infoframe if applicable. */
> 
> to the end of the function should be inside
> 
> if (dssdev->output_type == OMAP_DISPLAY_TYPE_HDMI)

When I identified the issue I whitelisted DVI, since I wasn't sure
if it also has the HDMI functionality. I planned to check the code
later and then forgot about it. You are right, this should only
check for HDMI.

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)