Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq<br /> <br /> storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it<br /> doesn&amp;#39;t need to make forward progress under memory pressure. Marking this<br /> workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a<br /> non-WQ_MEM_RECLAIM workqueue. In the current state it causes the following<br /> warning:<br /> <br /> [ 14.506347] ------------[ cut here ]------------<br /> [ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn<br /> [ 14.506360] WARNING: CPU: 0 PID: 8 at kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130<br /> [ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu<br /> [ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022<br /> [ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun<br /> [ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130<br /> <br /> [ 14.506408] Call Trace:<br /> [ 14.506412] __flush_work+0xf1/0x1c0<br /> [ 14.506414] __cancel_work_timer+0x12f/0x1b0<br /> [ 14.506417] ? kernfs_put+0xf0/0x190<br /> [ 14.506418] cancel_delayed_work_sync+0x13/0x20<br /> [ 14.506420] disk_block_events+0x78/0x80<br /> [ 14.506421] del_gendisk+0x3d/0x2f0<br /> [ 14.506423] sr_remove+0x28/0x70<br /> [ 14.506427] device_release_driver_internal+0xef/0x1c0<br /> [ 14.506428] device_release_driver+0x12/0x20<br /> [ 14.506429] bus_remove_device+0xe1/0x150<br /> [ 14.506431] device_del+0x167/0x380<br /> [ 14.506432] __scsi_remove_device+0x11d/0x150<br /> [ 14.506433] scsi_remove_device+0x26/0x40<br /> [ 14.506434] storvsc_remove_lun+0x40/0x60<br /> [ 14.506436] process_one_work+0x209/0x400<br /> [ 14.506437] worker_thread+0x34/0x400<br /> [ 14.506439] kthread+0x121/0x140<br /> [ 14.506440] ? process_one_work+0x400/0x400<br /> [ 14.506441] ? kthread_park+0x90/0x90<br /> [ 14.506443] ret_from_fork+0x35/0x40<br /> [ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Don&amp;#39;t use tnum_range on array range checking for poke descriptors<br /> <br /> Hsin-Wei reported a KASAN splat triggered by their BPF runtime fuzzer which<br /> is based on a customized syzkaller:<br /> <br /> BUG: KASAN: slab-out-of-bounds in bpf_int_jit_compile+0x1257/0x13f0<br /> Read of size 8 at addr ffff888004e90b58 by task syz-executor.0/1489<br /> CPU: 1 PID: 1489 Comm: syz-executor.0 Not tainted 5.19.0 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.13.0-1ubuntu1.1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x9c/0xc9<br /> print_address_description.constprop.0+0x1f/0x1f0<br /> ? bpf_int_jit_compile+0x1257/0x13f0<br /> kasan_report.cold+0xeb/0x197<br /> ? kvmalloc_node+0x170/0x200<br /> ? bpf_int_jit_compile+0x1257/0x13f0<br /> bpf_int_jit_compile+0x1257/0x13f0<br /> ? arch_prepare_bpf_dispatcher+0xd0/0xd0<br /> ? rcu_read_lock_sched_held+0x43/0x70<br /> bpf_prog_select_runtime+0x3e8/0x640<br /> ? bpf_obj_name_cpy+0x149/0x1b0<br /> bpf_prog_load+0x102f/0x2220<br /> ? __bpf_prog_put.constprop.0+0x220/0x220<br /> ? find_held_lock+0x2c/0x110<br /> ? __might_fault+0xd6/0x180<br /> ? lock_downgrade+0x6e0/0x6e0<br /> ? lock_is_held_type+0xa6/0x120<br /> ? __might_fault+0x147/0x180<br /> __sys_bpf+0x137b/0x6070<br /> ? bpf_perf_link_attach+0x530/0x530<br /> ? new_sync_read+0x600/0x600<br /> ? __fget_files+0x255/0x450<br /> ? lock_downgrade+0x6e0/0x6e0<br /> ? fput+0x30/0x1a0<br /> ? ksys_write+0x1a8/0x260<br /> __x64_sys_bpf+0x7a/0xc0<br /> ? syscall_enter_from_user_mode+0x21/0x70<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f917c4e2c2d<br /> <br /> The problem here is that a range of tnum_range(0, map-&gt;max_entries - 1) has<br /> limited ability to represent the concrete tight range with the tnum as the<br /> set of resulting states from value + mask can result in a superset of the<br /> actual intended range, and as such a tnum_in(range, reg-&gt;var_off) check may<br /> yield true when it shouldn&amp;#39;t, for example tnum_range(0, 2) would result in<br /> 00XX -&gt; v = 0000, m = 0011 such that the intended set of {0, 1, 2} is here<br /> represented by a less precise superset of {0, 1, 2, 3}. As the register is<br /> known const scalar, really just use the concrete reg-&gt;var_off.value for the<br /> upper index check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> loop: Check for overflow while configuring loop<br /> <br /> The userspace can configure a loop using an ioctl call, wherein<br /> a configuration of type loop_config is passed (see lo_ioctl()&amp;#39;s<br /> case on line 1550 of drivers/block/loop.c). This proceeds to call<br /> loop_configure() which in turn calls loop_set_status_from_info()<br /> (see line 1050 of loop.c), passing &amp;config-&gt;info which is of type<br /> loop_info64*. This function then sets the appropriate values, like<br /> the offset.<br /> <br /> loop_device has lo_offset of type loff_t (see line 52 of loop.c),<br /> which is typdef-chained to long long, whereas loop_info64 has<br /> lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h).<br /> <br /> The function directly copies offset from info to the device as<br /> follows (See line 980 of loop.c):<br /> lo-&gt;lo_offset = info-&gt;lo_offset;<br /> <br /> This results in an overflow, which triggers a warning in iomap_iter()<br /> due to a call to iomap_iter_done() which has:<br /> WARN_ON_ONCE(iter-&gt;iomap.offset &gt; iter-&gt;pos);<br /> <br /> Thus, check for negative value during loop_set_status_from_info().<br /> <br /> Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/mprotect: only reference swap pfn page if type match<br /> <br /> Yu Zhao reported a bug after the commit "mm/swap: Add swp_offset_pfn() to<br /> fetch PFN from swap entry" added a check in swp_offset_pfn() for swap type [1]:<br /> <br /> kernel BUG at include/linux/swapops.h:117!<br /> CPU: 46 PID: 5245 Comm: EventManager_De Tainted: G S O L 6.0.0-dbg-DEV #2<br /> RIP: 0010:pfn_swap_entry_to_page+0x72/0xf0<br /> Code: c6 48 8b 36 48 83 fe ff 74 53 48 01 d1 48 83 c1 08 48 8b 09 f6<br /> c1 01 75 7b 66 90 48 89 c1 48 8b 09 f6 c1 01 74 74 5d c3 eb 9e 0b<br /> 48 ba ff ff ff ff 03 00 00 00 eb ae a9 ff 0f 00 00 75 13 48<br /> RSP: 0018:ffffa59e73fabb80 EFLAGS: 00010282<br /> RAX: 00000000ffffffe8 RBX: 0c00000000000000 RCX: ffffcd5440000000<br /> RDX: 1ffffffffff7a80a RSI: 0000000000000000 RDI: 0c0000000000042b<br /> RBP: ffffa59e73fabb80 R08: ffff9965ca6e8bb8 R09: 0000000000000000<br /> R10: ffffffffa5a2f62d R11: 0000030b372e9fff R12: ffff997b79db5738<br /> R13: 000000000000042b R14: 0c0000000000042b R15: 1ffffffffff7a80a<br /> FS: 00007f549d1bb700(0000) GS:ffff99d3cf680000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000440d035b3180 CR3: 0000002243176004 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> change_pte_range+0x36e/0x880<br /> change_p4d_range+0x2e8/0x670<br /> change_protection_range+0x14e/0x2c0<br /> mprotect_fixup+0x1ee/0x330<br /> do_mprotect_pkey+0x34c/0x440<br /> __x64_sys_mprotect+0x1d/0x30<br /> <br /> It triggers because pfn_swap_entry_to_page() could be called upon e.g. a<br /> genuine swap entry.<br /> <br /> Fix it by only calling it when it&amp;#39;s a write migration entry where the page*<br /> is used.<br /> <br /> [1] https://lore.kernel.org/lkml/CAOUHufaVC2Za-p8m0aiHw6YkheDcrO-C3wRGixwDS32VTS+k1w@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: avoid corrupting page-&gt;mapping in hugetlb_mcopy_atomic_pte<br /> <br /> In MCOPY_ATOMIC_CONTINUE case with a non-shared VMA, pages in the page<br /> cache are installed in the ptes. But hugepage_add_new_anon_rmap is called<br /> for them mistakenly because they&amp;#39;re not vm_shared. This will corrupt the<br /> page-&gt;mapping used by page cache code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: x86-android-tablets: Fix broken touchscreen on Chuwi Hi8 with Windows BIOS<br /> <br /> The x86-android-tablets handling for the Chuwi Hi8 is only necessary with<br /> the Android BIOS and it is causing problems with the Windows BIOS version.<br /> <br /> Specifically when trying to register the already present touchscreen<br /> x86_acpi_irq_helper_get() calls acpi_unregister_gsi(), this breaks<br /> the working of the touchscreen and also leads to an oops:<br /> <br /> [ 14.248946] ------------[ cut here ]------------<br /> [ 14.248954] remove_proc_entry: removing non-empty directory &amp;#39;irq/75&amp;#39;, leaking at least &amp;#39;MSSL0001:00&amp;#39;<br /> [ 14.248983] WARNING: CPU: 3 PID: 440 at fs/proc/generic.c:718 remove_proc_entry<br /> ...<br /> [ 14.249293] unregister_irq_proc+0xe0/0x100<br /> [ 14.249305] free_desc+0x29/0x70<br /> [ 14.249312] irq_free_descs+0x4b/0x80<br /> [ 14.249320] mp_unmap_irq+0x5c/0x60<br /> [ 14.249329] acpi_unregister_gsi_ioapic+0x2a/0x40<br /> [ 14.249338] x86_acpi_irq_helper_get+0x4b/0x190 [x86_android_tablets]<br /> [ 14.249355] x86_android_tablet_init+0x178/0xe34 [x86_android_tablets]<br /> <br /> Add an init callback for the Chuwi Hi8, which detects when the Windows BIOS<br /> is in use and exits with -ENODEV in that case, fixing this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: steam: Prevent NULL pointer dereference in steam_{recv,send}_report<br /> <br /> It is possible for a malicious device to forgo submitting a Feature<br /> Report. The HID Steam driver presently makes no prevision for this<br /> and de-references the &amp;#39;struct hid_report&amp;#39; pointer obtained from the<br /> HID devices without first checking its validity. Let&amp;#39;s change that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udmabuf: Set the DMA mask for the udmabuf device (v2)<br /> <br /> If the DMA mask is not set explicitly, the following warning occurs<br /> when the userspace tries to access the dma-buf via the CPU as<br /> reported by syzbot here:<br /> <br /> WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188<br /> __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188<br /> Modules linked in:<br /> CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted<br /> 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS<br /> Google 01/01/2011<br /> RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188<br /> Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0<br /> 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 0b 45<br /> 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00<br /> RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408<br /> RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f<br /> R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002<br /> R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000<br /> FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264<br /> get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72<br /> begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126<br /> dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164<br /> dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:874 [inline]<br /> __se_sys_ioctl fs/ioctl.c:860 [inline]<br /> __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f62fcf530f9<br /> Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89<br /> f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01<br /> f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9<br /> RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006<br /> RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> <br /> v2: Dont&amp;#39;t forget to deregister if DMA mask setup fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: pvrusb2: fix memory leak in pvr_probe<br /> <br /> The error handling code in pvr2_hdw_create forgets to unregister the<br /> v4l2 device. When pvr2_hdw_create returns back to pvr2_context_create,<br /> it calls pvr2_context_destroy to destroy context, but mp-&gt;hdw is NULL,<br /> which leads to that pvr2_hdw_destroy directly returns.<br /> <br /> Fix this by adding v4l2_device_unregister to decrease the refcount of<br /> usb interface.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: hidraw: fix memory leak in hidraw_release()<br /> <br /> Free the buffered reports before deleting the list entry.<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff88810e72f180 (size 32):<br /> comm "softirq", pid 0, jiffies 4294945143 (age 16.080s)<br /> hex dump (first 32 bytes):<br /> 64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 d..j............<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmemdup+0x23/0x50 mm/util.c:128<br /> [] kmemdup include/linux/fortify-string.h:440 [inline]<br /> [] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521<br /> [] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992<br /> [] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065<br /> [] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284<br /> [] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670<br /> [] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747<br /> [] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988<br /> [] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474<br /> [] expire_timers kernel/time/timer.c:1519 [inline]<br /> [] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790<br /> [] __run_timers kernel/time/timer.c:1768 [inline]<br /> [] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803<br /> [] __do_softirq+0xe6/0x2ea kernel/softirq.c:571<br /> [] invoke_softirq kernel/softirq.c:445 [inline]<br /> [] __irq_exit_rcu kernel/softirq.c:650 [inline]<br /> [] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662<br /> [] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106<br /> [] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649<br /> [] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline]<br /> [] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline]<br /> [] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline]<br /> [] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: gadget: Fix use-after-free Read in usb_udc_uevent()<br /> <br /> The syzbot fuzzer found a race between uevent callbacks and gadget<br /> driver unregistration that can cause a use-after-free bug:<br /> <br /> ---------------------------------------------------------------<br /> BUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130<br /> drivers/usb/gadget/udc/core.c:1732<br /> Read of size 8 at addr ffff888078ce2050 by task udevd/2968<br /> <br /> CPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google<br /> 06/29/2022<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:317 [inline]<br /> print_report.cold+0x2ba/0x719 mm/kasan/report.c:433<br /> kasan_report+0xbe/0x1f0 mm/kasan/report.c:495<br /> usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732<br /> dev_uevent+0x290/0x770 drivers/base/core.c:2424<br /> ---------------------------------------------------------------<br /> <br /> The bug occurs because usb_udc_uevent() dereferences udc-&gt;driver but<br /> does so without acquiring the udc_lock mutex, which protects this<br /> field. If the gadget driver is unbound from the udc concurrently with<br /> uevent processing, the driver structure may be accessed after it has<br /> been deallocated.<br /> <br /> To prevent the race, we make sure that the routine holds the mutex<br /> around the racing accesses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: fb_pm2fb: Avoid potential divide by zero error<br /> <br /> In `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be<br /> copied from user, then go through `fb_set_var()` and<br /> `info-&gt;fbops-&gt;fb_check_var()` which could may be `pm2fb_check_var()`.<br /> Along the path, `var-&gt;pixclock` won&amp;#39;t be modified. This function checks<br /> whether reciprocal of `var-&gt;pixclock` is too high. If `var-&gt;pixclock` is<br /> zero, there will be a divide by zero error. So, it is necessary to check<br /> whether denominator is zero to avoid crash. As this bug is found by<br /> Syzkaller, logs are listed below.<br /> <br /> divide error in pm2fb_check_var<br /> Call Trace:<br /> <br /> fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015<br /> do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110<br /> fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189