[PATCH] fbdev: da8xx-fb: add missing regulator_disable() in fb_probe
The error handling code in fb_probe misses regulator_disable if
regulator_enable is called successfully. The previous commit only
adds regulator_disable in the .remove(), forgetting the error
handling code in the .probe.
Fix this by adding a new error label to call regulator_disable.
Fixes: 611097d5daea("fbdev: da8xx: add support for a regulator")
Signed-off-by: Dongliang Mu
---
drivers/video/fbdev/da8xx-fb.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/da8xx-fb.c b/drivers/video/fbdev/da8xx-fb.c
index 11922b009ed7..cd07e401b326 100644
--- a/drivers/video/fbdev/da8xx-fb.c
+++ b/drivers/video/fbdev/da8xx-fb.c
@@ -1431,7 +1431,7 @@ static int fb_probe(struct platform_device *device)
dev_err(>dev,
"GLCD: kmalloc for frame buffer failed\n");
ret = -EINVAL;
- goto err_release_fb;
+ goto err_disable_reg;
}
da8xx_fb_info->screen_base = (char __iomem *) par->vram_virt;
@@ -1475,7 +1475,7 @@ static int fb_probe(struct platform_device *device)
ret = fb_alloc_cmap(_fb_info->cmap, PALETTE_SIZE, 0);
if (ret)
- goto err_release_fb;
+ goto err_disable_reg;
da8xx_fb_info->cmap.len = par->palette_sz;
/* initialize var_screeninfo */
@@ -1529,6 +1529,9 @@ static int fb_probe(struct platform_device *device)
err_dealloc_cmap:
fb_dealloc_cmap(_fb_info->cmap);
+err_disable_reg:
+ if (par->lcd_supply)
+ regulator_disable(par->lcd_supply);
err_release_fb:
framebuffer_release(da8xx_fb_info);
--
2.35.1
[PATCH] fbdev: smscufx: fix error handling code in ufx_usb_probe
The current error handling code in ufx_usb_probe have many unmatching
issues, e.g., missing ufx_free_usb_list, destroy_modedb label should
only include framebuffer_release, fb_dealloc_cmap only matches
fb_alloc_cmap.
My local syzkaller reports a memory leak bug:
memory leak in ufx_usb_probe
BUG: memory leak
unreferenced object 0x88802f879580 (size 128):
comm "kworker/0:7", pid 17416, jiffies 4295067474 (age 46.710s)
hex dump (first 32 bytes):
80 21 7c 2e 80 88 ff ff 18 d0 d0 0c 80 88 ff ff .!|.
00 d0 d0 0c 80 88 ff ff e0 ff ff ff 0f 00 00 00
backtrace:
[] kmalloc_trace+0x20/0x90 mm/slab_common.c:1045
[] kmalloc include/linux/slab.h:553 [inline]
[] kzalloc include/linux/slab.h:689 [inline]
[] ufx_alloc_urb_list drivers/video/fbdev/smscufx.c:1873
[inline]
[] ufx_usb_probe+0x11c/0x15a0
drivers/video/fbdev/smscufx.c:1655
[] usb_probe_interface+0x177/0x370
drivers/usb/core/driver.c:396
[] call_driver_probe drivers/base/dd.c:560 [inline]
[] really_probe+0x12d/0x390 drivers/base/dd.c:639
[] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
[] driver_probe_device+0x2a/0x120 drivers/base/dd.c:808
[] __device_attach_driver+0xf7/0x150 drivers/base/dd.c:936
[] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
[] __device_attach+0x105/0x2d0 drivers/base/dd.c:1008
[] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
[] device_add+0x642/0xdc0 drivers/base/core.c:3517
[] usb_set_configuration+0x8ef/0xb80
drivers/usb/core/message.c:2170
[] usb_generic_driver_probe+0x8c/0xc0
drivers/usb/core/generic.c:238
[] usb_probe_device+0x5c/0x140
drivers/usb/core/driver.c:293
[] call_driver_probe drivers/base/dd.c:560 [inline]
[] really_probe+0x12d/0x390 drivers/base/dd.c:639
[] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
Fix this bug by rewriting the error handling code in ufx_usb_probe.
Reported-by: syzkaller
Tested-by: Dongliang Mu
Signed-off-by: Dongliang Mu
---
drivers/video/fbdev/smscufx.c | 46 +++
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
index 9343b7a4ac89..2ad6e98ce10d 100644
--- a/drivers/video/fbdev/smscufx.c
+++ b/drivers/video/fbdev/smscufx.c
@@ -1622,7 +1622,7 @@ static int ufx_usb_probe(struct usb_interface *interface,
struct usb_device *usbdev;
struct ufx_data *dev;
struct fb_info *info;
- int retval;
+ int retval = -ENOMEM;
u32 id_rev, fpga_rev;
/* usb initialization */
@@ -1654,15 +1654,17 @@ static int ufx_usb_probe(struct usb_interface
*interface,
if (!ufx_alloc_urb_list(dev, WRITES_IN_FLIGHT, MAX_TRANSFER)) {
dev_err(dev->gdev, "ufx_alloc_urb_list failed\n");
- goto e_nomem;
+ goto put_ref;
}
/* We don't register a new USB class. Our client interface is fbdev */
/* allocates framebuffer driver structure, not framebuffer memory */
info = framebuffer_alloc(0, >dev);
- if (!info)
- goto e_nomem;
+ if (!info) {
+ dev_err(dev->gdev, "framebuffer_alloc failed\n");
+ goto free_urb_list;
+ }
dev->info = info;
info->par = dev;
@@ -1705,22 +1707,34 @@ static int ufx_usb_probe(struct usb_interface
*interface,
check_warn_goto_error(retval, "unable to find common mode for display
and adapter");
retval = ufx_reg_set_bits(dev, 0x4000, 0x0001);
- check_warn_goto_error(retval, "error %d enabling graphics engine",
retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d enabling graphics engine", retval);
+ goto setup_modes;
+ }
/* ready to begin using device */
atomic_set(>usb_active, 1);
dev_dbg(dev->gdev, "checking var");
retval = ufx_ops_check_var(>var, info);
- check_warn_goto_error(retval, "error %d ufx_ops_check_var", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d ufx_ops_check_var", retval);
+ goto reset_active;
+ }
dev_dbg(dev->gdev, "setting par");
retval = ufx_ops_set_par(info);
- check_warn_goto_error(retval, "error %d ufx_ops_set_par", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d ufx_ops_set_par", retval);
+ goto reset_active;
+ }
dev_dbg(dev->gdev, "registering framebuffer");
retval = register_framebuffer(info);
- check_warn_goto_error(retval, "error %d register_framebuffer", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error
Re: [syzbot] general protection fault in virtio_gpu_array_put_free
On Sat, Dec 4, 2021 at 5:53 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:d58071a8a76d Linux 5.16-rc3
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=11f773f6b0
> kernel config: https://syzkaller.appspot.com/x/.config?x=171728a464c05f2b
> dashboard link: https://syzkaller.appspot.com/bug?extid=e9072e90624a31dfa85f
> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils
> for Debian) 2.35.2
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+e9072e90624a31dfa...@syzkaller.appspotmail.com
>
>
> general protection fault, probably for non-canonical address
> 0xdc0e: [#1] PREEMPT SMP KASAN
> KASAN: null-ptr-deref in range [0x0070-0x0077]
> CPU: 0 PID: 20114 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
> RIP: 0010:virtio_gpu_array_put_free+0x2f/0x190
> drivers/gpu/drm/virtio/virtgpu_gem.c:251
>From the description of stack trace, the bug resides in the missing
allocation of objs variable.
If fense is NULL, it will bypass the assignment of objs. And then in
the error handling of virtio_gpu_object_shmem_init, objs will be used
to dereference, leading to Null Pointer Dereference.
if (fence) {
ret = -ENOMEM;
objs = virtio_gpu_array_alloc(1); // if fence is NULL, this
assignment will be bypassed.
if (!objs)
goto err_put_id;
virtio_gpu_array_add_obj(objs, >base.base);
ret = virtio_gpu_array_lock_resv(objs);
if (ret != 0)
goto err_put_objs;
}
ret = virtio_gpu_object_shmem_init(vgdev, bo, , );
if (ret != 0) {
virtio_gpu_array_put_free(objs);
virtio_gpu_free_object(_obj->base);
return ret;
}
> Code: 55 49 89 fd 41 54 55 53 48 83 ec 08 e8 5a dd 09 fd 49 8d 45 70 48 89 c2
> 48 89 04 24 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <0f> b6 04 02 84 c0 74
> 08 3c 03 0f 8e 21 01 00 00 41 8b 5d 70 31 ff
> RSP: 0018:c90005a9fa90 EFLAGS: 00010202
> RAX: dc00 RBX: RCX: c900262ce000
> RDX: 000e RSI: 846cf6e6 RDI:
> RBP: 88801882b800 R08: R09: c90005a9f9ef
> R10: 846dcc29 R11: R12: c90005a9fbd0
> R13: R14: 888045f6 R15: fff4
> FS: 7f4ad9393700() GS:88802ca0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 7f561e680558 CR3: 50bde000 CR4: 00150ef0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0600
> Call Trace:
>
> virtio_gpu_object_create+0x5c7/0xd90
> drivers/gpu/drm/virtio/virtgpu_object.c:251
> virtio_gpu_gem_create drivers/gpu/drm/virtio/virtgpu_gem.c:42 [inline]
> virtio_gpu_mode_dumb_create+0x319/0x5c0
> drivers/gpu/drm/virtio/virtgpu_gem.c:90
> drm_mode_create_dumb+0x26c/0x2f0 drivers/gpu/drm/drm_dumb_buffers.c:96
> drm_ioctl_kernel+0x27d/0x4e0 drivers/gpu/drm/drm_ioctl.c:782
> drm_ioctl+0x51e/0x9d0 drivers/gpu/drm/drm_ioctl.c:885
> vfs_ioctl fs/ioctl.c:51 [inline]
> __do_sys_ioctl fs/ioctl.c:874 [inline]
> __se_sys_ioctl fs/ioctl.c:860 [inline]
> __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x44/0xae
> RIP: 0033:0x7f4adbe1dae9
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48
> 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73
> 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
> RSP: 002b:7f4ad9393188 EFLAGS: 0246 ORIG_RAX: 0010
> RAX: ffda RBX: 7f4adbf30f60 RCX: 7f4adbe1dae9
> RDX: 2040 RSI: c02064b2 RDI: 0003
> RBP: 7f4ad93931d0 R08: R09:
> R10: R11: 0246 R12: 0002
> R13: 7ffccb96db4f R14: 7f4ad9393300 R15: 00022000
>
> Modules linked in:
> ---[ end trace 8191b5e5ff4f69ef ]---
> RIP: 0010:virtio_gpu_array_put_free+0x2f/0x190
> drivers/gpu/drm/virtio/virtgpu_gem.c:251
> Code: 55 49 89 fd 41 54 55 53 48 83 ec 08 e8 5a dd 09 fd 49 8d 45 70 48 89 c2
> 48 89 04 24 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <0f> b6 04 02 84 c0 74
> 08 3c 03 0f 8e 21 01 00 00 41 8b 5d 70 31 ff
> RSP: 0018:c90005a9fa90 EFLAGS: 00010202
> RAX: dc00 RBX: RCX: c900262ce000
> RDX: 000e RSI: 846cf6e6 RDI:
> RBP: 88801882b800 R08: R09: c90005a9f9ef
> R10: 846dcc29 R11: R12: c90005a9fbd0
> R13: R14: 888045f6 R15: fff4
> FS:
Re: [PATCH 4.19] fbmem: add margin check to fb_check_caps()
On Fri, Sep 3, 2021 at 9:55 PM Greg KH wrote: > > On Thu, Sep 02, 2021 at 02:10:48PM +0800, Dongliang Mu wrote: > > [ Upstream commit a49145acfb975d921464b84fe00279f99827d816 ] > > > > A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting > > or yres setting in struct fb_var_screeninfo will result in a > > KASAN: vmalloc-out-of-bounds failure in bitfill_aligned() as > > the margins are being cleared. The margins are cleared in > > chunks and if the xres setting or yres setting is a value of > > zero upto the chunk size, the failure will occur. > > > > Add a margin check to validate xres and yres settings. > > > > Note that, this patch needs special handling to backport it to linux > > kernel 4.19, 4.14, 4.9, 4.4. > > Looks like this is already in the 4.4.283, 4.9.282, 4.14.246, and > 4.19.206 kernel releases. Can you check them to verify that it matches > your backport as well? Yes, I have seen them in these releases and they are fine to me. > > thanks, > > greg k-h
Re: [PATCH 4.19] fbmem: add margin check to fb_check_caps()
On Thu, Sep 2, 2021 at 9:15 PM Geert Uytterhoeven wrote:
>
> Hi Dongliang,
>
> On Thu, Sep 2, 2021 at 8:04 AM Dongliang Mu wrote:
> > [ Upstream commit a49145acfb975d921464b84fe00279f99827d816 ]
>
> Oops, looks like I missed when that one was submitted for review...
This patch cannot directly apply to old stable trees. Maybe that's the reason.
>
> > A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting
> > or yres setting in struct fb_var_screeninfo will result in a
> > KASAN: vmalloc-out-of-bounds failure in bitfill_aligned() as
> > the margins are being cleared. The margins are cleared in
> > chunks and if the xres setting or yres setting is a value of
> > zero upto the chunk size, the failure will occur.
> >
> > Add a margin check to validate xres and yres settings.
>
> Shouldn't (the caller of) bitfill_aligned() be fixed instead?
> Can this be triggered by e.g. using the mini_4x6 font?
I am sorry. I don't know much detail about this subsystem. I just
found syzkaller can still trigger this bug in linux-4.19.
Combined with the bug information, I found this patch is not merged
into the old kernel trees. So I send this patch rebased on linux-4.19.
Also I have tested it on linux-4.14 and below.
>
> > Note that, this patch needs special handling to backport it to linux
> > kernel 4.19, 4.14, 4.9, 4.4.
> >
> > Signed-off-by: George Kennedy
> > Reported-by: syzbot+e5fd3e65515b48c02...@syzkaller.appspotmail.com
> > Reviewed-by: Dan Carpenter
> > Cc: Dhaval Giani
> > Signed-off-by: Bartlomiej Zolnierkiewicz
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/1594149963-13801-1-git-send-email-george.kenn...@oracle.com
> > Signed-off-by: Sasha Levin
> > ---
> > drivers/video/fbdev/core/fbmem.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/video/fbdev/core/fbmem.c
> > b/drivers/video/fbdev/core/fbmem.c
> > index 84845275dbef..de04c097d67c 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -991,6 +991,10 @@ fb_set_var(struct fb_info *info, struct
> > fb_var_screeninfo *var)
> > goto done;
> > }
> >
> > + /* bitfill_aligned() assumes that it's at least 8x8 */
> > + if (var->xres < 8 || var->yres < 8)
> > + return -EINVAL;
>
> Are you sure there don't exist such small displays (e.g. OLED)?
>
> > +
> > ret = info->fbops->fb_check_var(var, info);
> >
> > if (ret)
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
[PATCH 4.19] fbmem: add margin check to fb_check_caps()
[ Upstream commit a49145acfb975d921464b84fe00279f99827d816 ] A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting or yres setting in struct fb_var_screeninfo will result in a KASAN: vmalloc-out-of-bounds failure in bitfill_aligned() as the margins are being cleared. The margins are cleared in chunks and if the xres setting or yres setting is a value of zero upto the chunk size, the failure will occur. Add a margin check to validate xres and yres settings. Note that, this patch needs special handling to backport it to linux kernel 4.19, 4.14, 4.9, 4.4. Signed-off-by: George Kennedy Reported-by: syzbot+e5fd3e65515b48c02...@syzkaller.appspotmail.com Reviewed-by: Dan Carpenter Cc: Dhaval Giani Signed-off-by: Bartlomiej Zolnierkiewicz Link: https://patchwork.freedesktop.org/patch/msgid/1594149963-13801-1-git-send-email-george.kenn...@oracle.com Signed-off-by: Sasha Levin --- drivers/video/fbdev/core/fbmem.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index 84845275dbef..de04c097d67c 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -991,6 +991,10 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var) goto done; } + /* bitfill_aligned() assumes that it's at least 8x8 */ + if (var->xres < 8 || var->yres < 8) + return -EINVAL; + ret = info->fbops->fb_check_var(var, info); if (ret) -- 2.25.1
[PATCH 4.19] fbmem: add margin check to fb_check_caps()
[ Upstream commit a49145acfb975d921464b84fe00279f99827d816 ] A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting or yres setting in struct fb_var_screeninfo will result in a KASAN: vmalloc-out-of-bounds failure in bitfill_aligned() as the margins are being cleared. The margins are cleared in chunks and if the xres setting or yres setting is a value of zero upto the chunk size, the failure will occur. Add a margin check to validate xres and yres settings. Note that, this patch needs special handling to backport it to linux kernel 4.19, 4.14, 4.9, 4.4. Signed-off-by: George Kennedy Reported-by: syzbot+e5fd3e65515b48c02...@syzkaller.appspotmail.com Reviewed-by: Dan Carpenter Cc: Dhaval Giani Signed-off-by: Bartlomiej Zolnierkiewicz Link: https://patchwork.freedesktop.org/patch/msgid/1594149963-13801-1-git-send-email-george.kenn...@oracle.com Signed-off-by: Sasha Levin --- drivers/video/fbdev/core/fbmem.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index 84845275dbef..de04c097d67c 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -991,6 +991,10 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var) goto done; } + /* bitfill_aligned() assumes that it's at least 8x8 */ + if (var->xres < 8 || var->yres < 8) + return -EINVAL; + ret = info->fbops->fb_check_var(var, info); if (ret) -- 2.25.1
Re: [PATCH 4.19] fbmem: add margin check to fb_check_caps()
On Thu, Sep 2, 2021 at 2:02 PM Dongliang Mu wrote: > > [ Upstream commit a49145acfb975d921464b84fe00279f99827d816 ] > > A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting > or yres setting in struct fb_var_screeninfo will result in a > KASAN: vmalloc-out-of-bounds failure in bitfill_aligned() as > the margins are being cleared. The margins are cleared in > chunks and if the xres setting or yres setting is a value of > zero upto the chunk size, the failure will occur. > > Add a margin check to validate xres and yres settings. > > Note that, this patch needs special handling to backport it to linux > kernel 4.19, 4.14, 4.9, 4.4. I have tested that, this patch can be applied to the branches: linux-4.19.y/linux-4.14.y/linux-4.9.y/linux-4.4.y. > > Signed-off-by: George Kennedy > Reported-by: syzbot+e5fd3e65515b48c02...@syzkaller.appspotmail.com > Reviewed-by: Dan Carpenter > Cc: Dhaval Giani > Signed-off-by: Bartlomiej Zolnierkiewicz > Link: > https://patchwork.freedesktop.org/patch/msgid/1594149963-13801-1-git-send-email-george.kenn...@oracle.com > Signed-off-by: Sasha Levin > --- > drivers/video/fbdev/core/fbmem.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/video/fbdev/core/fbmem.c > b/drivers/video/fbdev/core/fbmem.c > index 84845275dbef..de04c097d67c 100644 > --- a/drivers/video/fbdev/core/fbmem.c > +++ b/drivers/video/fbdev/core/fbmem.c > @@ -991,6 +991,10 @@ fb_set_var(struct fb_info *info, struct > fb_var_screeninfo *var) > goto done; > } > > + /* bitfill_aligned() assumes that it's at least 8x8 */ > + if (var->xres < 8 || var->yres < 8) > + return -EINVAL; > + > ret = info->fbops->fb_check_var(var, info); > > if (ret) > -- > 2.25.1 >
