[PATCH next v2] dma-buf/sync-file: do not allow zero size allocation

out early if it is equal to 0 Fixes: 519f490db07e ("dma-buf/sync-file: fix warning about fence containers") Signed-off-by: Pavel Skripkin --- Changes since v1: - Dropped already merged part - Removed syzkaller's tag --- drivers/dma-buf/sync_file.c | 2 +- 1

Re: [Linaro-mm-sig] [PATCH next] dma-buf/sync-file: do not allow zero size allocations

Hi Christian, On 3/30/22 10:09, Christian König wrote: That problem is already fixed with patch 21d139d73f77 dma-buf/sync-file: fix logic error in new fence merge code. Am 30.03.22 um 00:14 schrieb Pavel Skripkin: syzbot reported GPF in dma_fence_array_first(), which is caused by

[PATCH next] dma-buf/sync-file: do not allow zero size allocations

yzbot+5c943fe38e86d615c...@syzkaller.appspotmail.com Fixes: 519f490db07e ("dma-buf/sync-file: fix warning about fence containers") Signed-off-by: Pavel Skripkin --- drivers/dma-buf/sync_file.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/sync_file.c b/

Re: [syzbot] general protection fault in dma_fence_array_first

On 3/30/22 00:23, syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:8515d05bf6bc Add linux-next specific files for 20220328 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1694e21b70 kernel config: https://syzkaller.appspot.com/x

[PATCH] fbdev: udlfb: properly check endpoint type

s/usb/core/driver.c:396 Fixes: 88e58b1a42f8 ("Staging: add udlfb driver") Reported-and-tested-by: syzbot+53ce4a4246d0fe0fe...@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin --- drivers/video/fbdev/udlfb.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-

Re: [syzbot] WARNING in component_del

ps://lore.kernel.org/linux-usb/20220208170048.24718-1-fmdefrance...@gmail.com/ With regards, Pavel Skripkin

Re: [syzbot] WARNING in component_del

nent_add(), but usb_hub_create_port_device() just prints warn message in case of component_add() failure (see log (*)) And then calling component_del() on non-added item causes WARN_ON() Can't prove my thoughts, since there is no repro :( With regards, Pavel Skripkin

Re: [PATCH] udmabuf: validate ubuf->pagecount

On 12/30/21 17:26, Pavel Skripkin wrote: Syzbot has reported GPF in sg_alloc_append_table_from_pages(). The problem was in ubuf->pages == ZERO_PTR. ubuf->pagecount is calculated from arguments passed from user-space. If user creates udmabuf with list.size == 0 then ubuf->pagecount wil

[PATCH] udmabuf: validate ubuf->pagecount

rray() to return ZERO_PTR. Fix it by validating ubuf->pagecount before passing it to kmalloc_array(). Fixes: fbb0de795078 ("Add udmabuf misc device") Reported-and-tested-by: syzbot+2c56b725ec547fa9c...@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin --- Happy New Ye

Re: [syzbot] general protection fault in sg_alloc_append_table_from_pages

On 10/13/21 19:51, syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:717478d89fe2 Merge tag 'riscv-for-linus-5.15-rc5' of git:/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=12489abf30 kernel config: https://syzkaller.appspot.c

Re: [syzbot] general protection fault in udmabuf_create

l 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 With regards, Pavel Skripkin

[PATCH v2] gpu: ttm: add missing NULL checks

tm/ttm_bo.c:1050 ttm_bo_init+0x105/0x270 drivers/gpu/drm/ttm/ttm_bo.c:1074 drm_gem_vram_create+0x332/0x4c0 drivers/gpu/drm/drm_gem_vram_helper.c:228 Fixes: d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer") Signed-off-by: Pavel Skripkin --- Changes in v2: 1. A

Re: [PATCH] gpu: ttm: fix GPF in ttm_bo_release

On Thu, 8 Jul 2021 12:56:19 +0200 Christian König wrote: > Am 08.07.21 um 12:09 schrieb Pavel Skripkin: > > On Thu, 8 Jul 2021 11:37:01 +0300 > > Pavel Skripkin wrote: > > > >> On Thu, 8 Jul 2021 08:49:48 +0200 > >> Christian König wrote: > >> &

Re: [PATCH] gpu: ttm: fix GPF in ttm_bo_release

On Thu, 8 Jul 2021 11:37:01 +0300 Pavel Skripkin wrote: > On Thu, 8 Jul 2021 08:49:48 +0200 > Christian König wrote: > > > Am 07.07.21 um 20:51 schrieb Pavel Skripkin: > > > My local syzbot instance hit GPF in ttm_bo_release(). > > > Unfortunately, syzbot did

[PATCH] gpu: ttm: fix GPF in ttm_bo_release

m: rename bo->mem and make it a pointer") Signed-off-by: Pavel Skripkin --- drivers/gpu/drm/ttm/ttm_bo.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 1b950b45cf4b..15eb97459eab 100644 --- a/drivers/gpu/drm/

[PATCH] OMAP: DSS2: OMAPFB: fix potential GPF

ncing random pointers in kfree(). Fix it by rewriting error handling path. Fixes: 897044e99e43 ("OMAP: DSS2: OMAPFB: Reduce stack usage") Signed-off-by: Pavel Skripkin --- .../video/fbdev/omap2/omapfb/omapfb-main.c| 21 +-- 1 file changed, 10 insertions(+), 11 deletions(-

Re: [PATCH] OMAP: DSS2: OMAPFB: fix potential GPF

On Sun, 27 Jun 2021 02:14:23 +0300 Aaro Koskinen wrote: > Hi, > > On Sat, Jun 26, 2021 at 01:33:23AM +0300, Pavel Skripkin wrote: > > In case of allocation failures, all code paths was jumping > > to this code: > > > > err: > > kfree(fbi);