memory leak in video_usercopy

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: a409ed15 Merge tag 'gpio-v5.11-1' of git://git.kernel.org/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10a5880f500000
kernel config: https://syzkaller.appspot.com/x/.config?x=37c889fb8b2761af
dashboard link: https://syzkaller.appspot.com/bug?extid=1115e79c8df6472c612b
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14d18f9b500000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=106a2c13500000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1115e7...@syzkaller.appspotmail.com

Debian GNU/Linux 9 syzkaller ttyS0
Warning: Permanently added '10.128.10.29' (ECDSA) to the list of known hosts.
executing program
executing program
BUG: memory leak
unreferenced object 0xffff88810fb12300 (size 256):
comm "syz-executor399", pid 8472, jiffies 4294942333 (age 13.960s)
hex dump (first 32 bytes):
03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000009fd00995>] kmalloc_node include/linux/slab.h:575 [inline]
[<000000009fd00995>] kvmalloc_node+0x61/0xf0 mm/util.c:575
[<0000000096a57c4a>] kvmalloc include/linux/mm.h:773 [inline]
[<0000000096a57c4a>] video_usercopy+0x991/0xa50 drivers/media/v4l2-core/v4l2-ioctl.c:3303
[<00000000f7529cc2>] v4l2_ioctl+0x77/0x90 drivers/media/v4l2-core/v4l2-dev.c:360
[<0000000061b5e6a9>] vfs_ioctl fs/ioctl.c:48 [inline]
[<0000000061b5e6a9>] __do_sys_ioctl fs/ioctl.c:753 [inline]
[<0000000061b5e6a9>] __se_sys_ioctl fs/ioctl.c:739 [inline]
[<0000000061b5e6a9>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:739
[<000000000139479b>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
[<00000000d6de1c9c>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

BUG: memory leak
unreferenced object 0xffff88810f934300 (size 256):
comm "syz-executor399", pid 8473, jiffies 4294942927 (age 8.030s)
hex dump (first 32 bytes):
03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000009fd00995>] kmalloc_node include/linux/slab.h:575 [inline]
[<000000009fd00995>] kvmalloc_node+0x61/0xf0 mm/util.c:575
[<0000000096a57c4a>] kvmalloc include/linux/mm.h:773 [inline]
[<0000000096a57c4a>] video_usercopy+0x991/0xa50 drivers/media/v4l2-core/v4l2-ioctl.c:3303
[<00000000f7529cc2>] v4l2_ioctl+0x77/0x90 drivers/media/v4l2-core/v4l2-dev.c:360
[<0000000061b5e6a9>] vfs_ioctl fs/ioctl.c:48 [inline]
[<0000000061b5e6a9>] __do_sys_ioctl fs/ioctl.c:753 [inline]
[<0000000061b5e6a9>] __se_sys_ioctl fs/ioctl.c:739 [inline]
[<0000000061b5e6a9>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:739
[<000000000139479b>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
[<00000000d6de1c9c>] entry_SYSCALL_64_after_hwframe+0x44/0xa9



---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

[Arnd Bergmann]

,On Sat, Dec 19, 2020 at 2:15 PM syzbot

It seems there are commands that need both a buffer for the direct ioc
argument and for array_args. If that happens, we have two kvmalloc() calls
but only one kvfree(), and that would correctly trigger the leak detector.

The direct ioc argument copy happens for arguments over 128 bytes.
Checking the sizes of the comands with array args shows

VIDIOC_PREPARE_BUF, VIDIOC_QUERYBUF, VIDIOC_QBUF, VIDIOC_DQBUF:
v4l2_buffer, 84 bytes or less

VIDIOC_G_EDID, VIDIOC_S_EDID:
v4l2_edid, 40 bytes or less

VIDIOC_G_EXT_CTRLS, VIDIOC_S_EXT_CTRLS, VIDIOC_TRY_EXT_CTRLS:
v4l2_ext_controls, 32 bytes or less

VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_TRY_FMT:
v4l2_format, 204 or 208 bytes

I would conclude it's one of the last three commands, and it could be
avoided either by increasing the on-stack buffer to sizeof(struct v4l2_format),
or by restructuring this function again to have two separate pointers
for alloc/free.

Arnd

[Sakari Ailus]

Hi Arnd,

Thanks for reporting this.

I'd say the original approach was risky to begin with, and that risk
effectively materialised here. I'd rather fix the risky construction than
leaving it there.

Considering the format IOCTLs have been unchanged (size-wise) all this
time, it looks like it really has been broken for a few days short of a
decade! sbuf has been 128 bytes all this time.

--
Kind regards,

Sakari Ailus