user/sven/linux.git, branch v5.12.18

Linux 5.12.18

2021-07-19T08:01:28Z

Link: https://lore.kernel.org/r/20210715182551.731989182@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20210716182137.994236340@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Tested-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman

f2fs: fix to avoid racing on fsync_entry_slab by multi filesystem instances

2021-07-19T08:01:28Z

commit cad83c968c2ebe97905f900326988ed37146c347 upstream. As syzbot reported, there is an use-after-free issue during f2fs recovery: Use-after-free write at 0xffff88823bc16040 (in kfence-#10): kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486 f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869 f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945 mount_bdev+0x26c/0x3a0 fs/super.c:1367 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x86/0x270 fs/super.c:1497 do_new_mount fs/namespace.c:2905 [inline] path_mount+0x196f/0x2be0 fs/namespace.c:3235 do_mount fs/namespace.c:3248 [inline] __do_sys_mount fs/namespace.c:3456 [inline] __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433 do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae The root cause is multi f2fs filesystem instances can race on accessing global fsync_entry_slab pointer, result in use-after-free issue of slab cache, fixes to init/destroy this slab cache only once during module init/destroy procedure to avoid this issue. Reported-by: syzbot+9d90dad32dd9727ed084@syzkaller.appspotmail.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman

ext4: fix memory leak in ext4_fill_super

2021-07-19T08:01:28Z

commit 618f003199c6188e01472b03cdbba227f1dc5f24 upstream. static int kthread(void *_create) will return -ENOMEM or -EINTR in case of internal failure or kthread_stop() call happens before threadfn call. To prevent fancy error checking and make code more straightforward we moved all cleanup code out of kmmpd threadfn. Also, dropped struct mmpd_data at all. Now struct super_block is a threadfn data and struct buffer_head embedded into struct ext4_sb_info. Reported-by: syzbot+d9e482e303930fa4f6ff@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Link: https://lore.kernel.org/r/20210430185046.15742-1-paskripkin@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman

smackfs: restrict bytes count in smk_set_cipso()

2021-07-19T08:01:28Z

commit 49ec114a6e62d8d320037ce71c1aaf9650b3cafd upstream. Oops, I failed to update subject line. From 07571157c91b98ce1a4aa70967531e64b78e8346 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Mon, 12 Apr 2021 22:25:06 +0900 Subject: smackfs: restrict bytes count in smk_set_cipso() Commit 7ef4c19d245f3dc2 ("smackfs: restrict bytes count in smackfs write functions") missed that count > SMK_CIPSOMAX check applies to only format == SMK_FIXED24_FMT case. Reported-by: syzbot Signed-off-by: Tetsuo Handa Signed-off-by: Casey Schaufler Signed-off-by: Greg Kroah-Hartman

media: v4l2-core: explicitly clear ioctl input data

2021-07-19T08:01:27Z

commit 7b53cca764f9b291b7907fcd39d9e66ad728ee0b upstream. As seen from a recent syzbot bug report, mistakes in the compat ioctl implementation can lead to uninitialized kernel stack data getting used as input for driver ioctl handlers. The reported bug is now fixed, but it's possible that other related bugs are still present or get added in the future. As the drivers need to check user input already, the possible impact is fairly low, but it might still cause an information leak. To be on the safe side, always clear the entire ioctl buffer before calling the conversion handler functions that are meant to initialize them. Signed-off-by: Arnd Bergmann Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

jfs: fix GPF in diFree

2021-07-19T08:01:27Z

commit 9d574f985fe33efd6911f4d752de6f485a1ea732 upstream. Avoid passing inode with JFS_SBI(inode->i_sb)->ipimap == NULL to diFree()[1]. GFP will appear: struct inode *ipimap = JFS_SBI(ip->i_sb)->ipimap; struct inomap *imap = JFS_IP(ipimap)->i_imap; JFS_IP() will return invalid pointer when ipimap == NULL Call Trace: diFree+0x13d/0x2dc0 fs/jfs/jfs_imap.c:853 [1] jfs_evict_inode+0x2c9/0x370 fs/jfs/inode.c:154 evict+0x2ed/0x750 fs/inode.c:578 iput_final fs/inode.c:1654 [inline] iput.part.0+0x3fe/0x820 fs/inode.c:1680 iput+0x58/0x70 fs/inode.c:1670 Reported-and-tested-by: syzbot+0a89a7b56db04c21a656@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Signed-off-by: Dave Kleikamp Signed-off-by: Greg Kroah-Hartman

drm/ast: Remove reference to struct drm_device.pdev

2021-07-19T08:01:27Z

commit 0ecb51824e838372e01330752503ddf9c0430ef7 upstream. Using struct drm_device.pdev is deprecated. Upcast with to_pci_dev() from struct drm_device.dev to get the PCI device structure. v9: * fix remaining pdev references Signed-off-by: Thomas Zimmermann Reviewed-by: Michael J. Ruhl Fixes: ba4e0339a6a3 ("drm/ast: Fixed CVE for DP501") Cc: KuoHsiang Chou Cc: kernel test robot Cc: Thomas Zimmermann Cc: Dave Airlie Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20210429105101.25667-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman

pinctrl: mcp23s08: Fix missing unlock on error in mcp23s08_irq()

2021-07-19T08:01:27Z

commit 884af72c90016cfccd5717439c86b48702cbf184 upstream. Add the missing unlock before return from function mcp23s08_irq() in the error handling case. v1-->v2: remove the "return IRQ_HANDLED" line Fixes: 897120d41e7a ("pinctrl: mcp23s08: fix race condition in irq handler") Reported-by: Hulk Robot Signed-off-by: Zou Wei Link: https://lore.kernel.org/r/1623134048-56051-1-git-send-email-zou_wei@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

dm writecache: write at least 4k when committing

2021-07-19T08:01:27Z

commit 867de40c4c23e6d7f89f9ce4272a5d1b1484c122 upstream. SSDs perform badly with sub-4k writes (because they perfrorm read-modify-write internally), so make sure writecache writes at least 4k when committing. Fixes: 991bd8d7bc78 ("dm writecache: commit just one block, not a full page") Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman

media: uvcvideo: Fix pixel format change for Elgato Cam Link 4K

2021-07-19T08:01:27Z

commit 4c6e0976295add7f0ed94d276c04a3d6f1ea8f83 upstream. The Elgato Cam Link 4K HDMI video capture card reports to support three different pixel formats, where the first format depends on the connected HDMI device. ``` $ v4l2-ctl -d /dev/video0 --list-formats-ext ioctl: VIDIOC_ENUM_FMT Type: Video Capture [0]: 'NV12' (Y/CbCr 4:2:0) Size: Discrete 3840x2160 Interval: Discrete 0.033s (29.970 fps) [1]: 'NV12' (Y/CbCr 4:2:0) Size: Discrete 3840x2160 Interval: Discrete 0.033s (29.970 fps) [2]: 'YU12' (Planar YUV 4:2:0) Size: Discrete 3840x2160 Interval: Discrete 0.033s (29.970 fps) ``` Changing the pixel format to anything besides the first pixel format does not work: ``` $ v4l2-ctl -d /dev/video0 --try-fmt-video pixelformat=YU12 Format Video Capture: Width/Height : 3840/2160 Pixel Format : 'NV12' (Y/CbCr 4:2:0) Field : None Bytes per Line : 3840 Size Image : 12441600 Colorspace : sRGB Transfer Function : Rec. 709 YCbCr/HSV Encoding: Rec. 709 Quantization : Default (maps to Limited Range) Flags : ``` User space applications like VLC might show an error message on the terminal in that case: ``` libv4l2: error set_fmt gave us a different result than try_fmt! ``` Depending on the error handling of the user space applications, they might display a distorted video, because they use the wrong pixel format for decoding the stream. The Elgato Cam Link 4K responds to the USB video probe VS_PROBE_CONTROL/VS_COMMIT_CONTROL with a malformed data structure: The second byte contains bFormatIndex (instead of being the second byte of bmHint). The first byte is always zero. The third byte is always 1. The firmware bug was reported to Elgato on 2020-12-01 and it was forwarded by the support team to the developers as feature request. There is no firmware update available since then. The latest firmware for Elgato Cam Link 4K as of 2021-03-23 has MCU 20.02.19 and FPGA 67. Therefore correct the malformed data structure for this device. The change was successfully tested with VLC, OBS, and Chromium using different pixel formats (YUYV, NV12, YU12), resolutions (3840x2160, 1920x1080), and frame rates (29.970 and 59.940 fps). Cc: stable@vger.kernel.org Signed-off-by: Benjamin Drung Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman