Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3026247imu; Sun, 9 Dec 2018 15:27:30 -0800 (PST) X-Google-Smtp-Source: AFSGD/X65Y0hPO1JC/MLaj6MTC5TRVDdfOJcIVqRLi93j9UvfCgKcDDxC9H/SmMfW/j21BI574wm X-Received: by 2002:a62:220d:: with SMTP id i13mr10172660pfi.162.1544398049932; Sun, 09 Dec 2018 15:27:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544398049; cv=none; d=google.com; s=arc-20160816; b=I5L1h33qljihgEk5MX7txnAdr8Ai/EMk+AvDiUkDR1XMiiQIvGg/o0EORR09Jz1odn 3iMFTYHquRRqwJxQTWoAD50y2sQHaQUKGNqeZ+TchoaMQ6hSNY2ei2KjowvN1YFpQ7QF 55PKJmiJnDg6p9YG8sljE+bJJ3YIR6fl1lFFQq8yV3xMvrZexxBzHuKUa33Xj0cNHspD k62SMxMloGMLOZO7NRRsS4+DokhqO9GEr5TLblea7FgufKGHcc9tfI99tguxf+fvombH Th6CS8gez/evHexkYjGZz5jtB1sfLGra+HSs8D3EELmIsZReBdaGw0BNktueaF66Vq34 lVGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=rOLsxQNhikwKLZvUeL7RUUjSdFgTG4cey/vi9ZCUD2o=; b=q7ETAoo6mph4R9CtI5NnRp270EuI3lHEt9jb5yXCDa8zNPmLTNLHQxGUTpNPqoTswv JmxBEL+WWgy5xLWI31waKWZSplQsWD4u2lFcsWqpYP8u3vUUVJDyMk27sCoyJ9en92g8 REe6C2JefS3QwTJfehMeD1dBMRaTf/50zcwYyTbPe7vbJ/a1ifKPedTZ6eFSuwV3DaKe uRgRbiT8s/dyemNt+Jet2MpTYlvrlVVT+OMPNpbPi6e3YXbiB9wJAZgxqGugvsgdiQ6y XDfqyFUk5ce4ymvCJDhdxsuFgesaKrF9bpldd38a2tJid2rlvAfJuI2Q6AbPR7dY4Fgb MeDA== ARC-Authentication-Results: i=1; mx.google.com; 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 g34si8777902pld.15.2018.12.09.15.27.12; Sun, 09 Dec 2018 15:27:29 -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; 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 S1727773AbeLIWWE (ORCPT + 99 others); Sun, 9 Dec 2018 17:22:04 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:35190 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726517AbeLIVzV (ORCPT ); Sun, 9 Dec 2018 16:55:21 -0500 Received: from pub.yeoldevic.com ([81.174.156.145] helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gW72k-0002pr-6i; Sun, 09 Dec 2018 21:55:18 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gW72h-0003Yn-IB; Sun, 09 Dec 2018 21:55:15 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Daniel Vetter" , "Sean Paul" , "Emil Lundmark" Date: Sun, 09 Dec 2018 21:50:33 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 230/328] drm: udl: Destroy framebuffer only if it was initialized In-Reply-To: X-SA-Exim-Connect-IP: 81.174.156.145 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.62-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Emil Lundmark commit fcb74da1eb8edd3a4ef9b9724f88ed709d684227 upstream. This fixes a NULL pointer dereference that can happen if the UDL driver is unloaded before the framebuffer is initialized. This can happen e.g. if the USB device is unplugged right after it was plugged in. As explained by Stéphane Marchesin: It happens when fbdev is disabled (which is the case for Chrome OS). Even though intialization of the fbdev part is optional (it's done in udlfb_create which is the callback for fb_probe()), the teardown isn't optional (udl_driver_unload -> udl_fbdev_cleanup -> udl_fbdev_destroy). Note that udl_fbdev_cleanup *tries* to be conditional (you can see it does if (!udl->fbdev)) but that doesn't work, because udl->fbdev is always set during udl_fbdev_init. Suggested-by: Sean Paul Reviewed-by: Sean Paul Acked-by: Daniel Vetter Signed-off-by: Emil Lundmark Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20180528142711.142466-1-lndmrk@chromium.org Signed-off-by: Sean Paul [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings --- drivers/gpu/drm/udl/udl_fb.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/drivers/gpu/drm/udl/udl_fb.c +++ b/drivers/gpu/drm/udl/udl_fb.c @@ -574,9 +574,11 @@ static void udl_fbdev_destroy(struct drm framebuffer_release(info); } drm_fb_helper_fini(&ufbdev->helper); - drm_framebuffer_unregister_private(&ufbdev->ufb.base); - drm_framebuffer_cleanup(&ufbdev->ufb.base); - drm_gem_object_unreference_unlocked(&ufbdev->ufb.obj->base); + if (ufbdev->ufb.obj) { + drm_framebuffer_unregister_private(&ufbdev->ufb.base); + drm_framebuffer_cleanup(&ufbdev->ufb.base); + drm_gem_object_unreference_unlocked(&ufbdev->ufb.obj->base); + } } int udl_fbdev_init(struct drm_device *dev)