Vulnerabilities

SeaCMS v12.9 has an unauthorized SQL injection vulnerability. The vulnerability is caused by the SQL injection through the cid parameter at /js/player/dmplayer/dmku/index.php?ac=edit, which can cause sensitive database information to be leaked.

** UNSUPPORTED WHEN ASSIGNED ** A vulnerability was found in D-Link DAR-7000 up to 20230922. It has been rated as problematic. Affected by this issue is some unknown functionality of the file /log/decodmail.php. The manipulation of the argument file leads to deserialization. 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-270368. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

A vulnerability was found in ShopXO up to 6.1.0. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file extend/base/Uploader.php. The manipulation of the argument source leads to server-side request forgery. 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-270367. NOTE: The original disclosure confuses CSRF with SSRF.

A vulnerability was found in ZKTeco BioTime up to 9.5.2. It has been classified as problematic. Affected is an unknown function of the component system-group-add Handler. The manipulation of the argument user with the input alert('XSS') leads to cross site scripting. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. VDB-270366 is the identifier assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

Unauthorized file access in WEB Server in ABB ASPECT - Enterprise v3.08.01; NEXUS Series<br /> <br /> v3.08.01<br /> <br /> ; MATRIX Series <br /> <br /> v3.08.01 allows Attacker to access files unauthorized

Unauthorized file access in WEB Server in ABB ASPECT - Enterprise v3.08.01; NEXUS Series<br /> <br /> v3.08.01<br /> <br /> ; MATRIX Series <br /> <br /> v3.08.01 allows Attacker to execute arbitrary code remotely

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix log recovery buffer allocation for the legacy h_size fixup<br /> <br /> Commit a70f9fe52daa ("xfs: detect and handle invalid iclog size set by<br /> mkfs") added a fixup for incorrect h_size values used for the initial<br /> umount record in old xfsprogs versions. Later commit 0c771b99d6c9<br /> ("xfs: clean up calculation of LR header blocks") cleaned up the log<br /> reover buffer calculation, but stoped using the fixed up h_size value<br /> to size the log recovery buffer, which can lead to an out of bounds<br /> access when the incorrect h_size does not come from the old mkfs<br /> tool, but a fuzzer.<br /> <br /> Fix this by open coding xlog_logrec_hblks and taking the fixed h_size<br /> into account for this calculation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension<br /> <br /> If a process module does not have base config extension then the same<br /> format applies to all of it&amp;#39;s inputs and the process-&gt;base_config_ext is<br /> NULL, causing NULL dereference when specifically crafted topology and<br /> sequences used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL<br /> <br /> commit a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc")<br /> includes support for __GFP_NOFAIL, but it presents a conflict with commit<br /> dd544141b9eb ("vmalloc: back off when the current task is OOM-killed"). A<br /> possible scenario is as follows:<br /> <br /> process-a<br /> __vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL)<br /> __vmalloc_area_node()<br /> vm_area_alloc_pages()<br /> --&gt; oom-killer send SIGKILL to process-a<br /> if (fatal_signal_pending(current)) break;<br /> --&gt; return NULL;<br /> <br /> To fix this, do not check fatal_signal_pending() in vm_area_alloc_pages()<br /> if __GFP_NOFAIL set.<br /> <br /> This issue occurred during OPLUS KASAN TEST. Below is part of the log<br /> -&gt; oom-killer sends signal to process<br /> [65731.222840] [ T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/uid_10198,task=gs.intelligence,pid=32454,uid=10198<br /> <br /> [65731.259685] [T32454] Call trace:<br /> [65731.259698] [T32454] dump_backtrace+0xf4/0x118<br /> [65731.259734] [T32454] show_stack+0x18/0x24<br /> [65731.259756] [T32454] dump_stack_lvl+0x60/0x7c<br /> [65731.259781] [T32454] dump_stack+0x18/0x38<br /> [65731.259800] [T32454] mrdump_common_die+0x250/0x39c [mrdump]<br /> [65731.259936] [T32454] ipanic_die+0x20/0x34 [mrdump]<br /> [65731.260019] [T32454] atomic_notifier_call_chain+0xb4/0xfc<br /> [65731.260047] [T32454] notify_die+0x114/0x198<br /> [65731.260073] [T32454] die+0xf4/0x5b4<br /> [65731.260098] [T32454] die_kernel_fault+0x80/0x98<br /> [65731.260124] [T32454] __do_kernel_fault+0x160/0x2a8<br /> [65731.260146] [T32454] do_bad_area+0x68/0x148<br /> [65731.260174] [T32454] do_mem_abort+0x151c/0x1b34<br /> [65731.260204] [T32454] el1_abort+0x3c/0x5c<br /> [65731.260227] [T32454] el1h_64_sync_handler+0x54/0x90<br /> [65731.260248] [T32454] el1h_64_sync+0x68/0x6c<br /> <br /> [65731.260269] [T32454] z_erofs_decompress_queue+0x7f0/0x2258<br /> --&gt; be-&gt;decompressed_pages = kvcalloc(be-&gt;nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL);<br /> kernel panic by NULL pointer dereference.<br /> erofs assume kvmalloc with __GFP_NOFAIL never return NULL.<br /> [65731.260293] [T32454] z_erofs_runqueue+0xf30/0x104c<br /> [65731.260314] [T32454] z_erofs_readahead+0x4f0/0x968<br /> [65731.260339] [T32454] read_pages+0x170/0xadc<br /> [65731.260364] [T32454] page_cache_ra_unbounded+0x874/0xf30<br /> [65731.260388] [T32454] page_cache_ra_order+0x24c/0x714<br /> [65731.260411] [T32454] filemap_fault+0xbf0/0x1a74<br /> [65731.260437] [T32454] __do_fault+0xd0/0x33c<br /> [65731.260462] [T32454] handle_mm_fault+0xf74/0x3fe0<br /> [65731.260486] [T32454] do_mem_abort+0x54c/0x1b34<br /> [65731.260509] [T32454] el0_da+0x44/0x94<br /> [65731.260531] [T32454] el0t_64_sync_handler+0x98/0xb4<br /> [65731.260553] [T32454] el0t_64_sync+0x198/0x19c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: savage: Handle err return when savagefb_check_var failed<br /> <br /> The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero")<br /> checks the value of pixclock to avoid divide-by-zero error. However<br /> the function savagefb_probe doesn&amp;#39;t handle the error return of<br /> savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING<br /> <br /> Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with<br /> small possibility, the root cause is exactly the same as commit<br /> bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")<br /> <br /> However, Dan reported another hang after that, and junxiao investigated<br /> the problem and found out that this is caused by plugged bio can&amp;#39;t issue<br /> from raid5d().<br /> <br /> Current implementation in raid5d() has a weird dependence:<br /> <br /> 1) md_check_recovery() from raid5d() must hold &amp;#39;reconfig_mutex&amp;#39; to clear<br /> MD_SB_CHANGE_PENDING;<br /> 2) raid5d() handles IO in a deadloop, until all IO are issued;<br /> 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;<br /> <br /> This behaviour is introduce before v2.6, and for consequence, if other<br /> context hold &amp;#39;reconfig_mutex&amp;#39;, and md_check_recovery() can&amp;#39;t update<br /> super_block, then raid5d() will waste one cpu 100% by the deadloop, until<br /> &amp;#39;reconfig_mutex&amp;#39; is released.<br /> <br /> Refer to the implementation from raid1 and raid10, fix this problem by<br /> skipping issue IO if MD_SB_CHANGE_PENDING is still set after<br /> md_check_recovery(), daemon thread will be woken up when &amp;#39;reconfig_mutex&amp;#39;<br /> is released. Meanwhile, the hang problem will be fixed as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: do not call vma_add_reservation upon ENOMEM<br /> <br /> sysbot reported a splat [1] on __unmap_hugepage_range(). This is because<br /> vma_needs_reservation() can return -ENOMEM if<br /> allocate_file_region_entries() fails to allocate the file_region struct<br /> for the reservation.<br /> <br /> Check for that and do not call vma_add_reservation() if that is the case,<br /> otherwise region_abort() and region_del() will see that we do not have any<br /> file_regions.<br /> <br /> If we detect that vma_needs_reservation() returned -ENOMEM, we clear the<br /> hugetlb_restore_reserve flag as if this reservation was still consumed, so<br /> free_huge_folio() will not increment the resv count.<br /> <br /> [1] https://lore.kernel.org/linux-mm/0000000000004096100617c58d54@google.com/T/#ma5983bc1ab18a54910da83416b3f89f3c7ee43aa