Received: by 10.223.185.116 with SMTP id b49csp596900wrg; Tue, 20 Feb 2018 04:50:26 -0800 (PST) X-Google-Smtp-Source: AH8x224pBF1zKcNBrta7NIj8PNKMSQb0uP2vm790nkKa0g5qMy5UtjXs65KqgqiTjb5Gocbc/YC6 X-Received: by 10.101.86.198 with SMTP id w6mr14879849pgs.434.1519131026323; Tue, 20 Feb 2018 04:50:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519131026; cv=none; d=google.com; s=arc-20160816; b=C6WefDQh5zvjuiv0t1lwqmqyHBI2uvEH6zDB0/BGgEw67jQQ14sqVLceuooE0tbZnz 9/mQFpePV+F0I/1E3uIabrHsis2lMSqN4JNRrVLTB+TV/iLK4UbE1xHLXDpKYUntLcTG F0kdhj0xRu4kYzX8J1oHo4SFfmjNi0hpoCkPrudyFZqghb37ZIN8Xq2RBqRgu+YW1b2q Nigmxgo8bQj9DzvjBkbwuPMEV779Lv5SNom9MXjachz6NVAnh/SJnl+R5k2TRaGroCkF zm4xDpL8owQqZ/rvWBjYCBYQDr9AOuAQParSRqfOIgPQA5KjElNHpM2FCVrX8c+sZQwQ 6jcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:mail-followup-to:message-id:subject:cc:to:from:date :dkim-signature:arc-authentication-results; bh=Uz4OuWNnv0LPhol+vp+GaLFv2P3IdfXA+IvgA9c5aW8=; b=i2Nk9mIY11iiu+sVV8NAfRDYAX3xws6B3v6GNVLB58ghJTpcDvAujN42uh3JQaO3R1 RJp9sOsnFnyaw49vlfudEbbUH9GgthRLa/X4uPPGTVdI53V0q/8aCQ3RW0Q8q+04eI9K uiFN/MW5Ecduh5RmKxZfi0GZOxUbuZDHYIaEzD37JU7L/SaUV9VWsh2y208+P956Q+h5 01FpOPdgWNNzWvHLM3SK/11rHcgmHyf5+hBWaG0zufL78NJTaMWYJySoodZnNcL5jHZ1 uOzNAv2dMcZe38qN5xta6gs4aYrAX7XwIC3syNya1/n7Sqy/57HT1V8m4XQFxwy0zyY/ zLFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@ffwll.ch header.s=google header.b=k9o74lCS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q15si5009129pgc.746.2018.02.20.04.50.11; Tue, 20 Feb 2018 04:50:26 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@ffwll.ch header.s=google header.b=k9o74lCS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751786AbeBTMtY (ORCPT + 99 others); Tue, 20 Feb 2018 07:49:24 -0500 Received: from mail-wr0-f193.google.com ([209.85.128.193]:33170 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751539AbeBTMtX (ORCPT ); Tue, 20 Feb 2018 07:49:23 -0500 Received: by mail-wr0-f193.google.com with SMTP id s5so14048362wra.0 for ; Tue, 20 Feb 2018 04:49:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=Uz4OuWNnv0LPhol+vp+GaLFv2P3IdfXA+IvgA9c5aW8=; b=k9o74lCS35GxqlSgF3lXqgGW0707v1VSBMAVGN5VuFhUoXZ8mpdQhAyrLfqAqoK5Ok uUnqSG1C/n4GUoc7ukxZvrmWtSBmb17HkdEUtbHO8aFhqCv4zCGsph/1rujrPPoVcEq2 HxgTZCK2jJ3hHGr/KXig2BMoFzigYDZfXcA8c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=Uz4OuWNnv0LPhol+vp+GaLFv2P3IdfXA+IvgA9c5aW8=; b=mc08Tf+oN+JSIxarp650iJcdKmjuU9yT1IYQy9xY7GZ5Ek98/FXcGxcmowlUMS1hCo RK9LQq/Me9MM/sYx9x3090n8VVkeuHHOLXH5QtEzyNU8bIUHWOxCLEfJNnrNWY8RqvgE Ga6jBlLieoUHWipHMOrTYQJU/+oPkhN/b8uyMa9aoAEqh9bZvgxY4LtQUA7OLHcJtbti RlyNaoemTj1sWbVu4ARTOAV5+rvrO+JDPLidCyg++RowFhBqLT/DXiiMP7DAKuvIhKbw gNeiBDET8CafdsqCcvhWnD/dU6/W8JkO1BeOy+X235syHLqgueJub4QilC6zMRpwaNx9 1JzQ== X-Gm-Message-State: APf1xPCAvwvZxXSnZ0PNMomwpTgQuNHK77N1zGCTN9limvNwIzHinFdA hImGkm7H+UnMsnw8HLWm97UlwQ== X-Received: by 10.80.172.131 with SMTP id x3mr187407edc.260.1519130961906; Tue, 20 Feb 2018 04:49:21 -0800 (PST) Received: from phenom.ffwll.local (212-51-149-109.fiber7.init7.net. [212.51.149.109]) by smtp.gmail.com with ESMTPSA id g2sm4182553eda.85.2018.02.20.04.49.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 20 Feb 2018 04:49:21 -0800 (PST) Date: Tue, 20 Feb 2018 13:49:19 +0100 From: Daniel Vetter To: Oleksandr Andrushchenko Cc: Oleksandr Andrushchenko , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, airlied@linux.ie, daniel.vetter@intel.com Subject: Re: [PATCH] drm/simple_kms_helper: Fix NULL pointer dereference with no active CRTC Message-ID: <20180220124919.GS22199@phenom.ffwll.local> Mail-Followup-To: Oleksandr Andrushchenko , Oleksandr Andrushchenko , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, airlied@linux.ie, daniel.vetter@intel.com References: <1518511456-28257-1-git-send-email-andr2000@gmail.com> <20180219143002.GC22199@phenom.ffwll.local> <20180220111748.GJ22199@phenom.ffwll.local> <38f46c4f-3c0d-cf86-3d50-cf0f9313b205@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <38f46c4f-3c0d-cf86-3d50-cf0f9313b205@gmail.com> X-Operating-System: Linux phenom 4.14.0-3-amd64 User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 20, 2018 at 02:36:05PM +0200, Oleksandr Andrushchenko wrote: > On 02/20/2018 01:17 PM, Daniel Vetter wrote: > > On Mon, Feb 19, 2018 at 04:58:43PM +0200, Oleksandr Andrushchenko wrote: > > > On 02/19/2018 04:30 PM, Daniel Vetter wrote: > > > > On Tue, Feb 13, 2018 at 10:44:16AM +0200, Oleksandr Andrushchenko wrote: > > > > > From: Oleksandr Andrushchenko > > > > > > > > > > It is possible that drm_simple_kms_plane_atomic_check called > > > > > with no CRTC set, e.g. when user-space application sets CRTC_ID/FB_ID > > > > > to 0 before doing any actual drawing. This leads to NULL pointer > > > > > dereference because in this case new CRTC state is NULL and must be > > > > > checked before accessing. > > > > > > > > > > Signed-off-by: Oleksandr Andrushchenko > > > > > --- > > > > > drivers/gpu/drm/drm_simple_kms_helper.c | 6 ++++-- > > > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c b/drivers/gpu/drm/drm_simple_kms_helper.c > > > > > index 9ca8a4a59b74..a05eca9cec8b 100644 > > > > > --- a/drivers/gpu/drm/drm_simple_kms_helper.c > > > > > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c > > > > > @@ -121,8 +121,10 @@ static int drm_simple_kms_plane_atomic_check(struct drm_plane *plane, > > > > > pipe = container_of(plane, struct drm_simple_display_pipe, plane); > > > > > crtc_state = drm_atomic_get_new_crtc_state(plane_state->state, > > > > > &pipe->crtc); > > > > > - if (!crtc_state->enable) > > > > > - return 0; /* nothing to check when disabling or disabled */ > > > > > + > > > > > + if (!crtc_state || !crtc_state->enable) > > > > > + /* nothing to check when disabling or disabled or no CRTC set */ > > > > > + return 0; > > > > > if (crtc_state->enable) > > > > > drm_mode_get_hv_timing(&crtc_state->mode, > > > > Hm, this is a bit annoying, since the can_position = false parameter to > > > > drm_atomic_helper_check_plane_state is supposed to catch all this. Would > > > > moving all the checks after the call to that helper, and gating them on > > > > plane_state->visible also work? > > > Yes, it does work if this is what you mean: > > I wasn't sure, thanks for figuring this out! > > > > > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c > > > b/drivers/gpu/drm/drm_simple_kms_helper.c > > > index a05eca9cec8b..c48858bb2823 100644 > > > --- a/drivers/gpu/drm/drm_simple_kms_helper.c > > > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c > > > @@ -122,14 +122,6 @@ static int drm_simple_kms_plane_atomic_check(struct > > > drm_plane *plane, > > > ??????? crtc_state = drm_atomic_get_new_crtc_state(plane_state->state, > > > &pipe->crtc); > > > > > > -?????? if (!crtc_state || !crtc_state->enable) > > > -?????????????? /* nothing to check when disabling or disabled or no CRTC > > > set */ > > > -?????????????? return 0; > > > - > > > -?????? if (crtc_state->enable) > > > -?????????????? drm_mode_get_hv_timing(&crtc_state->mode, > > > -????????????????????????????????????? &clip.x2, &clip.y2); > > > - > > > ??????? ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state, > > > ????????????????????????????????????????????????? &clip, > > > DRM_PLANE_HELPER_NO_SCALING, > > > @@ -138,6 +130,13 @@ static int drm_simple_kms_plane_atomic_check(struct > > > drm_plane *plane, > > > ??????? if (ret) > > > ??????????????? return ret; > > > > > > +?????? if (!plane_state->visible || !crtc_state->enable) > > > +?????????????? return 0; /* nothing to check when disabling or disabled */ > > if (!plane_state->visible) { > > WARN_ON(crtc_state->enabled); > > return 0; > > } > > > > The helper call above should guarantee this. > Yes, but I still see cases when crtc_state is NULL, thus > making crtc_state->enable to fail Right, when the plane is completely off there's no CRTC state. Correct check should be WARN_ON(crtc_state && crtc_state->enabled); > > > + > > > +?????? if (plane_state->visible && crtc_state->enable) > > Similar here. > > > > > +?????????????? drm_mode_get_hv_timing(&crtc_state->mode, > > > +????????????????????????????????????? &clip.x2, &clip.y2); > > > + > > > ??????? if (!plane_state->visible) > > > ??????????????? return -EINVAL; > > This can now be removed, the plane helper takes care of checking for > > plane_state->visible != crtc_state->enable. Please also remove. > > > > > > We'd need to add a guarantee to drm_atomic_helper_check_plane_state that > > > > it can cope with crtc_state == NULL, but I think that's a good idea > > > > anyway. Atm it shouldn't end up looking at the crtc_state pointer in that > > > > case. > > > It doesn't look at it at the moment > > > > Otherwise we'll just go with your fix, but it feels all a bit too fragile, > > > > hence why I want to explore more robust options a bit. > > > At list with the change above it passes my test which failed > > > before. Although I cannot confirm it works for others, but it > > > certainly does for me. > > > > -Daniel > > > Do you want me to send v1 with the code above? > > Yes please, with my above cleanup suggestions. > Please see the patch under test attached (I believe it is what you mean, > with the only change that > ??? if (!plane_state->visible) { > ??? ??? *if (crtc_state)* > ??? ??? ??? WARN_ON(crtc_state->enable); > ??? ??? return 0; > ??? } > check is used). > > Whith this patch + additional logs I have: > > [?? 18.939204] [drm:drm_ioctl [drm]] pid=2105, dev=0xe200, auth=1, > DRM_IOCTL_MODE_ATOMIC > [...] > [?? 18.939681] [drm:drm_atomic_set_crtc_for_plane [drm]] Link plane state > 00000000c302cbbf to [NOCRTC] > [?? 18.939822] [drm:drm_atomic_set_fb_for_plane [drm]] Set [NOFB] for plane > state 00000000c302cbbf > [?? 18.939963] [drm:drm_atomic_print_state [drm]] checking 000000000bc224e7 > [?? 18.939988] vdispl vdispl.0: [drm] plane[29]: plane-0 > [?? 18.940003] vdispl vdispl.0: [drm]?? crtc=(null) > [?? 18.940018] vdispl vdispl.0: [drm]?? fb=0 > [?? 18.940032] vdispl vdispl.0: [drm]?? crtc-pos=0x0+0+0 > [?? 18.940048] vdispl vdispl.0: [drm] > src-pos=0.000000x0.000000+0.000000+0.000000 > [?? 18.940067] vdispl vdispl.0: [drm]?? rotation=1 > [?? 18.940199] [drm:drm_atomic_check_only [drm]] checking 000000000bc224e7 > [?? 18.940226] ================================= plane_state->visible 0 > crtc_state?????????? (null) > [...] > [?? 18.978146] [drm:drm_atomic_set_crtc_for_plane [drm]] Link plane state > 000000006bd50580 to [CRTC:30:crtc-0] > [?? 18.978292] [drm:drm_atomic_set_fb_for_plane [drm]] Set [FB:35] for plane > state 000000006bd50580 > [?? 18.978993] [drm:drm_atomic_set_mode_prop_for_crtc [drm]] Set > [MODE:1024x768] for CRTC state 00000000e5a28f6a > [?? 18.979425] [drm:drm_atomic_check_only [drm]] checking 000000000bc224e7 > [?? 18.979540] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] > [CRTC:30:crtc-0] mode changed > [?? 18.979632] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] > [CRTC:30:crtc-0] enable changed > [?? 18.979708] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] > [CRTC:30:crtc-0] active changed > [?? 18.979792] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] > Updating routing for [CONNECTOR:28:Virtual-1] > [?? 18.979877] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] > [CONNECTOR:28:Virtual-1] using [ENCODER:31:None-31] on [CRTC:30:crtc-0] > [?? 18.979960] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] > [CRTC:30:crtc-0] needs all connectors, enable: y, active: y > [?? 18.980139] [drm:drm_atomic_add_affected_connectors [drm]] Adding all > current connectors for [CRTC:30:crtc-0] to 000000000bc224e7 > [?? 18.980184] ================================= plane_state->visible 0 > crtc_state 00000000e5a28f6a > [?? 18.980205] crtc_state->enable 1 > > *[?? 19.022608] WARNING: CPU: 1 PID: 2105 at > drivers/gpu/drm/drm_simple_kms_helper.c:137 > drm_simple_kms_plane_atomic_check+0xdc/0xf8 [drm_kms_helper]* > > [...] > > [?? 19.113601] ================================= plane_state->visible 0 > crtc_state 00000000e5a28f6a > [?? 19.113623] crtc_state->enable 1 > [?? 19.113792] WARNING: CPU: 1 PID: 2105 at > drivers/gpu/drm/drm_simple_kms_helper.c:137 > drm_simple_kms_plane_atomic_check+0xdc/0xf8 [drm_kms_helper] > > [...] > > And finally > > [?? 19.340249] ================================= plane_state->visible 0 > crtc_state 0000000036a1b1f5 > [?? 19.340271] crtc_state->enable 0 > > So, it seems that crtc_state can still be NULL if "!plane_state->visible" > making > NULL pointer dereference, so we need a check for that. > Yet, !plane_state->visible && crtc_state->enable makes WARN_ON to fire > always. So, probably we may want removing it. > > > > Thanks, Daniel > Thank you, > Oleksandr > From dbcce708b237740158a2c16029c56a579324f269 Mon Sep 17 00:00:00 2001 > From: Oleksandr Andrushchenko > Date: Tue, 13 Feb 2018 10:32:20 +0200 > Subject: [PATCH] drm/simple_kms_helper: Fix NULL pointer dereference with no > active CRTC > > It is possible that drm_simple_kms_plane_atomic_check called > with no CRTC set, e.g. when user-space application sets CRTC_ID/FB_ID > to 0 before doing any actual drawing. This leads to NULL pointer > dereference because in this case new CRTC state is NULL and must be > checked before accessing. > > Signed-off-by: Oleksandr Andrushchenko > --- > drivers/gpu/drm/drm_simple_kms_helper.c | 15 +++++++-------- > 1 file changed, 7 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c b/drivers/gpu/drm/drm_simple_kms_helper.c > index 9ca8a4a59b74..f54711ff9767 100644 > --- a/drivers/gpu/drm/drm_simple_kms_helper.c > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c > @@ -121,12 +121,6 @@ static int drm_simple_kms_plane_atomic_check(struct drm_plane *plane, > pipe = container_of(plane, struct drm_simple_display_pipe, plane); > crtc_state = drm_atomic_get_new_crtc_state(plane_state->state, > &pipe->crtc); > - if (!crtc_state->enable) > - return 0; /* nothing to check when disabling or disabled */ > - > - if (crtc_state->enable) > - drm_mode_get_hv_timing(&crtc_state->mode, > - &clip.x2, &clip.y2); > > ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state, > &clip, > @@ -136,8 +130,13 @@ static int drm_simple_kms_plane_atomic_check(struct drm_plane *plane, > if (ret) > return ret; > > - if (!plane_state->visible) > - return -EINVAL; > + if (!plane_state->visible) { > + if (crtc_state) > + WARN_ON(crtc_state->enable); > + return 0; > + } > + > + drm_mode_get_hv_timing(&crtc_state->mode, &clip.x2, &clip.y2); lgtm. With or without the bikeshed to pull the crtc_state check into the WARN_ON. Reviewed-by: Daniel Vetter Please resubmit as a stand-alone patch, patchwork can't pull patches out of attachments :-/ -Daniel > > if (!pipe->funcs || !pipe->funcs->check) > return 0; > -- > 2.7.4 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch