From patchwork Wed May 4 22:48:49 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thadeu Lima de Souza Cascardo X-Patchwork-Id: 1626651 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=ALclfhw3; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4KtsVx0NDqz9sCq for ; Thu, 5 May 2022 08:50:49 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1nmNpU-0003lR-15; Wed, 04 May 2022 22:50:44 +0000 Received: from smtp-relay-canonical-1.internal ([10.131.114.174] helo=smtp-relay-canonical-1.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1nmNpR-0003kk-Vw for kernel-team@lists.ubuntu.com; Wed, 04 May 2022 22:50:41 +0000 Received: from localhost.localdomain (1.general.cascardo.us.vpn [10.172.70.58]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-canonical-1.canonical.com (Postfix) with ESMTPSA id D4DBC3F130 for ; Wed, 4 May 2022 22:50:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1651704641; bh=2pX6+9fIKfW4YLzt+0SoTKu1F+zT++N0NDs7W8seNLM=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=ALclfhw3lvmAarknXjCZ9kg5fVRYC/jp8mbQq/+KqGEq/rb62uT9vnJWbY50a+/GA MdyEnyZmN2SeWyXxjQ5S2JnOQA78zV9GVfCRSufaoK6j7V8xfIIKtDkns9tqULbz1p U3o3gm4OVS0r7MFaMUJ5eAiV5Xy578VwFWkWoB6C0ToX1bqjimhZ47Z4twQthz5Tx7 TOhKIhATMV0+TQsfB7B13DKI+5Zf2uKYT/0n3MWljZ1SfCT7HI9lXW8KjCP1TVPee1 sIadrcYGwLQFvesI4Dtb83nd+SHWEYH+or35EOtDVfW0EqjalZWF8JgF+SBdA5cPh5 5N4dcUu/bOKbw== From: Thadeu Lima de Souza Cascardo To: kernel-team@lists.ubuntu.com Subject: [SRU Bionic 1/2] drm/vgem: Reclassify buffer creation debug message Date: Wed, 4 May 2022 19:48:49 -0300 Message-Id: <20220504224850.3702338-2-cascardo@canonical.com> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20220504224850.3702338-1-cascardo@canonical.com> References: <20220504224850.3702338-1-cascardo@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Chris Wilson A buffer is created in response to the user ioctl, it should therefore be a plain DRM_DEBUG() message to reflect it being a user invoked response and not a driver construct. This is just to make the commonplace drm.debug=[26e] quieter when running with vgem. Signed-off-by: Chris Wilson Cc: Daniel Vetter Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190712120147.29830-1-chris@chris-wilson.co.uk (cherry picked from commit 913cafbb250f146654ea979186d8615e0c54d6a7) CVE-2022-1419 Signed-off-by: Thadeu Lima de Souza Cascardo --- drivers/gpu/drm/vgem/vgem_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c index 67037eb9a80e..8b9af2fad453 100644 --- a/drivers/gpu/drm/vgem/vgem_drv.c +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -215,7 +215,7 @@ static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, args->size = gem_object->size; args->pitch = pitch; - DRM_DEBUG_DRIVER("Created object of size %lld\n", size); + DRM_DEBUG("Created object of size %lld\n", size); return 0; } From patchwork Wed May 4 22:48:50 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thadeu Lima de Souza Cascardo X-Patchwork-Id: 1626652 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=X8gn97SQ; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4KtsVz6vYqz9sCq for ; Thu, 5 May 2022 08:50:51 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1nmNpX-0003oC-7w; Wed, 04 May 2022 22:50:47 +0000 Received: from smtp-relay-canonical-1.internal ([10.131.114.174] helo=smtp-relay-canonical-1.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1nmNpU-0003lw-J4 for kernel-team@lists.ubuntu.com; Wed, 04 May 2022 22:50:44 +0000 Received: from localhost.localdomain (1.general.cascardo.us.vpn [10.172.70.58]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-canonical-1.canonical.com (Postfix) with ESMTPSA id 80F6C3F130 for ; Wed, 4 May 2022 22:50:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1651704644; bh=uvL3Z2TxgLcitRLGp+mq3OQ8AXHSKCAwmGk64xSsIxo=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=X8gn97SQhzKkIJgfkltTJtLao08vFIpubxfk29aSyvErySxGXip1x8n20oR6Im+tX CykcwHS90sGDGrhW7AS4I/vxyZhwElP4lN2Nkrh/skgGg3tM6f3LSQz8+KvqIJXzZP UOiUm/fDfPyb5ph7bSA81JO5v295fpcmU6+Aj43r2PNas4R8331Jg0vgcitzkgv6GP JQMl9AwtlUlUc9Om7EmS515E2FFIo/vhIZpoGtlM5aEkVzLdlUYpUa0xpnKkIzdfcj 0iYVtLV4sFSjuT0SdmrjExAp8Ta+9NFyaWR/xX/jFiQTauUvVS8xDsbG+EBqdhOrPW gU1Q/oR6IsN4g== From: Thadeu Lima de Souza Cascardo To: kernel-team@lists.ubuntu.com Subject: [SRU Bionic 2/2] drm/vgem: Close use-after-free race in vgem_gem_create Date: Wed, 4 May 2022 19:48:50 -0300 Message-Id: <20220504224850.3702338-3-cascardo@canonical.com> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20220504224850.3702338-1-cascardo@canonical.com> References: <20220504224850.3702338-1-cascardo@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Daniel Vetter There's two references floating around here (for the object reference, not the handle_count reference, that's a different thing): - The temporary reference held by vgem_gem_create, acquired by creating the object and released by calling drm_gem_object_put_unlocked. - The reference held by the object handle, created by drm_gem_handle_create. This one generally outlives the function, except if a 2nd thread races with a GEM_CLOSE ioctl call. So usually everything is correct, except in that race case, where the access to gem_object->size could be looking at freed data already. Which again isn't a real problem (userspace shot its feet off already with the race, we could return garbage), but maybe someone can exploit this as an information leak. Cc: Dan Carpenter Cc: Hillf Danton Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Cc: Emil Velikov Cc: Daniel Vetter Cc: Sean Paul Cc: Chris Wilson Cc: Eric Anholt Cc: Sam Ravnborg Cc: Rob Clark Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200202132133.1891846-1-daniel.vetter@ffwll.ch (cherry picked from commit 4b848f20eda5974020f043ca14bacf7a7e634fc8) CVE-2022-1419 Signed-off-by: Thadeu Lima de Souza Cascardo --- drivers/gpu/drm/vgem/vgem_drv.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c index 8b9af2fad453..ad5bd47cf035 100644 --- a/drivers/gpu/drm/vgem/vgem_drv.c +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -190,9 +190,10 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, return ERR_CAST(obj); ret = drm_gem_handle_create(file, &obj->base, handle); - drm_gem_object_put_unlocked(&obj->base); - if (ret) + if (ret) { + drm_gem_object_put_unlocked(&obj->base); return ERR_PTR(ret); + } return &obj->base; } @@ -215,7 +216,9 @@ static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, args->size = gem_object->size; args->pitch = pitch; - DRM_DEBUG("Created object of size %lld\n", size); + drm_gem_object_put_unlocked(gem_object); + + DRM_DEBUG("Created object of size %llu\n", args->size); return 0; }