Vulnerabilities

Puwell Cloud Tech Co, Ltd 360Eyes Pro v3.9.5.16(3090516) was discovered to transmit sensitive information in cleartext. This vulnerability allows attackers to intercept and access sensitive information, including users' credentials and password change requests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix MST Null Ptr for RV<br /> <br /> The change try to fix below error specific to RV platform:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2<br /> Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022<br /> RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]<br /> Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 8&gt;<br /> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224<br /> RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280<br /> RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850<br /> R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000<br /> R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224<br /> FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0<br /> Call Trace:<br /> <br /> ? __die+0x23/0x70<br /> ? page_fault_oops+0x171/0x4e0<br /> ? plist_add+0xbe/0x100<br /> ? exc_page_fault+0x7c/0x180<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]<br /> ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]<br /> compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]<br /> ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]<br /> compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]<br /> amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]<br /> drm_atomic_check_only+0x5c5/0xa40<br /> drm_mode_atomic_ioctl+0x76e/0xbc0<br /> ? _copy_to_user+0x25/0x30<br /> ? drm_ioctl+0x296/0x4b0<br /> ? __pfx_drm_mode_atomic_ioctl+0x10/0x10<br /> drm_ioctl_kernel+0xcd/0x170<br /> drm_ioctl+0x26d/0x4b0<br /> ? __pfx_drm_mode_atomic_ioctl+0x10/0x10<br /> amdgpu_drm_ioctl+0x4e/0x90 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]<br /> __x64_sys_ioctl+0x94/0xd0<br /> do_syscall_64+0x60/0x90<br /> ? do_syscall_64+0x6c/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> RIP: 0033:0x7f4dad17f76f<br /> Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 c&gt;<br /> RSP: 002b:00007ffd9ae859f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 000055e255a55900 RCX: 00007f4dad17f76f<br /> RDX: 00007ffd9ae85a90 RSI: 00000000c03864bc RDI: 000000000000000b<br /> RBP: 00007ffd9ae85a90 R08: 0000000000000003 R09: 0000000000000003<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c03864bc<br /> R13: 000000000000000b R14: 000055e255a7fc60 R15: 000055e255a01eb0<br /> <br /> Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ccm cmac algif_hash algif_skcipher af_alg joydev mousedev bnep &gt;<br /> typec libphy k10temp ipmi_msghandler roles i2c_scmi acpi_cpufreq mac_hid nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_mas&gt;<br /> CR2: 0000000000000008<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]<br /> Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 8&gt;<br /> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224<br /> RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280<br /> RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850<br /> R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000<br /> R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224<br /> FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC<br /> <br /> Recently, we encounter kernel crash in function rm3100_common_probe<br /> caused by out of bound access of array rm3100_samp_rates (because of<br /> underlying hardware failures). Add boundary check to prevent out of<br /> bound access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/timerlat: Move hrtimer_init to timerlat_fd open()<br /> <br /> Currently, the timerlat&amp;#39;s hrtimer is initialized at the first read of<br /> timerlat_fd, and destroyed at close(). It works, but it causes an error<br /> if the user program open() and close() the file without reading.<br /> <br /> Here&amp;#39;s an example:<br /> <br /> # echo NO_OSNOISE_WORKLOAD &gt; /sys/kernel/debug/tracing/osnoise/options<br /> # echo timerlat &gt; /sys/kernel/debug/tracing/current_tracer<br /> <br /> # cat

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix double-free of blocks due to wrong extents moved_len<br /> <br /> In ext4_move_extents(), moved_len is only updated when all moves are<br /> successfully executed, and only discards orig_inode and donor_inode<br /> preallocations when moved_len is not zero. When the loop fails to exit<br /> after successfully moving some extents, moved_len is not updated and<br /> remains at 0, so it does not discard the preallocations.<br /> <br /> If the moved extents overlap with the preallocated extents, the<br /> overlapped extents are freed twice in ext4_mb_release_inode_pa() and<br /> ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4:<br /> Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is<br /> incremented twice. Hence when trim is executed, a zero-division bug is<br /> triggered in mb_update_avg_fragment_size() because bb_free is not zero<br /> and bb_fragments is zero.<br /> <br /> Therefore, update move_len after each extent move to avoid the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: BTLB: Fix crash when setting up BTLB at CPU bringup<br /> <br /> When using hotplug and bringing up a 32-bit CPU, ask the firmware about the<br /> BTLB information to set up the static (block) TLB entries.<br /> <br /> For that write access to the static btlb_info struct is needed, but<br /> since it is marked __ro_after_init the kernel segfaults with missing<br /> write permissions.<br /> <br /> Fix the crash by dropping the __ro_after_init annotation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Fix random data corruption from exception handler<br /> <br /> The current exception handler implementation, which assists when accessing<br /> user space memory, may exhibit random data corruption if the compiler decides<br /> to use a different register than the specified register %r29 (defined in<br /> ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another<br /> register, the fault handler will nevertheless store -EFAULT into %r29 and thus<br /> trash whatever this register is used for.<br /> Looking at the assembly I found that this happens sometimes in emulate_ldd().<br /> <br /> To solve the issue, the easiest solution would be if it somehow is<br /> possible to tell the fault handler which register is used to hold the error<br /> code. Using %0 or %1 in the inline assembly is not posssible as it will show<br /> up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not<br /> convert to an integer.<br /> <br /> This patch takes another, better and more flexible approach:<br /> We extend the __ex_table (which is out of the execution path) by one 32-word.<br /> In this word we tell the compiler to insert the assembler instruction<br /> "or %r0,%r0,%reg", where %reg references the register which the compiler<br /> choosed for the error return code.<br /> In case of an access failure, the fault handler finds the __ex_table entry and<br /> can examine the opcode. The used register is encoded in the lowest 5 bits, and<br /> the fault handler can then store -EFAULT into this register.<br /> <br /> Since we extend the __ex_table to 3 words we can&amp;#39;t use the BUILDTIME_TABLE_SORT<br /> config option any longer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()<br /> <br /> Syzkaller reported [1] hitting a warning after failing to allocate<br /> resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will<br /> not help much in this case, it might be prudent to switch to<br /> netdev_warn_once(). At the very least it will suppress syzkaller<br /> reports such as [1].<br /> <br /> Just in case, use netdev_warn_once() in send_prp_supervision_frame()<br /> for similar reasons.<br /> <br /> [1]<br /> HSR: Could not send supervision frame<br /> WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294<br /> RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294<br /> ...<br /> Call Trace:<br /> <br /> hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382<br /> call_timer_fn+0x193/0x590 kernel/time/timer.c:1700<br /> expire_timers kernel/time/timer.c:1751 [inline]<br /> __run_timers+0x764/0xb20 kernel/time/timer.c:2022<br /> run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035<br /> __do_softirq+0x21a/0x8de kernel/softirq.c:553<br /> invoke_softirq kernel/softirq.c:427 [inline]<br /> __irq_exit_rcu kernel/softirq.c:632 [inline]<br /> irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644<br /> sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076<br /> <br /> <br /> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649<br /> ...<br /> <br /> This issue is also found in older kernels (at least up to 5.10).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: really cope with fastopen race<br /> <br /> Fastopen and PM-trigger subflow shutdown can race, as reported by<br /> syzkaller.<br /> <br /> In my first attempt to close such race, I missed the fact that<br /> the subflow status can change again before the subflow_state_change<br /> callback is invoked.<br /> <br /> Address the issue additionally copying with all the states directly<br /> reachable from TCP_FIN_WAIT1.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/iommu: Fix the missing iommu_group_put() during platform domain attach<br /> <br /> The function spapr_tce_platform_iommu_attach_dev() is missing to call<br /> iommu_group_put() when the domain is already set. This refcount leak<br /> shows up with BUG_ON() during DLPAR remove operation as:<br /> <br /> KernelBug: Kernel bug in state &amp;#39;None&amp;#39;: kernel BUG at arch/powerpc/platforms/pseries/iommu.c:100!<br /> Oops: Exception in kernel mode, sig: 5 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=8192 NUMA pSeries<br /> <br /> Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_016) hv:phyp pSeries<br /> NIP: c0000000000ff4d4 LR: c0000000000ff4cc CTR: 0000000000000000<br /> REGS: c0000013aed5f840 TRAP: 0700 Tainted: G I (6.8.0-rc3-autotest-g99bd3cb0d12e)<br /> MSR: 8000000000029033 CR: 44002402 XER: 20040000<br /> CFAR: c000000000a0d170 IRQMASK: 0<br /> ...<br /> NIP iommu_reconfig_notifier+0x94/0x200<br /> LR iommu_reconfig_notifier+0x8c/0x200<br /> Call Trace:<br /> iommu_reconfig_notifier+0x8c/0x200 (unreliable)<br /> notifier_call_chain+0xb8/0x19c<br /> blocking_notifier_call_chain+0x64/0x98<br /> of_reconfig_notify+0x44/0xdc<br /> of_detach_node+0x78/0xb0<br /> ofdt_write.part.0+0x86c/0xbb8<br /> proc_reg_write+0xf4/0x150<br /> vfs_write+0xf8/0x488<br /> ksys_write+0x84/0x140<br /> system_call_exception+0x138/0x330<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> The patch adds the missing iommu_group_put() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ad4130: zero-initialize clock init data<br /> <br /> The clk_init_data struct does not have all its members<br /> initialized, causing issues when trying to expose the internal<br /> clock on the CLK pin.<br /> <br /> Fix this by zero-initializing the clk_init_data struct.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/kasan: Fix addr error caused by page alignment<br /> <br /> In kasan_init_region, when k_start is not page aligned, at the begin of<br /> for loop, k_cur = k_start &amp; PAGE_MASK is less than k_start, and then<br /> `va = block + k_cur - k_start` is less than block, the addr va is invalid,<br /> because the memory address space from va to block is not alloced by<br /> memblock_alloc, which will not be reserved by memblock_reserve later, it<br /> will be used by other places.<br /> <br /> As a result, memory overwriting occurs.<br /> <br /> for example:<br /> int __init __weak kasan_init_region(void *start, size_t size)<br /> {<br /> [...]<br /> /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */<br /> block = memblock_alloc(k_end - k_start, PAGE_SIZE);<br /> [...]<br /> for (k_cur = k_start &amp; PAGE_MASK; k_cur