From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B03FCC433EF for ; Wed, 6 Oct 2021 23:00:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8D82060F92 for ; Wed, 6 Oct 2021 23:00:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232227AbhJFXC2 (ORCPT ); Wed, 6 Oct 2021 19:02:28 -0400 Received: from mga11.intel.com ([192.55.52.93]:6249 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229582AbhJFXCZ (ORCPT ); Wed, 6 Oct 2021 19:02:25 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10129"; a="223515489" X-IronPort-AV: E=Sophos;i="5.85,352,1624345200"; d="scan'208";a="223515489" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2021 16:00:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,352,1624345200"; d="scan'208";a="624046966" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.171]) by fmsmga001.fm.intel.com with SMTP; 06 Oct 2021 16:00:10 -0700 Received: by stinkbox (sSMTP sendmail emulation); Thu, 07 Oct 2021 02:00:09 +0300 Date: Thu, 7 Oct 2021 02:00:09 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Doug Anderson Cc: dri-devel , "Siqueira, Rodrigo" , "Zuo, Jerry" , alexander.deucher@amd.com, "Wentland, Harry" , Kuogee Hsieh , Daniel Vetter , David Airlie , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , LKML Subject: Re: [PATCH v2] drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read Message-ID: References: <20211005192905.v2.1.Ib059f9c23c2611cb5a9d760e7d0a700c1295928d@changeid> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Patchwork-Hint: comment Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 06, 2021 at 03:45:07PM -0700, Doug Anderson wrote: > Hi, > > On Tue, Oct 5, 2021 at 7:29 PM Douglas Anderson wrote: > > > > In commit e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid > > corruption test") the function connector_bad_edid() started assuming > > that the memory for the EDID passed to it was big enough to hold > > `edid[0x7e] + 1` blocks of data (1 extra for the base block). It > > completely ignored the fact that the function was passed `num_blocks` > > which indicated how much memory had been allocated for the EDID. > > > > Let's fix this by adding a bounds check. > > > > This is important for handling the case where there's an error in the > > first block of the EDID. In that case we will call > > connector_bad_edid() without having re-allocated memory based on > > `edid[0x7e]`. > > > > Fixes: e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid corruption test") > > Reported-by: Ville Syrjälä > > Signed-off-by: Douglas Anderson > > Reviewed-by: Ville Syrjälä > > --- > > This problem report came up in the context of a patch I sent out [1] > > and this is my attempt at a fix. The problem predates my patch, > > though. I don't personally know anything about DP compliance testing > > and what should be happening here, nor do I apparently have any > > hardware that actually reports a bad EDID. Thus this is just compile > > tested. I'm hoping that someone here can test this and make sure it > > seems OK to them. > > > > Changes in v2: > > - Added a comment/changed math to help make it easier to grok. > > > > drivers/gpu/drm/drm_edid.c | 15 ++++++++++++--- > > 1 file changed, 12 insertions(+), 3 deletions(-) > > Pushed this to drm-misc-fixes since the commit it fixes is fairly old. > > fdc21c35aaa1 drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read BTW seems kasan caught this for us [1]. I didn't notice we had a bug open about it until now. Just Chris Wilson mentioned it to me in passing quite a while ago, and I totally forgot about it until I saw your other patch poking around the same code. [1] https://gitlab.freedesktop.org/drm/intel/-/issues/4106 -- Ville Syrjälä Intel