From nobody Fri May 8 09:59:00 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BEBAAC433EF for ; Thu, 5 May 2022 22:04:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1386140AbiEEWIS (ORCPT ); Thu, 5 May 2022 18:08:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54648 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237116AbiEEWIQ (ORCPT ); Thu, 5 May 2022 18:08:16 -0400 Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [170.10.129.74]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 00EDD1EEF0 for ; Thu, 5 May 2022 15:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651788274; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ncwUrPXa6D//xAE+gUKX4W9jlEJvsWNrctcaxVQSCb8=; b=PweeKV1NXVpyIKwskeT5YWzMaOC8hxCWX50B+RJhVgasW4M/7b+YGOgtPuiB5iEyMrZMwE u/eKyb8rJxxRo83/ZqQ2JBqwy+JwSm+opIyQoZJFx4Ad4b1A6ndjELKCAgmnoPkfcNP9/i BkgkF24AE8ikHmSrWu7Rp+Lwao7EvC8= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-215-2g0Sq597PYuiA62tgGDZhA-1; Thu, 05 May 2022 18:04:25 -0400 X-MC-Unique: 2g0Sq597PYuiA62tgGDZhA-1 Received: by mail-wr1-f71.google.com with SMTP id s14-20020adfa28e000000b0020ac7532f08so1872384wra.15 for ; Thu, 05 May 2022 15:04:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ncwUrPXa6D//xAE+gUKX4W9jlEJvsWNrctcaxVQSCb8=; b=X7IKakNfuemgSg7A1tR+HChKeEnWTxcXVbnFIWG/rbURC1lwmLql8U3z0Ovj/1kAGe JPX7nq9wpBpnn4B2OL7LDBCzPIcEraAnLtVJouvvwlDXt/YIidhQmKuSQdqVMbPoxr4n e8cqtn51Ukao88VwUUdqzsqgxSFKsJWUAt/EenSgadYp48ZuA6Tu0QfOtuMFcslcaavv wDyyrjmFA/OggqBEtFy8r470scErsmgwyUN8MtakIdi+J7GayLC9FW4nbpiszaIak0IH 09TP8JWostrrtbj4pCmp+drOC4OoKi6SmmXZxxMsroI9P6fNCKRqJ+S0QCKsQ1sPaDwV msGA== X-Gm-Message-State: AOAM530Cn8icTu7pTtC57hJfmBMu+43pPvXIJkjKCFa5o1pNlUsHpNK8 waQZudw/h4PQyNO0Dlszcz/MnRNaPVgYmfmsRHwT6F0AhxAwdjNpf7ksteDai/3lH3WRSPQZh/3 k4lBCSPHpcW3AJYkL8NBAF73h+CKPOn6wM/HUF+qHCxT9K/Y1nYP+KXNB1bVEMjDxGmtZlDBMxY Y= X-Received: by 2002:a05:600c:3d8c:b0:394:6097:9994 with SMTP id bi12-20020a05600c3d8c00b0039460979994mr6726669wmb.29.1651788264100; Thu, 05 May 2022 15:04:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyfwhAOIQeVF2O3srNOg8rIqNBWMADJBM0ucjW4JDKss+KaRrP/Oe0Hd/iuu0biw9+SXEcE9g== X-Received: by 2002:a05:600c:3d8c:b0:394:6097:9994 with SMTP id bi12-20020a05600c3d8c00b0039460979994mr6726643wmb.29.1651788263758; Thu, 05 May 2022 15:04:23 -0700 (PDT) Received: from minerva.home (205.pool92-176-231.dynamic.orange.es. [92.176.231.205]) by smtp.gmail.com with ESMTPSA id m21-20020a05600c3b1500b003942a244f4bsm7980875wms.36.2022.05.05.15.04.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 May 2022 15:04:23 -0700 (PDT) From: Javier Martinez Canillas To: linux-kernel@vger.kernel.org Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, Daniel Vetter , Helge Deller , Daniel Vetter , Javier Martinez Canillas , Thomas Zimmermann Subject: [PATCH v3 1/4] fbdev: Prevent possible use-after-free in fb_release() Date: Fri, 6 May 2022 00:04:13 +0200 Message-Id: <20220505220413.365977-1-javierm@redhat.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220505215947.364694-1-javierm@redhat.com> References: <20220505215947.364694-1-javierm@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Daniel Vetter Most fbdev drivers have issues with the fb_info lifetime, because call to framebuffer_release() from their driver's .remove callback, rather than doing from fbops.fb_destroy callback. Doing that will destroy the fb_info too early, while references to it may still exist, leading to a use-after-free error. To prevent this, check the fb_info reference counter when attempting to kfree the data structure in framebuffer_release(). That will leak it but at least will prevent the mentioned error. Signed-off-by: Daniel Vetter Signed-off-by: Javier Martinez Canillas Reviewed-by: Thomas Zimmermann Reported-by: Andrzej Hajda --- (no changes since v1) drivers/video/fbdev/core/fbsysfs.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/= fbsysfs.c index 8c1ee9ecec3d..c2a60b187467 100644 --- a/drivers/video/fbdev/core/fbsysfs.c +++ b/drivers/video/fbdev/core/fbsysfs.c @@ -80,6 +80,10 @@ void framebuffer_release(struct fb_info *info) { if (!info) return; + + if (WARN_ON(refcount_read(&info->count))) + return; + kfree(info->apertures); kfree(info); } --=20 2.35.1 From nobody Fri May 8 09:59:00 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8AFD3C433FE for ; Thu, 5 May 2022 22:05:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1386154AbiEEWJH (ORCPT ); Thu, 5 May 2022 18:09:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355319AbiEEWIt (ORCPT ); Thu, 5 May 2022 18:08:49 -0400 Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [170.10.129.74]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 25E445DD38 for ; Thu, 5 May 2022 15:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651788308; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CpySyazXcP9jeQEo03DKJEoNJ7MOw25wdUGi6hnO0cY=; b=Tv5Cn2NQWTmW/dIbpECPwyLPLHqHjROL43HRs6dwHygl2YsVs4kCbOo3jrzFrr4C/v7LWn VYi6wxz4ZGygO0FQIiv+pqH6G5rZuEso829J7Pp8CSFCXO81eMEVPPa8mSUz9Zf8WfoOX1 1TvURTOn1MvV+U+PuF6i/AIGoW8QDYU= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-595-Usafqd9PMU6cvV_cGXZ7Ww-1; Thu, 05 May 2022 18:05:07 -0400 X-MC-Unique: Usafqd9PMU6cvV_cGXZ7Ww-1 Received: by mail-wm1-f70.google.com with SMTP id p24-20020a1c5458000000b003945d2ffc6eso2211789wmi.5 for ; Thu, 05 May 2022 15:05:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=CpySyazXcP9jeQEo03DKJEoNJ7MOw25wdUGi6hnO0cY=; b=f7+nEtbMYOrYS/fSujUYZfHfyfrScqIBff/agLAPBfXVLFb6I+rRie8s2LtNOiwgH3 nntFdCXNRLmLf6XenA/0usLZpdePWqogLbxgav7scYrxDXXgaIo9A22YZC3Gaavb1hNW vc625BQhcaWAHSxBsINvtvwO06KsNtROVLFm1Ynu4b5EzP4dSoicBTBYcC1oxj6WZKUL hFkMmekHiN6Mr0Chlndt2DlXUCk3xRuW31A2VWlk90bCkqWOEed77cktS0rdRxXJa4HN 1Z0menSN+IiFOY8NW3Nsm3ZF5tcZMi9aoO6ZQ1rWPY8Uyf16d0CXjfPA8EVlnxBaAIlK SM2A== X-Gm-Message-State: AOAM533POi3Mim/rsp7sRqNVyeKrpIOqadD4bEz9iyS6Td09/1tMN00/ FZ8ALc5VkWVi2F4WnKTz7bBl5eCwHzmQE6RPKZCZNaq3/lsf5Czcfut7iKTKcfkuWahSYm7gsZ/ moRpI/XBMJYOZLRMmxN+jd0ptwfwjhP67CFaEb8DOYAXXWgX6pId2Z+I6tUT/4iNk96gyDrdkuh s= X-Received: by 2002:a5d:6c65:0:b0:20c:5230:f145 with SMTP id r5-20020a5d6c65000000b0020c5230f145mr142615wrz.337.1651788305826; Thu, 05 May 2022 15:05:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzx4hSKJf5+8gqVXy4SQIIH/+d18yIIzPchwfl0/SeHroDdEocZasvgfA/q6M9W6ITqVZA+Yg== X-Received: by 2002:a5d:6c65:0:b0:20c:5230:f145 with SMTP id r5-20020a5d6c65000000b0020c5230f145mr142590wrz.337.1651788305549; Thu, 05 May 2022 15:05:05 -0700 (PDT) Received: from minerva.home (205.pool92-176-231.dynamic.orange.es. [92.176.231.205]) by smtp.gmail.com with ESMTPSA id n21-20020a7bc5d5000000b003942a244f47sm7942360wmk.32.2022.05.05.15.05.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 May 2022 15:05:05 -0700 (PDT) From: Javier Martinez Canillas To: linux-kernel@vger.kernel.org Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, Daniel Vetter , Helge Deller , Hans de Goede , Javier Martinez Canillas , Thomas Zimmermann Subject: [PATCH v3 2/4] fbdev: simplefb: Cleanup fb_info in .fb_destroy rather than .remove Date: Fri, 6 May 2022 00:04:56 +0200 Message-Id: <20220505220456.366090-1-javierm@redhat.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220505215947.364694-1-javierm@redhat.com> References: <20220505215947.364694-1-javierm@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" The driver is calling framebuffer_release() in its .remove callback, but this will cause the struct fb_info to be freed too early. Since it could be that a reference is still hold to it if user-space opened the fbdev. This would lead to a use-after-free error if the framebuffer device was unregistered but later a user-space process tries to close the fbdev fd. To prevent this, move the framebuffer_release() call to fb_ops.fb_destroy instead of doing it in the driver's .remove callback. Strictly speaking, the code flow in the driver is still wrong because all the hardware cleanupd (i.e: iounmap) should be done in .remove while the software cleanup (i.e: releasing the framebuffer) should be done in the .fb_destroy handler. But this at least makes to match the behavior before commit 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced remov= al"). Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced remov= al") Suggested-by: Daniel Vetter Signed-off-by: Javier Martinez Canillas Reviewed-by: Thomas Zimmermann Reviewed-by: Daniel Vetter --- (no changes since v1) drivers/video/fbdev/simplefb.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c index 94fc9c6d0411..2c198561c338 100644 --- a/drivers/video/fbdev/simplefb.c +++ b/drivers/video/fbdev/simplefb.c @@ -84,6 +84,10 @@ struct simplefb_par { static void simplefb_clocks_destroy(struct simplefb_par *par); static void simplefb_regulators_destroy(struct simplefb_par *par); =20 +/* + * fb_ops.fb_destroy is called by the last put_fb_info() call at the end + * of unregister_framebuffer() or fb_release(). Do any cleanup here. + */ static void simplefb_destroy(struct fb_info *info) { struct simplefb_par *par =3D info->par; @@ -94,6 +98,8 @@ static void simplefb_destroy(struct fb_info *info) if (info->screen_base) iounmap(info->screen_base); =20 + framebuffer_release(info); + if (mem) release_mem_region(mem->start, resource_size(mem)); } @@ -545,8 +551,8 @@ static int simplefb_remove(struct platform_device *pdev) { struct fb_info *info =3D platform_get_drvdata(pdev); =20 + /* simplefb_destroy takes care of info cleanup */ unregister_framebuffer(info); - framebuffer_release(info); =20 return 0; } --=20 2.35.1 From nobody Fri May 8 09:59:00 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EE6D9C433F5 for ; Thu, 5 May 2022 22:06:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1386156AbiEEWJo (ORCPT ); Thu, 5 May 2022 18:09:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236520AbiEEWJj (ORCPT ); Thu, 5 May 2022 18:09:39 -0400 Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [170.10.133.74]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 638FD5DD38 for ; Thu, 5 May 2022 15:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651788357; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XOMIAnnTamSRotiOWkLRdWbDfwtm7Vtf7J5gIUBLvsY=; b=Ba1xRvzB9SAXzBEcc7v3Ut+zYDe2RBV33jCalF3XsLrAW3XtcdZVtzzLVzO7fa7eCxeiPu GI2paM6ysQt+cMJODb8LtFpA7WFU5P8Vt+6q1Cri7LPfax4uoXseBdTO2eo6EUnhd27qxl od8dfrpQ2gvCHswWY5g2/W6t/ZaPtoU= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-664-naRzLUubPlSJKy_MnNkwOg-1; Thu, 05 May 2022 18:05:56 -0400 X-MC-Unique: naRzLUubPlSJKy_MnNkwOg-1 Received: by mail-wr1-f71.google.com with SMTP id k29-20020adfb35d000000b0020adc94662dso1867431wrd.12 for ; Thu, 05 May 2022 15:05:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=XOMIAnnTamSRotiOWkLRdWbDfwtm7Vtf7J5gIUBLvsY=; b=x+fs1NMwaAV2QMHOYf8HbG7ltf2EWaLWA78nag66doHOl5aKrtX2YVxIoXxfzgSnez V9EZqabN0qXeU1eHQ/W/m8hSEh+WBu5r6997S3iUu5hxmcBKZiwnh+jaASpNg2sf5Uhd HzECxF/n2xo66UBX2jKsTdSjzPshux+mFQgIRKX9E3LGM8PMdkSDR9foOEniXWzLDPaT RZANL26j50AxI/Zh+lKxA2U+FOteAtw5j/QJRgRhgkvq4DCQDs9jojGArV1OuPLC64BF mn/XtyY8izrfy1/NNRbhfyZK4hl52du1FeAnyHVZNmbrPZ7C1w1voIy0MFuV09wPzXmc PgEQ== X-Gm-Message-State: AOAM533p1zIqCSrRHAL3oJMRU2HzgCFeiapWOT4EMVA35N0uJ1wuqtiU tcM3YoS06jbcckItM+cT6QHb7Qi448jLH+9uMrD+RC5/MaIPznt6VVJ2sDUZGvnI8iLmHZUaUex OiVQzgSyQiPP2EOgLeIAW3rjzrpf30VDGRFEfHGaWxjKSpbfx+FFlq50Qktxbipf1P6yNJH+hG1 s= X-Received: by 2002:a05:600c:214c:b0:394:2dfe:2754 with SMTP id v12-20020a05600c214c00b003942dfe2754mr287451wml.135.1651788355019; Thu, 05 May 2022 15:05:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxeda1HHZwr4FX+lwN/TaIHgdOKHms0BlDVvSG/oTgRzg2lXGiKrE9u+GvlU9S+3hDsIgrQvw== X-Received: by 2002:a05:600c:214c:b0:394:2dfe:2754 with SMTP id v12-20020a05600c214c00b003942dfe2754mr287430wml.135.1651788354747; Thu, 05 May 2022 15:05:54 -0700 (PDT) Received: from minerva.home (205.pool92-176-231.dynamic.orange.es. [92.176.231.205]) by smtp.gmail.com with ESMTPSA id j28-20020a05600c1c1c00b003942a244f39sm7291679wms.18.2022.05.05.15.05.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 May 2022 15:05:54 -0700 (PDT) From: Javier Martinez Canillas To: linux-kernel@vger.kernel.org Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, Daniel Vetter , Helge Deller , Peter Jones , Javier Martinez Canillas , Thomas Zimmermann Subject: [PATCH v3 3/4] fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove Date: Fri, 6 May 2022 00:05:40 +0200 Message-Id: <20220505220540.366218-1-javierm@redhat.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220505215947.364694-1-javierm@redhat.com> References: <20220505215947.364694-1-javierm@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" The driver is calling framebuffer_release() in its .remove callback, but this will cause the struct fb_info to be freed too early. Since it could be that a reference is still hold to it if user-space opened the fbdev. This would lead to a use-after-free error if the framebuffer device was unregistered but later a user-space process tries to close the fbdev fd. To prevent this, move the framebuffer_release() call to fb_ops.fb_destroy instead of doing it in the driver's .remove callback. Strictly speaking, the code flow in the driver is still wrong because all the hardware cleanupd (i.e: iounmap) should be done in .remove while the software cleanup (i.e: releasing the framebuffer) should be done in the .fb_destroy handler. But this at least makes to match the behavior before commit 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced remov= al"). Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced remov= al") Suggested-by: Daniel Vetter Signed-off-by: Javier Martinez Canillas Reviewed-by: Thomas Zimmermann Reviewed-by: Daniel Vetter Reported-by: kernel test robot --- (no changes since v1) drivers/video/fbdev/efifb.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c index ea42ba6445b2..cfa3dc0b4eee 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/video/fbdev/efifb.c @@ -243,6 +243,10 @@ static void efifb_show_boot_graphics(struct fb_info *i= nfo) static inline void efifb_show_boot_graphics(struct fb_info *info) {} #endif =20 +/* + * fb_ops.fb_destroy is called by the last put_fb_info() call at the end + * of unregister_framebuffer() or fb_release(). Do any cleanup here. + */ static void efifb_destroy(struct fb_info *info) { if (efifb_pci_dev) @@ -254,6 +258,9 @@ static void efifb_destroy(struct fb_info *info) else memunmap(info->screen_base); } + + framebuffer_release(info); + if (request_mem_succeeded) release_mem_region(info->apertures->ranges[0].base, info->apertures->ranges[0].size); @@ -620,9 +627,9 @@ static int efifb_remove(struct platform_device *pdev) { struct fb_info *info =3D platform_get_drvdata(pdev); =20 + /* efifb_destroy takes care of info cleanup */ unregister_framebuffer(info); sysfs_remove_groups(&pdev->dev.kobj, efifb_groups); - framebuffer_release(info); =20 return 0; } --=20 2.35.1 From nobody Fri May 8 09:59:00 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3988CC433EF for ; Thu, 5 May 2022 22:06:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1386183AbiEEWKU (ORCPT ); Thu, 5 May 2022 18:10:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1386177AbiEEWKS (ORCPT ); Thu, 5 May 2022 18:10:18 -0400 Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [170.10.129.74]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 25E855EDDA for ; Thu, 5 May 2022 15:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651788396; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2QUs/dFpZjXD63m2oUdzjI7+Wpnx04uqjBRSmxR+fJo=; b=NoeVH+LQnxYMLYYVXHGRCy7OFetIWVi5u+7Pk5FBOHyKKEMSgREgymlEgh3EV5WBMV/IZK 14DKGnoqDCy80qvLrNJyR6w6p05KtLDMZMfmi8Kp7WCNuTRyjXogw+BhgFQKGeqYGr9/FG XegBqSEp0bm6RVZ4+Vinv6Aoi4AgJrc= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-639-IOYryVw9Nh6yPaHpBI4weg-1; Thu, 05 May 2022 18:06:35 -0400 X-MC-Unique: IOYryVw9Nh6yPaHpBI4weg-1 Received: by mail-wr1-f72.google.com with SMTP id s14-20020adfa28e000000b0020ac7532f08so1874160wra.15 for ; Thu, 05 May 2022 15:06:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=2QUs/dFpZjXD63m2oUdzjI7+Wpnx04uqjBRSmxR+fJo=; b=29P5oF84PWp0Z/EOyqbffA7rHLgnPZzNqyas9FjoSyi57U478h/BFTrwuAqGAh3eq/ T/futsReB6d6EBYrnD4CiH9dYc2hO6qBtq5EsqxDWXBmz2Ox9JZjm7Btb31DbvY3IcBI PFG8K3PmglOiWd/IHY6OKQU2eppea0SWar1F9TV4HjwYzcdohO1+59Xix5VK/VJ5buX/ L5y9Y1hOawZ3edDIy20ylnDDvvjMnFanHvqeuLlPsQ+ac3TPCAehJ3pf0eG0/uuFmmBV PttT9MrX9aEpe0PEl6aKCawY0GCgrJjWBYYALiTUHmWowDicPFYweejbNLaOjU2UGddl wv0w== X-Gm-Message-State: AOAM531kM0GFGkZFrlPkkAGPRMxrNoCjHSj15mrsPZSoeeFbQ7gYS7Cd MgoN22IasmrHaO4eiQursNYRi6p9cBwxO+11odaTQpZsQtGWcKPzPMy795ZAVz/Fw8RZm4aK0h8 CX14GgpMOjkhnCXaj1/BpiydWwf80647HU66YQsQvYAOTBgZSqd4g7w0ppSIJrFcSI2h2VnU9Mc 4= X-Received: by 2002:a5d:6dd1:0:b0:207:92c4:eaef with SMTP id d17-20020a5d6dd1000000b0020792c4eaefmr165085wrz.498.1651788393706; Thu, 05 May 2022 15:06:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwJuZtwlqObinYznGZMuIaaeVki7i2UMoMVMO9mJCvQ2FsqRQYwPdVCdFx20Il32JBmnuIcGA== X-Received: by 2002:a5d:6dd1:0:b0:207:92c4:eaef with SMTP id d17-20020a5d6dd1000000b0020792c4eaefmr165062wrz.498.1651788393466; Thu, 05 May 2022 15:06:33 -0700 (PDT) Received: from minerva.home (205.pool92-176-231.dynamic.orange.es. [92.176.231.205]) by smtp.gmail.com with ESMTPSA id n11-20020a056000170b00b0020c5253d8c7sm2040236wrc.19.2022.05.05.15.06.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 May 2022 15:06:33 -0700 (PDT) From: Javier Martinez Canillas To: linux-kernel@vger.kernel.org Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, Daniel Vetter , Helge Deller , Hans de Goede , Javier Martinez Canillas , Thomas Zimmermann Subject: [PATCH v3 4/4] fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than .remove Date: Fri, 6 May 2022 00:06:31 +0200 Message-Id: <20220505220631.366371-1-javierm@redhat.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220505215947.364694-1-javierm@redhat.com> References: <20220505215947.364694-1-javierm@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" The driver is calling framebuffer_release() in its .remove callback, but this will cause the struct fb_info to be freed too early. Since it could be that a reference is still hold to it if user-space opened the fbdev. This would lead to a use-after-free error if the framebuffer device was unregistered but later a user-space process tries to close the fbdev fd. To prevent this, move the framebuffer_release() call to fb_ops.fb_destroy instead of doing it in the driver's .remove callback. Strictly speaking, the code flow in the driver is still wrong because all the hardware cleanupd (i.e: iounmap) should be done in .remove while the software cleanup (i.e: releasing the framebuffer) should be done in the .fb_destroy handler. But this at least makes to match the behavior before commit 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced remov= al"). Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced remov= al") Suggested-by: Daniel Vetter Signed-off-by: Javier Martinez Canillas Reviewed-by: Thomas Zimmermann Reviewed-by: Daniel Vetter --- Changes in v3: - Only move framebuffer_release() and don't do any other change (Daniel Vetter). Changes in v2: - Also do the change for vesafb (Thomas Zimmermann). drivers/video/fbdev/vesafb.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c index df6de5a9dd4c..e25e8de5ff67 100644 --- a/drivers/video/fbdev/vesafb.c +++ b/drivers/video/fbdev/vesafb.c @@ -179,6 +179,10 @@ static int vesafb_setcolreg(unsigned regno, unsigned r= ed, unsigned green, return err; } =20 +/* + * fb_ops.fb_destroy is called by the last put_fb_info() call at the end + * of unregister_framebuffer() or fb_release(). Do any cleanup here. + */ static void vesafb_destroy(struct fb_info *info) { struct vesafb_par *par =3D info->par; @@ -188,6 +192,8 @@ static void vesafb_destroy(struct fb_info *info) if (info->screen_base) iounmap(info->screen_base); release_mem_region(info->apertures->ranges[0].base, info->apertures->rang= es[0].size); + + framebuffer_release(info); } =20 static struct fb_ops vesafb_ops =3D { @@ -484,10 +490,10 @@ static int vesafb_remove(struct platform_device *pdev) { struct fb_info *info =3D platform_get_drvdata(pdev); =20 + /* vesafb_destroy takes care of info cleanup */ unregister_framebuffer(info); if (((struct vesafb_par *)(info->par))->region) release_region(0x3c0, 32); - framebuffer_release(info); =20 return 0; } --=20 2.35.1