- 19 Nov, 2021 16 commits
-
-
Zheyu Ma authored
A out-of-bounds bug can be triggered by an interrupt, the reason for this bug is the lack of checking of register values. In flexcop_pci_isr, the driver reads value from a register and uses it as a dma address. Finally, this address will be passed to the count parameter of find_next_packet. If this value is larger than the size of dma, the index of buffer will be out-of-bounds. Fix this by adding a check after reading the value of the register. The following KASAN report reveals it: BUG: KASAN: slab-out-of-bounds in find_next_packet drivers/media/dvb-core/dvb_demux.c:528 [inline] BUG: KASAN: slab-out-of-bounds in _dvb_dmx_swfilter drivers/media/dvb-core/dvb_demux.c:572 [inline] BUG: KASAN: slab-out-of-bounds in dvb_dmx_swfilter+0x3fa/0x420 drivers/media/dvb-core/dvb_demux.c:603 Read of size 1 at addr ffff8880608c00a0 by task swapper/2/0 CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xec/0x156 lib/dump_stack.c:118 print_address_description+0x78/0x290 mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report+0x25b/0x380 mm/kasan/report.c:412 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:430 find_next_packet drivers/media/dvb-core/dvb_demux.c:528 [inline] _dvb_dmx_swfilter drivers/media/dvb-core/dvb_demux.c:572 [inline] dvb_dmx_swfilter+0x3fa/0x420 drivers/media/dvb-core/dvb_demux.c:603 flexcop_pass_dmx_data+0x2e/0x40 drivers/media/common/b2c2/flexcop.c:167 flexcop_pci_isr+0x3d1/0x5d0 drivers/media/pci/b2c2/flexcop-pci.c:212 __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149 handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189 handle_irq_event+0xac/0x140 kernel/irq/handle.c:206 handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725 generic_handle_irq_desc include/linux/irqdesc.h:155 [inline] handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87 do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247 common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670 </IRQ> RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61 Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 62 2f 8c 48 89 e5 e8 fb 31 e8 f8 8b 05 75 4f 8e 03 85 c0 7e 07 0f 00 2d 8a 61 66 00 fb f4 <5d> c3 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde RAX: 0000000000000000 RBX: ffffffff8bde44c8 RCX: ffffffff88a11285 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2f6200 RBP: ffff88806b71fcc8 R08: fffffbfff185ec40 R09: fffffbfff185ec40 R10: 0000000000000001 R11: fffffbfff185ec40 R12: 0000000000000002 R13: ffffffff8be9d6e0 R14: 0000000000000000 R15: 0000000000000000 arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] default_idle+0x6f/0x360 arch/x86/kernel/process.c:557 arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548 default_idle_call+0x3b/0x60 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [inline] do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369 start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243 Allocated by task 1: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x11/0x20 mm/kasan/kasan.c:490 slab_post_alloc_hook mm/slab.h:445 [inline] slab_alloc_node mm/slub.c:2741 [inline] slab_alloc mm/slub.c:2749 [inline] kmem_cache_alloc+0xeb/0x280 mm/slub.c:2754 kmem_cache_zalloc include/linux/slab.h:699 [inline] __kernfs_new_node+0xe2/0x6f0 fs/kernfs/dir.c:633 kernfs_new_node+0x9a/0x120 fs/kernfs/dir.c:693 __kernfs_create_file+0x5f/0x340 fs/kernfs/file.c:992 sysfs_add_file_mode_ns+0x22a/0x4e0 fs/sysfs/file.c:306 create_files fs/sysfs/group.c:63 [inline] internal_create_group+0x34e/0xc30 fs/sysfs/group.c:147 sysfs_create_group fs/sysfs/group.c:173 [inline] sysfs_create_groups+0x9c/0x140 fs/sysfs/group.c:200 driver_add_groups+0x3e/0x50 drivers/base/driver.c:129 bus_add_driver+0x3a5/0x790 drivers/base/bus.c:684 driver_register+0x1cd/0x410 drivers/base/driver.c:170 __pci_register_driver+0x197/0x200 drivers/pci/pci-driver.c:1411 cx88_audio_pci_driver_init+0x23/0x25 drivers/media/pci/cx88/cx88-alsa.c: 1017 do_one_initcall+0xe0/0x610 init/main.c:884 do_initcall_level init/main.c:952 [inline] do_initcalls init/main.c:960 [inline] do_basic_setup init/main.c:978 [inline] kernel_init_freeable+0x4d0/0x592 init/main.c:1145 kernel_init+0x18/0x190 init/main.c:1062 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 Freed by task 0: (stack is not available) The buggy address belongs to the object at ffff8880608c0000 which belongs to the cache kernfs_node_cache of size 160 The buggy address is located 0 bytes to the right of 160-byte region [ffff8880608c0000, ffff8880608c00a0) The buggy address belongs to the page: page:ffffea0001823000 count:1 mapcount:0 mapping:ffff88806bed1e00 index:0x0 compound_mapcount: 0 flags: 0x100000000008100(slab|head) raw: 0100000000008100 dead000000000100 dead000000000200 ffff88806bed1e00 raw: 0000000000000000 0000000000240024 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880608bff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8880608c0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8880608c0080: 00 00 00 00 fc fc fc fc fc fc fc fc 00 00 00 00 ^ ffff8880608c0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8880608c0180: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00 ================================================================== Link: https://lore.kernel.org/linux-media/1620723603-30912-1-git-send-email-zheyuma97@gmail.comReported-by:Zheyu Ma <zheyuma97@gmail.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Cai Huoqing authored
use SPDX-License-Identifier instead of a verbose license text and remove verbose license text. Link: https://lore.kernel.org/linux-media/20210916020018.8550-1-caihuoqing@baidu.comSigned-off-by:
Cai Huoqing <caihuoqing@baidu.com> Signed-off-by:
-
Wang Hai authored
I got a use-after-free report: dvbdev: dvb_register_device: failed to create device dvb1.dvr0 (-12) ... ================================================================== BUG: KASAN: use-after-free in dvb_dmxdev_release+0xce/0x2f0 ... Call Trace: dump_stack_lvl+0x6c/0x8b print_address_description.constprop.0+0x48/0x70 kasan_report.cold+0x82/0xdb __asan_load4+0x6b/0x90 dvb_dmxdev_release+0xce/0x2f0 ... Allocated by task 7666: kasan_save_stack+0x23/0x50 __kasan_kmalloc+0x83/0xa0 kmem_cache_alloc_trace+0x22e/0x470 dvb_register_device+0x12f/0x980 dvb_dmxdev_init+0x1f3/0x230 ... Freed by task 7666: kasan_save_stack+0x23/0x50 kasan_set_track+0x20/0x30 kasan_set_free_info+0x24/0x40 __kasan_slab_free+0xf2/0x130 kfree+0xd1/0x5c0 dvb_register_device.cold+0x1ac/0x1fa dvb_dmxdev_init+0x1f3/0x230 ... When dvb_register_device() in dvb_dmxdev_init() fails, dvb_dmxdev_init() does not return a failure, and the memory pointed to by dvbdev or dvr_dvbdev is invalid at this point. If they are used subsequently, it will result in UFA or null-ptr-deref. If dvb_register_device() in dvb_dmxdev_init() fails, fix the bug by making dvb_dmxdev_init() return an error as well. Link: https://lore.kernel.org/linux-media/20211015085741.1203283-1-wanghai38@huawei.com Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wang Hai <wanghai38@huawei.com> Signed-off-by:
-
Martin Weber authored
support greyscale pix fmt input for coda9_jpeg_encoder. The hardware supports it, so allow V4L2 Mem2Mem JPEG Encoder use it as well. Tested on an i.MX6QP. [hverkuil: updated the Subject line as suggested by Philipp] Signed-off-by:
Martin Weber <martin.weber@br-automation.com> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Niklas Söderlund authored
The driver already has logic to detect if it fails to stop properly and report this error to the user. The driver however did not report the unused buffers or buffers given to the hardware (if any) with an error, the buffers where instead returned to user-space in the active state. Build on the existing detection of the error condition and correctly return the buffers with an error if it triggers. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
-
Dorota Czaplejewicz authored
Neither imx_media_mbus_fmt_to_ipu_image nor imx_media_ipu_image_to_mbus_fmt were used anywhere. Signed-off-by:
Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> Signed-off-by:
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 9cb2173e ("[media] media: Add stk1160 new driver (easycap replacement)") Cc: stable@vger.kernel.org # 3.7 Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Use the common control-message timeout define for the five-second timeouts. Fixes: 38f993ad ("V4L/DVB (8125): This driver adds support for the Sensoray 2255 devices.") Cc: stable@vger.kernel.org # 2.6.27 Signed-off-by:
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: d855497e ("V4L/DVB (4228a): pvrusb2 to kernel 2.6.18") Cc: stable@vger.kernel.org # 2.6.18 Signed-off-by:
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: a6c2ba28 ("[PATCH] v4l: 716: support for em28xx board family") Cc: stable@vger.kernel.org # 2.6.16 Signed-off-by:
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: ab33d507 ("V4L/DVB (3376): Add cpia2 camera support") Cc: stable@vger.kernel.org # 2.6.17 Signed-off-by:
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Note that the driver was multiplying some of the timeout values with HZ twice resulting in 3000-second timeouts with HZ=1000. Also note that two of the timeout defines are currently unused. Fixes: 2154be65 ("[media] redrat3: new rc-core IR transceiver device driver") Cc: stable@vger.kernel.org # 3.0 Signed-off-by:
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 2154be65 ("[media] redrat3: new rc-core IR transceiver device driver") Cc: stable@vger.kernel.org # 3.0 Signed-off-by:
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 66e89522 ("V4L/DVB: IR: add mceusb IR receiver driver") Cc: stable@vger.kernel.org # 2.6.36 Signed-off-by:
-
Dafna Hirschfeld authored
The prarameter bs_size to function vpu_enc_encode is not used. Remove it. Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by:
-
Dafna Hirschfeld authored
In order for the encoder to work with gstreamer it needs to have the V4L2_CID_MPEG_VIDEO_VP8_PROFILE ctrl. This patch adds that ctrl with only profile 0 supported. Signed-off-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by:
-
- 17 Nov, 2021 20 commits
-
-
Mauro Carvalho Chehab authored
The logic there is meant to be used by newer firmwares. clean it up, in order to make compatible with the chosen firmware version. Signed-off-by: -
Mauro Carvalho Chehab authored
Aligns it which the Intel Aero firmware. Signed-off-by: -
Mauro Carvalho Chehab authored
ia_css_frame_find_crop_resolution() is not used anymore. So, remove it. Signed-off-by: -
Mauro Carvalho Chehab authored
As we're using this firmware for ISP2401: https://github.com/intel-aero/meta-intel-aero-base/blob/master/recipes-kernel/linux/linux-yocto/shisp_2401a0_v21.bin Revert some changes that are not compatible with it, making the code close to the Intel Aero one. Signed-off-by:
-
Mauro Carvalho Chehab authored
As we're using this firmware for ISP2401: https://github.com/intel-aero/meta-intel-aero-base/blob/master/recipes-kernel/linux/linux-yocto/shisp_2401a0_v21.bin It makes no sense to try to select a non-existing binary inside the firmware. So, revert it to reflect the Intel Aero device driver. Signed-off-by:
-
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
It doesn't make sense to have a control for that. Besides that, the Intel Aero implementation doesn't have, which means that even the custom control is not used in practice, at least outside Android. So, get rid of it. Signed-off-by: -
Mauro Carvalho Chehab authored
Change some recovery logic at the driver, in order to make it more compatible with ISP2401 Intel Aero firmware. Signed-off-by: -
Mauro Carvalho Chehab authored
As we're using Intel Aero firmware, make the code closer to the driver for such device. Signed-off-by: -
Mauro Carvalho Chehab authored
The comments are not following Kernel coding style. Also, there are two missing comments that are found at the Intel Aero device driver code. Add them. No functional changes. Signed-off-by: -
Mauro Carvalho Chehab authored
Those seem to be used only on certain ISP2401 firmwares that aren't supported by the driver. So, get rid of them. Signed-off-by: -
Mauro Carvalho Chehab authored
This does nothing but declare extern to a non-existing var. Signed-off-by: -
Mauro Carvalho Chehab authored
This is meant to select a platform-dependent factor between Linux and Windows. It makes no sense to keep it on Kernel. Signed-off-by: -
Mauro Carvalho Chehab authored
This is not defined anywhere, so, solve the ifdefs, getting rid of them. Signed-off-by: -
Mauro Carvalho Chehab authored
Now that the tests for the new ISP2401 input system were dropped, simplify the code, making it closer to the Intel Aero device driver. Signed-off-by: -
Mauro Carvalho Chehab authored
Those tests are related to the input system, which is the same for the chosen firmware, so both ISP2400 and ISP2401 will be identical with that regards. Signed-off-by: -
Mauro Carvalho Chehab authored
With the ISP2401 firmware we're using, the code differences are not that much from ISP2400. Cleanup the code in order to make it closer to Intel Aero driver. Signed-off-by: -
Mauro Carvalho Chehab authored
There are two #ifdefs there which aren't defined anywhere. So, just drop the dead code. Signed-off-by: -
Mauro Carvalho Chehab authored
There are several unused macros. Simplify the logic there, making it closer to the Intel Aero driver and the corresponding firmware, as this is what we have widely available for this device. Signed-off-by: -
Mauro Carvalho Chehab authored
There's nothing inside such files. Just drop them. Signed-off-by:
-
- 16 Nov, 2021 4 commits
-
-
Mauro Carvalho Chehab authored
This is defined as 64 for the devices/firmware that were chosen. So, evaluate the macros accordingly. Signed-off-by: -
Mauro Carvalho Chehab authored
As we're using the firmware from Intel Aero, ensure that the logic inside sh_css as similar as possible to such driver. Signed-off-by: -
Mauro Carvalho Chehab authored
There's a note at the uninit function that warns about issues with mipi frames de-allocation. print a warning if the problem ever happens. Signed-off-by: -
Mauro Carvalho Chehab authored
Such function doesn't exist on Intel Aero driver. As we're using its firmware, it may mean that this is not compatible with the current file. So, drop it. Signed-off-by:
-
