Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix possible null pointer dereference<br /> <br /> abo-&gt;tbo.resource may be NULL in amdgpu_vm_bo_update.

A vulnerability classified as problematic has been found in EZ-Suite EZ-Partner 5. Affected is an unknown function of the component Forgot Password Handler. The manipulation leads to basic cross site scripting. It is possible to launch the attack remotely. VDB-269154 is the identifier assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability classified as critical was found in Ruijie RG-UAC 1.0. Affected by this vulnerability is an unknown functionality of the file /view/systemConfig/reboot/reboot_commit.php. The manipulation of the argument servicename leads to os command injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-269155. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability, which was classified as critical, has been found in Ruijie RG-UAC 1.0. Affected by this issue is the function get_ip_addr_details of the file /view/dhcp/dhcpConfig/commit.php. The manipulation of the argument ethname leads to os command injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-269156. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev<br /> <br /> struct rpmsg_ctrldev contains a struct cdev. The current code frees<br /> the rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the<br /> cdev is a managed object, therefore its release is not predictable<br /> and the rpmsg_ctrldev could be freed before the cdev is entirely<br /> released, as in the backtrace below.<br /> <br /> [ 93.625603] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x7c<br /> [ 93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0<br /> [ 93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v<br /> [ 93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G B 5.4.163-lockdep #26<br /> [ 93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)<br /> [ 93.730055] Workqueue: events kobject_delayed_cleanup<br /> [ 93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO)<br /> [ 93.740216] pc : debug_print_object+0x13c/0x1b0<br /> [ 93.744890] lr : debug_print_object+0x13c/0x1b0<br /> [ 93.749555] sp : ffffffacf5bc7940<br /> [ 93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000<br /> [ 93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000<br /> [ 93.763916] x25: ffffffd0734f856c x24: dfffffd000000000<br /> [ 93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0<br /> [ 93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0<br /> [ 93.780338] x19: ffffffd075199100 x18: 00000000000276e0<br /> [ 93.785814] x17: 0000000000000000 x16: dfffffd000000000<br /> [ 93.791291] x15: ffffffffffffffff x14: 6e6968207473696c<br /> [ 93.796768] x13: 0000000000000000 x12: ffffffd075e2b000<br /> [ 93.802244] x11: 0000000000000001 x10: 0000000000000000<br /> [ 93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900<br /> [ 93.813200] x7 : 0000000000000000 x6 : 0000000000000000<br /> [ 93.818676] x5 : 0000000000000080 x4 : 0000000000000000<br /> [ 93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001<br /> [ 93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061<br /> [ 93.835104] Call trace:<br /> [ 93.837644] debug_print_object+0x13c/0x1b0<br /> [ 93.841963] __debug_check_no_obj_freed+0x25c/0x3c0<br /> [ 93.846987] debug_check_no_obj_freed+0x18/0x20<br /> [ 93.851669] slab_free_freelist_hook+0xbc/0x1e4<br /> [ 93.856346] kfree+0xfc/0x2f4<br /> [ 93.859416] rpmsg_ctrldev_release_device+0x78/0xb8<br /> [ 93.864445] device_release+0x84/0x168<br /> [ 93.868310] kobject_cleanup+0x12c/0x298<br /> [ 93.872356] kobject_delayed_cleanup+0x10/0x18<br /> [ 93.876948] process_one_work+0x578/0x92c<br /> [ 93.881086] worker_thread+0x804/0xcf8<br /> [ 93.884963] kthread+0x2a8/0x314<br /> [ 93.888303] ret_from_fork+0x10/0x18<br /> <br /> The cdev_device_add/del() API was created to address this issue (see<br /> commit &amp;#39;233ed09d7fda ("chardev: add helper function to register char<br /> devs with a struct device")&amp;#39;), use it instead of cdev add/del().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: core: Fix hang in usb_kill_urb by adding memory barriers<br /> <br /> The syzbot fuzzer has identified a bug in which processes hang waiting<br /> for usb_kill_urb() to return. It turns out the issue is not unlinking<br /> the URB; that works just fine. Rather, the problem arises when the<br /> wakeup notification that the URB has completed is not received.<br /> <br /> The reason is memory-access ordering on SMP systems. In outline form,<br /> usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on<br /> different CPUs perform the following actions:<br /> <br /> CPU 0 CPU 1<br /> ---------------------------- ---------------------------------<br /> usb_kill_urb(): __usb_hcd_giveback_urb():<br /> ... ...<br /> atomic_inc(&amp;urb-&gt;reject); atomic_dec(&amp;urb-&gt;use_count);<br /> ... ...<br /> wait_event(usb_kill_urb_queue,<br /> atomic_read(&amp;urb-&gt;use_count) == 0);<br /> if (atomic_read(&amp;urb-&gt;reject))<br /> wake_up(&amp;usb_kill_urb_queue);<br /> <br /> Confining your attention to urb-&gt;reject and urb-&gt;use_count, you can<br /> see that the overall pattern of accesses on CPU 0 is:<br /> <br /> write urb-&gt;reject, then read urb-&gt;use_count;<br /> <br /> whereas the overall pattern of accesses on CPU 1 is:<br /> <br /> write urb-&gt;use_count, then read urb-&gt;reject.<br /> <br /> This pattern is referred to in memory-model circles as SB (for "Store<br /> Buffering"), and it is well known that without suitable enforcement of<br /> the desired order of accesses -- in the form of memory barriers -- it<br /> is entirely possible for one or both CPUs to execute their reads ahead<br /> of their writes. The end result will be that sometimes CPU 0 sees the<br /> old un-decremented value of urb-&gt;use_count while CPU 1 sees the old<br /> un-incremented value of urb-&gt;reject. Consequently CPU 0 ends up on<br /> the wait queue and never gets woken up, leading to the observed hang<br /> in usb_kill_urb().<br /> <br /> The same pattern of accesses occurs in usb_poison_urb() and the<br /> failure pathway of usb_hcd_submit_urb().<br /> <br /> The problem is fixed by adding suitable memory barriers. To provide<br /> proper memory-access ordering in the SB pattern, a full barrier is<br /> required on both CPUs. The atomic_inc() and atomic_dec() accesses<br /> themselves don&amp;#39;t provide any memory ordering, but since they are<br /> present, we can use the optimized smp_mb__after_atomic() memory<br /> barrier in the various routines to obtain the desired effect.<br /> <br /> This patch adds the necessary memory barriers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci-plat: fix crash when suspend if remote wake enable<br /> <br /> Crashed at i.mx8qm platform when suspend if enable remote wakeup<br /> <br /> Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP<br /> Modules linked in:<br /> CPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12<br /> Hardware name: Freescale i.MX8QM MEK (DT)<br /> Workqueue: events_unbound async_run_entry_fn<br /> pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : xhci_disable_hub_port_wake.isra.62+0x60/0xf8<br /> lr : xhci_disable_hub_port_wake.isra.62+0x34/0xf8<br /> sp : ffff80001394bbf0<br /> x29: ffff80001394bbf0 x28: 0000000000000000 x27: ffff00081193b578<br /> x26: ffff00081193b570 x25: 0000000000000000 x24: 0000000000000000<br /> x23: ffff00081193a29c x22: 0000000000020001 x21: 0000000000000001<br /> x20: 0000000000000000 x19: ffff800014e90490 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000000<br /> x11: 0000000000000000 x10: 0000000000000960 x9 : ffff80001394baa0<br /> x8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 : 000000001853b453<br /> x5 : 0000000000000496 x4 : 0000000000000000 x3 : ffff00081193a29c<br /> x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff000814591620<br /> Call trace:<br /> xhci_disable_hub_port_wake.isra.62+0x60/0xf8<br /> xhci_suspend+0x58/0x510<br /> xhci_plat_suspend+0x50/0x78<br /> platform_pm_suspend+0x2c/0x78<br /> dpm_run_callback.isra.25+0x50/0xe8<br /> __device_suspend+0x108/0x3c0<br /> <br /> The basic flow:<br /> 1. run time suspend call xhci_suspend, xhci parent devices gate the clock.<br /> 2. echo mem &gt;/sys/power/state, system _device_suspend call xhci_suspend<br /> 3. xhci_suspend call xhci_disable_hub_port_wake, which access register,<br /> but clock already gated by run time suspend.<br /> <br /> This problem was hidden by power domain driver, which call run time resume before it.<br /> <br /> But the below commit remove it and make this issue happen.<br /> commit c1df456d0f06e ("PM: domains: Don&amp;#39;t runtime resume devices at genpd_prepare()")<br /> <br /> This patch call run time resume before suspend to make sure clock is on<br /> before access register.<br /> <br /> Testeb-by: Abel Vesa

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: extable: fix load_unaligned_zeropad() reg indices<br /> <br /> In ex_handler_load_unaligned_zeropad() we erroneously extract the data and<br /> addr register indices from ex-&gt;type rather than ex-&gt;data. As ex-&gt;type will<br /> contain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4):<br /> * We&amp;#39;ll always treat X0 as the address register, since EX_DATA_REG_ADDR is<br /> extracted from bits [9:5]. Thus, we may attempt to dereference an<br /> arbitrary address as X0 may hold an arbitrary value.<br /> * We&amp;#39;ll always treat X4 as the data register, since EX_DATA_REG_DATA is<br /> extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary<br /> behaviour within load_unaligned_zeropad() and its caller.<br /> <br /> Fix this by extracting both values from ex-&gt;data as originally intended.<br /> <br /> On an MTE-enabled QEMU image we are hitting the following crash:<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> Call trace:<br /> fixup_exception+0xc4/0x108<br /> __do_kernel_fault+0x3c/0x268<br /> do_tag_check_fault+0x3c/0x104<br /> do_mem_abort+0x44/0xf4<br /> el1_abort+0x40/0x64<br /> el1h_64_sync_handler+0x60/0xa0<br /> el1h_64_sync+0x7c/0x80<br /> link_path_walk+0x150/0x344<br /> path_openat+0xa0/0x7dc<br /> do_filp_open+0xb8/0x168<br /> do_sys_openat2+0x88/0x17c<br /> __arm64_sys_openat+0x74/0xa0<br /> invoke_syscall+0x48/0x148<br /> el0_svc_common+0xb8/0xf8<br /> do_el0_svc+0x28/0x88<br /> el0_svc+0x24/0x84<br /> el0t_64_sync_handler+0x88/0xec<br /> el0t_64_sync+0x1b4/0x1b8<br /> Code: f8695a69 71007d1f 540000e0 927df12a (f940014a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Forcibly leave nested virt when SMM state is toggled<br /> <br /> Forcibly leave nested virtualization operation if userspace toggles SMM<br /> state via KVM_SET_VCPU_EVENTS or KVM_SYNC_X86_EVENTS. If userspace<br /> forces the vCPU out of SMM while it&amp;#39;s post-VMXON and then injects an SMI,<br /> vmx_enter_smm() will overwrite vmx-&gt;nested.smm.vmxon and end up with both<br /> vmxon=false and smm.vmxon=false, but all other nVMX state allocated.<br /> <br /> Don&amp;#39;t attempt to gracefully handle the transition as (a) most transitions<br /> are nonsencial, e.g. forcing SMM while L2 is running, (b) there isn&amp;#39;t<br /> sufficient information to handle all transitions, e.g. SVM wants access<br /> to the SMRAM save state, and (c) KVM_SET_VCPU_EVENTS must precede<br /> KVM_SET_NESTED_STATE during state restore as the latter disallows putting<br /> the vCPU into L2 if SMM is active, and disallows tagging the vCPU as<br /> being post-VMXON in SMM if SMM is not active.<br /> <br /> Abuse of KVM_SET_VCPU_EVENTS manifests as a WARN and memory leak in nVMX<br /> due to failure to free vmcs01&amp;#39;s shadow VMCS, but the bug goes far beyond<br /> just a memory leak, e.g. toggling SMM on while L2 is active puts the vCPU<br /> in an architecturally impossible state.<br /> <br /> WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline]<br /> WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656<br /> Modules linked in:<br /> CPU: 1 PID: 3606 Comm: syz-executor725 Not tainted 5.17.0-rc1-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline]<br /> RIP: 0010:free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656<br /> Code: 0b eb b3 e8 8f 4d 9f 00 e9 f7 fe ff ff 48 89 df e8 92 4d 9f 00<br /> Call Trace:<br /> <br /> kvm_arch_vcpu_destroy+0x72/0x2f0 arch/x86/kvm/x86.c:11123<br /> kvm_vcpu_destroy arch/x86/kvm/../../../virt/kvm/kvm_main.c:441 [inline]<br /> kvm_destroy_vcpus+0x11f/0x290 arch/x86/kvm/../../../virt/kvm/kvm_main.c:460<br /> kvm_free_vcpus arch/x86/kvm/x86.c:11564 [inline]<br /> kvm_arch_destroy_vm+0x2e8/0x470 arch/x86/kvm/x86.c:11676<br /> kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1217 [inline]<br /> kvm_put_kvm+0x4fa/0xb00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1250<br /> kvm_vm_release+0x3f/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1273<br /> __fput+0x286/0x9f0 fs/file_table.c:311<br /> task_work_run+0xdd/0x1a0 kernel/task_work.c:164<br /> exit_task_work include/linux/task_work.h:32 [inline]<br /> do_exit+0xb29/0x2a30 kernel/exit.c:806<br /> do_group_exit+0xd2/0x2f0 kernel/exit.c:935<br /> get_signal+0x4b0/0x28c0 kernel/signal.c:2862<br /> arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:868<br /> handle_signal_work kernel/entry/common.c:148 [inline]<br /> exit_to_user_mode_loop kernel/entry/common.c:172 [inline]<br /> exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]<br /> syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300<br /> do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Free kvm_cpuid_entry2 array on post-KVM_RUN KVM_SET_CPUID{,2}<br /> <br /> Free the "struct kvm_cpuid_entry2" array on successful post-KVM_RUN<br /> KVM_SET_CPUID{,2} to fix a memory leak, the callers of kvm_set_cpuid()<br /> free the array only on failure.<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff88810963a800 (size 2048):<br /> comm "syz-executor025", pid 3610, jiffies 4294944928 (age 8.080s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 0d 00 00 00 ................<br /> 47 65 6e 75 6e 74 65 6c 69 6e 65 49 00 00 00 00 GenuntelineI....<br /> backtrace:<br /> [] kmalloc_node include/linux/slab.h:604 [inline]<br /> [] kvmalloc_node+0x3e/0x100 mm/util.c:580<br /> [] kvmalloc include/linux/slab.h:732 [inline]<br /> [] vmemdup_user+0x22/0x100 mm/util.c:199<br /> [] kvm_vcpu_ioctl_set_cpuid2+0x8f/0xf0 arch/x86/kvm/cpuid.c:423<br /> [] kvm_arch_vcpu_ioctl+0xb99/0x1e60 arch/x86/kvm/x86.c:5251<br /> [] kvm_vcpu_ioctl+0x4ad/0x950 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4066<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+0xfc/0x140 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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: LAPIC: Also cancel preemption timer during SET_LAPIC<br /> <br /> The below warning is splatting during guest reboot.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]<br /> CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G I 5.17.0-rc1+ #5<br /> RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]<br /> Call Trace:<br /> <br /> kvm_vcpu_ioctl+0x279/0x710 [kvm]<br /> __x64_sys_ioctl+0x83/0xb0<br /> do_syscall_64+0x3b/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7fd39797350b<br /> <br /> This can be triggered by not exposing tsc-deadline mode and doing a reboot in<br /> the guest. The lapic_shutdown() function which is called in sys_reboot path<br /> will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears<br /> APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode<br /> switch between tsc-deadline and oneshot/periodic, which can result in preemption<br /> timer be cancelled in apic_update_lvtt(). However, We can&amp;#39;t depend on this when<br /> not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption<br /> timer. Qemu will synchronise states around reset, let&amp;#39;s cancel preemption timer<br /> under KVM_SET_LAPIC.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Wrap dcn301_calculate_wm_and_dlg for FPU.<br /> <br /> Mirrors the logic for dcn30. Cue lots of WARNs and some<br /> kernel panics without this fix.