[v2] video: imsttfb: Fix use after free bug in imsttfb_probe due to lack of error-handling of init_imstt
Message ID | 20230427030841.2384157-1-zyytlz.wz@163.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp3041vqo; Wed, 26 Apr 2023 20:24:20 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4KpsKZCpslWMR4FmkQOgrESy0yZcDYZuswb81EvoGu+wiOP+yoO6X1GTNEm1Z9CwOh0zwj X-Received: by 2002:a17:90a:17a2:b0:249:8963:c6b with SMTP id q31-20020a17090a17a200b0024989630c6bmr433283pja.18.1682565860425; Wed, 26 Apr 2023 20:24:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682565860; cv=none; d=google.com; s=arc-20160816; b=T967GyJsjbVzzeO+c6FYBd1cF2FOrmUH4vex1X3G7R1nWk1HAsIOy1iPOXD88PhNsk 6FwC3AEDGxA/YSqpFrbgAk4OggsfxqpQOvkbuU8kVy//L0jCEmbR7jbEH0hnaIUQBiGw //S35InXFwUWvuLKmmbN1/QC78DjnV9F97knkGVRD48pXL5lx9C6UQrNGYsDJDwFjVZx ZhEdpg29hz3bEkHb4WjC6GnBTHcPXtSztWtELO24ZBfKpn/348VSjjLlPrTrobZLHy8r vLfK4UUmNi7VuGq0LRdhenohEGQ9ihHoExVXAhpnHN81giHD8B0Bs3UBog1dHaAYQjHj W2AQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=aJJrvyTyo8hE6ICK1Lxk50jXuG4KqTFF4VfxF35PEdo=; b=umrhyaJFqPTvRv6EpRh3944zoMJ/tmmZns7i7xivYa3b1c3YAcQ1BHOEp8Xy1bY3zL 61t3SBkgqMEPzhr72BS9kd/C0YUcMU6Zm6+Uesdgkb8ZLQ62HO/3jiphIRB/GVrHIGNM KVWsU9brVbNDWGdBrxxrEmhdcc7eTzmqArYYdmIRBY1h/Wzk6PAu1BW0snIfh6pkoJhY w6RaeOiFheNvDwanWsMuBkZcJz5hh8uxcUzWcU5LfYAzNVMWR74lripmGLNiQ+CERyKO L/16CUm1ouF0QafaCFBOPkWbnAIA8PdkjyI0E8+HGLYOKkZ0Iqlp6Yh/mQG/X8OtxRjf IWYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@163.com header.s=s110527 header.b=BKEP3oc6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=163.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l6-20020a17090ab70600b00235dc16de3asi19766396pjr.16.2023.04.26.20.24.07; Wed, 26 Apr 2023 20:24:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@163.com header.s=s110527 header.b=BKEP3oc6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=163.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242718AbjD0DJJ (ORCPT <rfc822;zxc52fgh@gmail.com> + 99 others); Wed, 26 Apr 2023 23:09:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242755AbjD0DJG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 26 Apr 2023 23:09:06 -0400 Received: from m12.mail.163.com (m12.mail.163.com [220.181.12.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 018F21BC9; Wed, 26 Apr 2023 20:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-Id:MIME-Version; bh=aJJrv yTyo8hE6ICK1Lxk50jXuG4KqTFF4VfxF35PEdo=; b=BKEP3oc6YdFydmWaXWXc0 yGtJWWiLg8SAh7R/jClOrjeYA2r4LPlwlwpSnxfUc9iAdkdLfa7XVSGLyMtwQniW 4cOWj25t1y9XAmqYnHwc7v98vpuns2Gl2dyjka+WNGw2JwAiSNBDrTCFcSbEp6Yq JZ8rf2Qlsurgo++GH+4oVw= Received: from leanderwang-LC2.localdomain (unknown [111.206.145.21]) by zwqz-smtp-mta-g5-4 (Coremail) with SMTP id _____wD3uKQ650lkHEztAA--.58828S2; Thu, 27 Apr 2023 11:08:42 +0800 (CST) From: Zheng Wang <zyytlz.wz@163.com> To: deller@gmx.de Cc: javierm@redhat.com, tzimmermann@suse.de, linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, hackerzheng666@gmail.com, 1395428693sheep@gmail.com, alex000young@gmail.com, Zheng Wang <zyytlz.wz@163.com> Subject: [PATCH v2] video: imsttfb: Fix use after free bug in imsttfb_probe due to lack of error-handling of init_imstt Date: Thu, 27 Apr 2023 11:08:41 +0800 Message-Id: <20230427030841.2384157-1-zyytlz.wz@163.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: _____wD3uKQ650lkHEztAA--.58828S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7KFWxKr18uF1kur4rGw4xCrg_yoW8tw47pF 45A3Z8JrsrJF48Ww4kJF4UAF43KFn7t34agrW7Ka4SyF13CrW0gr1xGa42vr93JrZ7Jr17 ZF4kt34UCF1UuFDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0ziIzuAUUUUU= X-Originating-IP: [111.206.145.21] X-CM-SenderInfo: h2113zf2oz6qqrwthudrp/xtbBzhteU2I0Y-4VnQAAsb X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764297058478999713?= X-GMAIL-MSGID: =?utf-8?q?1764298179628309545?= |
Series |
[v2] video: imsttfb: Fix use after free bug in imsttfb_probe due to lack of error-handling of init_imstt
|
|
Commit Message
Zheng Wang
April 27, 2023, 3:08 a.m. UTC
A use-after-free bug may occur if init_imstt invokes framebuffer_release
and free the info ptr. The caller, imsttfb_probe didn't notice that and
still keep the ptr as private data in pdev.
If we remove the driver which will call imsttfb_remove to make cleanup,
UAF happens.
Fix it by return error code if bad case happens in init_imstt.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
---
v2:
- add return error code in another location.
---
drivers/video/fbdev/imsttfb.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
Comments
On 4/27/23 05:08, Zheng Wang wrote: > A use-after-free bug may occur if init_imstt invokes framebuffer_release > and free the info ptr. The caller, imsttfb_probe didn't notice that and > still keep the ptr as private data in pdev. > > If we remove the driver which will call imsttfb_remove to make cleanup, > UAF happens. > > Fix it by return error code if bad case happens in init_imstt. > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Signed-off-by: Zheng Wang <zyytlz.wz@163.com> applied. Thanks! Helge > --- > v2: > - add return error code in another location. > --- > drivers/video/fbdev/imsttfb.c | 15 ++++++++------- > 1 file changed, 8 insertions(+), 7 deletions(-) > > diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c > index bea45647184e..975dd682fae4 100644 > --- a/drivers/video/fbdev/imsttfb.c > +++ b/drivers/video/fbdev/imsttfb.c > @@ -1347,7 +1347,7 @@ static const struct fb_ops imsttfb_ops = { > .fb_ioctl = imsttfb_ioctl, > }; > > -static void init_imstt(struct fb_info *info) > +static int init_imstt(struct fb_info *info) > { > struct imstt_par *par = info->par; > __u32 i, tmp, *ip, *end; > @@ -1420,7 +1420,7 @@ static void init_imstt(struct fb_info *info) > || !(compute_imstt_regvals(par, info->var.xres, info->var.yres))) { > printk("imsttfb: %ux%ux%u not supported\n", info->var.xres, info->var.yres, info->var.bits_per_pixel); > framebuffer_release(info); > - return; > + return -ENODEV; > } > > sprintf(info->fix.id, "IMS TT (%s)", par->ramdac == IBM ? "IBM" : "TVP"); > @@ -1456,12 +1456,13 @@ static void init_imstt(struct fb_info *info) > > if (register_framebuffer(info) < 0) { > framebuffer_release(info); > - return; > + return -ENODEV; > } > > tmp = (read_reg_le32(par->dc_regs, SSTATUS) & 0x0f00) >> 8; > fb_info(info, "%s frame buffer; %uMB vram; chip version %u\n", > info->fix.id, info->fix.smem_len >> 20, tmp); > + return 0; > } > > static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent) > @@ -1529,10 +1530,10 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent) > if (!par->cmap_regs) > goto error; > info->pseudo_palette = par->palette; > - init_imstt(info); > - > - pci_set_drvdata(pdev, info); > - return 0; > + ret = init_imstt(info); > + if (!ret) > + pci_set_drvdata(pdev, info); > + return ret; > > error: > if (par->dc_regs)
Hello. On Thu, Apr 27, 2023 at 11:08:41AM +0800, Zheng Wang <zyytlz.wz@163.com> wrote: > static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent) > @@ -1529,10 +1530,10 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent) > if (!par->cmap_regs) > goto error; > info->pseudo_palette = par->palette; > - init_imstt(info); > - > - pci_set_drvdata(pdev, info); > - return 0; > + ret = init_imstt(info); > + if (!ret) > + pci_set_drvdata(pdev, info); > + return ret; > > error: > if (par->dc_regs) This part caught my eye -- shouldn't the -ENODEV from init_imstt go through the standard error with proper cleanup? (It seems like a leak from my 30000 ft view, i.e. not sure about imsttfb_{probe,remove} pairing.) Shouldn't there be something like the diff below on top of the existing code? Regards, Michal diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c index 975dd682fae4..a116ac8ca020 100644 --- a/drivers/video/fbdev/imsttfb.c +++ b/drivers/video/fbdev/imsttfb.c @@ -1419,7 +1419,6 @@ static int init_imstt(struct fb_info *info) if ((info->var.xres * info->var.yres) * (info->var.bits_per_pixel >> 3) > info->fix.smem_len || !(compute_imstt_regvals(par, info->var.xres, info->var.yres))) { printk("imsttfb: %ux%ux%u not supported\n", info->var.xres, info->var.yres, info->var.bits_per_pixel); - framebuffer_release(info); return -ENODEV; } @@ -1455,7 +1454,6 @@ static int init_imstt(struct fb_info *info) fb_alloc_cmap(&info->cmap, 0, 0); if (register_framebuffer(info) < 0) { - framebuffer_release(info); return -ENODEV; } @@ -1531,8 +1529,10 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent) goto error; info->pseudo_palette = par->palette; ret = init_imstt(info); - if (!ret) - pci_set_drvdata(pdev, info); + if (ret) + goto error; + + pci_set_drvdata(pdev, info); return ret; error:
Hi Michal, On 5/22/23 17:36, Michal Koutný wrote: > On Thu, Apr 27, 2023 at 11:08:41AM +0800, Zheng Wang <zyytlz.wz@163.com> wrote: >> static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent) >> @@ -1529,10 +1530,10 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent) >> if (!par->cmap_regs) >> goto error; >> info->pseudo_palette = par->palette; >> - init_imstt(info); >> - >> - pci_set_drvdata(pdev, info); >> - return 0; >> + ret = init_imstt(info); >> + if (!ret) >> + pci_set_drvdata(pdev, info); >> + return ret; >> >> error: >> if (par->dc_regs) > > This part caught my eye -- shouldn't the -ENODEV from init_imstt go > through the standard error with proper cleanup? (It seems like a leak > from my 30000 ft view, i.e. not sure about imsttfb_{probe,remove} > pairing.) Yes, you seem to be right. > Shouldn't there be something like the diff below on top of the existing code? Yes, but .... > Regards, > Michal > > diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c > index 975dd682fae4..a116ac8ca020 100644 > --- a/drivers/video/fbdev/imsttfb.c > +++ b/drivers/video/fbdev/imsttfb.c > @@ -1419,7 +1419,6 @@ static int init_imstt(struct fb_info *info) > if ((info->var.xres * info->var.yres) * (info->var.bits_per_pixel >> 3) > info->fix.smem_len > || !(compute_imstt_regvals(par, info->var.xres, info->var.yres))) { > printk("imsttfb: %ux%ux%u not supported\n", info->var.xres, info->var.yres, info->var.bits_per_pixel); > - framebuffer_release(info); > return -ENODEV; > } > > @@ -1455,7 +1454,6 @@ static int init_imstt(struct fb_info *info) > fb_alloc_cmap(&info->cmap, 0, 0); > > if (register_framebuffer(info) < 0) { > - framebuffer_release(info); That's ^^^ ok, but I think a fb_dealloc_cmap() is missing here ... ... and in the error path of imsttfb_probe() .... > return -ENODEV; > } > > @@ -1531,8 +1529,10 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent) > goto error; > info->pseudo_palette = par->palette; > ret = init_imstt(info); > - if (!ret) > - pci_set_drvdata(pdev, info); > + if (ret) > + goto error; > + > + pci_set_drvdata(pdev, info); > return ret; > > error: Would you mind sending a proper patch? Thanks for noticing! Helge
On 5/23/23 19:42, Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 23 May 2023 18:30:26 +0200 > > The value “-ENOMEM” was assigned to the variable “ret” > at the beginning. > Move this statement directly before the first ioremap() call. Please do not move such variables without real need. It makes backporting (of this and maybe follow-up patches) much more complicated and the compiler will optimize it anyway. Thanks! Helge > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/video/fbdev/imsttfb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c > index 6490f544f8eb..90c72428e8d7 100644 > --- a/drivers/video/fbdev/imsttfb.c > +++ b/drivers/video/fbdev/imsttfb.c > @@ -1484,7 +1484,6 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent) > ret = aperture_remove_conflicting_pci_devices(pdev, "imsttfb"); > if (ret) > return ret; > - ret = -ENOMEM; > > dp = pci_device_to_OF_node(pdev); > if(dp) > @@ -1525,6 +1524,7 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent) > } > > info->fix.smem_start = addr; > + ret = -ENOMEM; > info->screen_base = (__u8 *)ioremap(addr, par->ramdac == IBM ? > 0x400000 : 0x800000); > if (!info->screen_base) > -- > 2.40.1 >
On 5/23/23 19:38, Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 23 May 2023 14:32:39 +0200 > > The return value was overlooked from a call of > the function “fb_alloc_cmap”. > > * Thus use a corresponding error check. > > * Add two jump targets so that a bit of exception handling > can be better reused at the end of this function. > > > Reported-by: Helge Deller <deller@gmx.de> > Link: https://lore.kernel.org/dri-devel/069f2f78-01f3-9476-d860-2b695c122649@gmx.de/ > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Fixes: c75f5a550610 ("fbdev: imsttfb: Fix use after free bug in imsttfb_probe") > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/video/fbdev/imsttfb.c | 18 +++++++++++++----- > 1 file changed, 13 insertions(+), 5 deletions(-) > > diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c > index 975dd682fae4..d3532def4707 100644 > --- a/drivers/video/fbdev/imsttfb.c > +++ b/drivers/video/fbdev/imsttfb.c > @@ -1351,6 +1351,7 @@ static int init_imstt(struct fb_info *info) > { > struct imstt_par *par = info->par; > __u32 i, tmp, *ip, *end; > + int ret; > > tmp = read_reg_le32(par->dc_regs, PRC); > if (par->ramdac == IBM) > @@ -1419,8 +1420,7 @@ static int init_imstt(struct fb_info *info) > if ((info->var.xres * info->var.yres) * (info->var.bits_per_pixel >> 3) > info->fix.smem_len > || !(compute_imstt_regvals(par, info->var.xres, info->var.yres))) { > printk("imsttfb: %ux%ux%u not supported\n", info->var.xres, info->var.yres, info->var.bits_per_pixel); > - framebuffer_release(info); > - return -ENODEV; > + goto e_nodev; > } > > sprintf(info->fix.id, "IMS TT (%s)", par->ramdac == IBM ? "IBM" : "TVP"); > @@ -1452,17 +1452,25 @@ static int init_imstt(struct fb_info *info) > FBINFO_HWACCEL_FILLRECT | > FBINFO_HWACCEL_YPAN; > > - fb_alloc_cmap(&info->cmap, 0, 0); > + ret = fb_alloc_cmap(&info->cmap, 0, 0); > + if (ret) > + goto release_framebuffer; > > if (register_framebuffer(info) < 0) { > - framebuffer_release(info); > - return -ENODEV; > + fb_dealloc_cmap(&info->cmap); > + goto e_nodev; > } > > tmp = (read_reg_le32(par->dc_regs, SSTATUS) & 0x0f00) >> 8; > fb_info(info, "%s frame buffer; %uMB vram; chip version %u\n", > info->fix.id, info->fix.smem_len >> 20, tmp); > return 0; > + > +e_nodev: > + ret = -ENODEV; I think the return value isn't checked at all, so you could simply return below "-ENODEV" for all cases (instead of "return ret"). Then you don't need the e_nodev label and can simplify the flow. Helge > +release_framebuffer: > + framebuffer_release(info); > + return ret; > } > > static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent) > -- > 2.40.1 >
On 5/25/23 07:33, Markus Elfring wrote: >>> The return value was overlooked from a call of >>> the function “fb_alloc_cmap”. >>> >>> * Thus use a corresponding error check. >>> >>> * Add two jump targets so that a bit of exception handling >>> can be better reused at the end of this function. > … >>> +++ b/drivers/video/fbdev/imsttfb.c > … >>> @@ -1452,17 +1452,25 @@ static int init_imstt(struct fb_info *info) >>> FBINFO_HWACCEL_FILLRECT | >>> FBINFO_HWACCEL_YPAN; >>> >>> - fb_alloc_cmap(&info->cmap, 0, 0); >>> + ret = fb_alloc_cmap(&info->cmap, 0, 0); >>> + if (ret) >>> + goto release_framebuffer; >>> >>> if (register_framebuffer(info) < 0) { >>> - framebuffer_release(info); >>> - return -ENODEV; >>> + fb_dealloc_cmap(&info->cmap); >>> + goto e_nodev; >>> } >>> >>> tmp = (read_reg_le32(par->dc_regs, SSTATUS) & 0x0f00) >> 8; >>> fb_info(info, "%s frame buffer; %uMB vram; chip version %u\n", >>> info->fix.id, info->fix.smem_len >> 20, tmp); >>> return 0; >>> + >>> +e_nodev: >>> + ret = -ENODEV; >> >> I think the return value isn't checked at all, so you could >> simply return below "-ENODEV" for all cases (instead of "return ret"). >> Then you don't need the e_nodev label and can simplify the flow. > > Can it be helpful to distinguish involved error codes better? No. Helge
diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c index bea45647184e..975dd682fae4 100644 --- a/drivers/video/fbdev/imsttfb.c +++ b/drivers/video/fbdev/imsttfb.c @@ -1347,7 +1347,7 @@ static const struct fb_ops imsttfb_ops = { .fb_ioctl = imsttfb_ioctl, }; -static void init_imstt(struct fb_info *info) +static int init_imstt(struct fb_info *info) { struct imstt_par *par = info->par; __u32 i, tmp, *ip, *end; @@ -1420,7 +1420,7 @@ static void init_imstt(struct fb_info *info) || !(compute_imstt_regvals(par, info->var.xres, info->var.yres))) { printk("imsttfb: %ux%ux%u not supported\n", info->var.xres, info->var.yres, info->var.bits_per_pixel); framebuffer_release(info); - return; + return -ENODEV; } sprintf(info->fix.id, "IMS TT (%s)", par->ramdac == IBM ? "IBM" : "TVP"); @@ -1456,12 +1456,13 @@ static void init_imstt(struct fb_info *info) if (register_framebuffer(info) < 0) { framebuffer_release(info); - return; + return -ENODEV; } tmp = (read_reg_le32(par->dc_regs, SSTATUS) & 0x0f00) >> 8; fb_info(info, "%s frame buffer; %uMB vram; chip version %u\n", info->fix.id, info->fix.smem_len >> 20, tmp); + return 0; } static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent) @@ -1529,10 +1530,10 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (!par->cmap_regs) goto error; info->pseudo_palette = par->palette; - init_imstt(info); - - pci_set_drvdata(pdev, info); - return 0; + ret = init_imstt(info); + if (!ret) + pci_set_drvdata(pdev, info); + return ret; error: if (par->dc_regs)