From patchwork Wed Sep 12 18:04:43 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?VmlsbGUgU3lyasOkbMOk?= X-Patchwork-Id: 10598119 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 14AF7921 for ; Wed, 12 Sep 2018 18:05:04 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 002052A7E8 for ; Wed, 12 Sep 2018 18:05:03 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E75922A9A5; Wed, 12 Sep 2018 18:05:03 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 6F5B62A7E8 for ; Wed, 12 Sep 2018 18:05:03 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id F283F8811C; Wed, 12 Sep 2018 18:05:01 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id 37EEB8811C for ; Wed, 12 Sep 2018 18:05:01 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2018 11:05:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,365,1531810800"; d="scan'208";a="72437649" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by orsmga007.jf.intel.com with SMTP; 12 Sep 2018 11:04:44 -0700 Received: by stinkbox (sSMTP sendmail emulation); Wed, 12 Sep 2018 21:04:43 +0300 From: Ville Syrjala To: intel-gfx@lists.freedesktop.org Date: Wed, 12 Sep 2018 21:04:43 +0300 Message-Id: <20180912180443.28649-1-ville.syrjala@linux.intel.com> X-Mailer: git-send-email 2.16.4 In-Reply-To: <20180911165457.12651-1-ville.syrjala@linux.intel.com> References: <20180911165457.12651-1-ville.syrjala@linux.intel.com> MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH v2] drm/i915: Fix a potential integer overflow with framebuffers extending past 4 GiB X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP From: Ville Syrjälä If we have framebuffers that are >= 4GiB in size we will overflow the fb size check in intel_fill_fb_info(). Currently that is only possible with NV12 and CCS as offsets[1] may be anything between 0 and 0xffffffff. offsets[0] is currently required to be 0 so we can't hit the overflow with any single plane format (thanks to max fb size of 8kx8k and max stride of 32 KiB). In the future we may allow almost any framebuffer to exceed 4GiB in size so we really should fix the overflow. Not that the overflow is particularly dangerous. It's mostly just a sanity check against insane userspace. The display engine can't write to memory anyway so I suppose in the worst case we might anger the hw by attempting scanout past the end of the ggtt, or we might scan out some data that we're not supposed to see from other parts of the ggtt. Note that triggering this overflow depends on the driver aligning the fb height to the next tile boundary to push the calculated size above 4GiB. With linear buffers the effective tile height is one so that never happens, and the core already has a check for 32bit overflow of offsets[]+pitches[]*height. v2: Drop the unnecessary cast (Chris) Testcase: igt/kms_big_fb/x-tiled-addfb-size-offset-overflow Testcase: igt/kms_big_fb/y-tiled-addfb-size-offset-overflow Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 7fbc006be44a..6928dcc926ef 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2640,9 +2640,9 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv, max_size = max(max_size, offset + size); } - if (max_size * tile_size > obj->base.size) { - DRM_DEBUG_KMS("fb too big for bo (need %u bytes, have %zu bytes)\n", - max_size * tile_size, obj->base.size); + if (mul_u32_u32(max_size, tile_size) > obj->base.size) { + DRM_DEBUG_KMS("fb too big for bo (need %llu bytes, have %zu bytes)\n", + mul_u32_u32(max_size, tile_size), obj->base.size); return -EINVAL; }