Vulnerabilities

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

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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 /> ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead<br /> <br /> ftrace_startup does not remove ops from ftrace_ops_list when<br /> ftrace_startup_enable fails:<br /> <br /> register_ftrace_function<br /> ftrace_startup<br /> __register_ftrace_function<br /> ...<br /> add_ftrace_ops(&amp;ftrace_ops_list, ops)<br /> ...<br /> ...<br /> ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is set to 1<br /> ...<br /> return 0 // ops is in the ftrace_ops_list.<br /> <br /> When ftrace_disabled = 1, unregister_ftrace_function simply returns without doing anything:<br /> unregister_ftrace_function<br /> ftrace_shutdown<br /> if (unlikely(ftrace_disabled))<br /> return -ENODEV; // return here, __unregister_ftrace_function is not executed,<br /> // as a result, ops is still in the ftrace_ops_list<br /> __unregister_ftrace_function<br /> ...<br /> <br /> If ops is dynamically allocated, it will be free later, in this case,<br /> is_ftrace_trampoline accesses NULL pointer:<br /> <br /> is_ftrace_trampoline<br /> ftrace_ops_trampoline<br /> do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL!<br /> <br /> Syzkaller reports as follows:<br /> [ 1203.506103] BUG: kernel NULL pointer dereference, address: 000000000000010b<br /> [ 1203.508039] #PF: supervisor read access in kernel mode<br /> [ 1203.508798] #PF: error_code(0x0000) - not-present page<br /> [ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0<br /> [ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI<br /> [ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Tainted: G B W 5.10.0 #8<br /> [ 1203.512324] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0<br /> [ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00<br /> [ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246<br /> [ 1203.520092] RAX: 0000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866<br /> [ 1203.521469] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000000000000010b<br /> [ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07<br /> [ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 0000000000478399<br /> [ 1203.524596] R13: 0000000000000000 R14: ffff888145088000 R15: 0000000000000008<br /> [ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000<br /> [ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 1203.527626] CR2: 000000000000010b CR3: 0000000170e1e001 CR4: 00000000003706e0<br /> [ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> <br /> Therefore, when ftrace_startup_enable fails, we need to rollback registration<br /> process and remove ops from ftrace_ops_list.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix refcount bug in sk_psock_get (2)<br /> <br /> Syzkaller reports refcount bug as follows:<br /> ------------[ cut here ]------------<br /> refcount_t: saturated; leaking memory.<br /> WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19<br /> Modules linked in:<br /> CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0<br /> <br /> __refcount_add_not_zero include/linux/refcount.h:163 [inline]<br /> __refcount_inc_not_zero include/linux/refcount.h:227 [inline]<br /> refcount_inc_not_zero include/linux/refcount.h:245 [inline]<br /> sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439<br /> tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091<br /> tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983<br /> tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057<br /> tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659<br /> tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682<br /> sk_backlog_rcv include/net/sock.h:1061 [inline]<br /> __release_sock+0x134/0x3b0 net/core/sock.c:2849<br /> release_sock+0x54/0x1b0 net/core/sock.c:3404<br /> inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909<br /> __sys_shutdown_sock net/socket.c:2331 [inline]<br /> __sys_shutdown_sock net/socket.c:2325 [inline]<br /> __sys_shutdown+0xf1/0x1b0 net/socket.c:2343<br /> __do_sys_shutdown net/socket.c:2351 [inline]<br /> __se_sys_shutdown net/socket.c:2349 [inline]<br /> __x64_sys_shutdown+0x50/0x70 net/socket.c:2349<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+0x46/0xb0<br /> <br /> <br /> During SMC fallback process in connect syscall, kernel will<br /> replaces TCP with SMC. In order to forward wakeup<br /> smc socket waitqueue after fallback, kernel will sets<br /> clcsk-&gt;sk_user_data to origin smc socket in<br /> smc_fback_replace_callbacks().<br /> <br /> Later, in shutdown syscall, kernel will calls<br /> sk_psock_get(), which treats the clcsk-&gt;sk_user_data<br /> as psock type, triggering the refcnt warning.<br /> <br /> So, the root cause is that smc and psock, both will use<br /> sk_user_data field. So they will mismatch this field<br /> easily.<br /> <br /> This patch solves it by using another bit(defined as<br /> SK_USER_DATA_PSOCK) in PTRMASK, to mark whether<br /> sk_user_data points to a psock object or not.<br /> This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e<br /> ("net, sk_msg: Clear sk_user_data pointer on clone if tagged").<br /> <br /> For there will possibly be more flags in the sk_user_data field,<br /> this patch also refactor sk_user_data flags code to be more generic<br /> to improve its maintainability.

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 /> 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 /> 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 /> 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 /> 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 /> bpf: Fix a data-race around bpf_jit_limit.<br /> <br /> While reading bpf_jit_limit, it can be changed concurrently via sysctl,<br /> WRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limit<br /> is long, so we need to add a paired READ_ONCE() to avoid load-tearing.