Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3004104pxb; Mon, 1 Nov 2021 06:11:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxA9eewIO9DbXnp2ToRjc0vuBcRwlRbtUOg0ku5InyJK/jcApuafwVVvwOhMmM9/Dyq1cv0 X-Received: by 2002:a05:6512:2393:: with SMTP id c19mr28447792lfv.518.1635772318717; Mon, 01 Nov 2021 06:11:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635772318; cv=none; d=google.com; s=arc-20160816; b=peFFRpaeuxQR74K6KZzREPKEL2CG5vG2EBd01pmIbWE9/KEGpTOWOTmvq08KHXHc8x MCywOJbpPVGYs0G1fZWXPqicW+3G73X4ZAvgj44XX3qtmikk3cUGJ+eehY2caQX41E/u XY/OKqNw3UZH1jI5g8y5ifEi/gnGiYekLKIGW0uT0qji3CMsPcTycrB691sd2LuEwCQ4 71WC03Uw6cC2GQHT3oG1vf5HZP4u9DCuSXm17bHfu0P3jyQ56AqmQvhhcjeX+mH64nsJ pcZgQVOxxTkV3ojBWxaWP2eNgz4ZQtbzS+fN2qo5xc2/TqKKh3JJ8dnvn1SeVSKe/2CZ 4vQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :organization:in-reply-to:subject:cc:to:from; bh=pfzaPRBRWP2gKN2uLOOajM00Imr4losj11Mu/HpbLG4=; b=vzyTOAVLaKqCjjPXhmyA3tB3/2xHj4KTPrghN8t7AvIBOI2jLMSY56BKlaOM6norjU 2ot0gf0lhT+s/JdoHSlIJjHXyVLK1gI79imxAxan8xP2ul6HVzZl4KkWcvLZ6Qe0kquq u0TYqulmtHZEGipd/MoNFBRfBuEfOwIJhUbcAZlV5TrWkrBKX469bsP/52DqfwelkZwB FPHX2tdU3yWzlKMi3Olr+kdy3JeetLlzudo5R0voPDxfi+epc2Rmj+wuiim3cHM4d4YX zXSaFxq6SwZZ1X/9fg/EoKyDZA2UIsSZsTxkuuJAbrscrnY2iQXz1tHggPmZ1iU064KI Hvqw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id sg11si27354775ejc.279.2021.11.01.06.11.33; Mon, 01 Nov 2021 06:11:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230438AbhKANJQ (ORCPT + 99 others); Mon, 1 Nov 2021 09:09:16 -0400 Received: from mga14.intel.com ([192.55.52.115]:49947 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230144AbhKANJP (ORCPT ); Mon, 1 Nov 2021 09:09:15 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10154"; a="231271754" X-IronPort-AV: E=Sophos;i="5.87,199,1631602800"; d="scan'208";a="231271754" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Nov 2021 06:06:42 -0700 X-IronPort-AV: E=Sophos;i="5.87,199,1631602800"; d="scan'208";a="500032544" Received: from mvtammin-mobl.ger.corp.intel.com (HELO localhost) ([10.251.214.228]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Nov 2021 06:06:38 -0700 From: Jani Nikula To: Perry Yuan , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter Cc: Perry.Yuan@amd.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Xinmei.Huang@amd.com, Ray.Huang@amd.com Subject: Re: [PATCH v2] drm/dp: Fix aux->transfer NULL pointer dereference on drm_dp_dpcd_access In-Reply-To: <20211101061053.38173-1-Perry.Yuan@amd.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20211101061053.38173-1-Perry.Yuan@amd.com> Date: Mon, 01 Nov 2021 15:06:36 +0200 Message-ID: <87a6iodnz7.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 01 Nov 2021, Perry Yuan wrote: > Fix below crash by adding a check in the drm_dp_dpcd_access which > ensures that aux->transfer was actually initialized earlier. Gut feeling says this is papering over a real usage issue somewhere else. Why is the aux being used for transfers before ->transfer has been set? Why should the dp helper be defensive against all kinds of misprogramming? BR, Jani. > > BUG: kernel NULL pointer dereference, address: 0000000000000000 > PGD 0 P4D 0 > Oops: 0010 [#1] SMP NOPTI > RIP: 0010:0x0 > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > RSP: 0018:ffffa8d64225bab8 EFLAGS: 00010246 > RAX: 0000000000000000 RBX: 0000000000000020 RCX: ffffa8d64225bb5e > RDX: ffff93151d921880 RSI: ffffa8d64225bac8 RDI: ffff931511a1a9d8 > RBP: ffffa8d64225bb10 R08: 0000000000000001 R09: ffffa8d64225ba60 > R10: 0000000000000002 R11: 000000000000000d R12: 0000000000000001 > R13: 0000000000000000 R14: ffffa8d64225bb5e R15: ffff931511a1a9d8 > FS: 00007ff8ea7fa9c0(0000) GS:ffff9317fe6c0000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: ffffffffffffffd6 CR3: 000000010d5a4000 CR4: 0000000000750ee0 > PKRU: 55555554 > Call Trace: > drm_dp_dpcd_access+0x72/0x110 [drm_kms_helper] > drm_dp_dpcd_read+0xb7/0xf0 [drm_kms_helper] > drm_dp_start_crc+0x38/0xb0 [drm_kms_helper] > amdgpu_dm_crtc_set_crc_source+0x1ae/0x3e0 [amdgpu] > crtc_crc_open+0x174/0x220 [drm] > full_proxy_open+0x168/0x1f0 > ? open_proxy_open+0x100/0x100 > do_dentry_open+0x156/0x370 > vfs_open+0x2d/0x30 > > v2: fix some typo > > Signed-off-by: Perry Yuan > --- > drivers/gpu/drm/drm_dp_helper.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c > index 6d0f2c447f3b..76b28396001a 100644 > --- a/drivers/gpu/drm/drm_dp_helper.c > +++ b/drivers/gpu/drm/drm_dp_helper.c > @@ -260,6 +260,10 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 request, > msg.buffer = buffer; > msg.size = size; > > + /* No transfer function is set, so not an available DP connector */ > + if (!aux->transfer) > + return -EINVAL; > + > mutex_lock(&aux->hw_mutex); > > /* -- Jani Nikula, Intel Open Source Graphics Center