Vulnerabilities

A vulnerability classified as problematic has been found in ruifang-tech Rebuild 3.8.6. This affects an unknown part of the file /project/050-9000000000000001/tasks of the component Project Tasks Section. The manipulation of the argument description leads to cross site scripting. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability was found in running-elephant Datart 1.0.0-rc3. It has been rated as critical. Affected by this issue is the function extractModel of the file /import of the component File Upload. 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 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 /> EDAC/igen6: Avoid segmentation fault on module unload<br /> <br /> The segmentation fault happens because:<br /> <br /> During modprobe:<br /> 1. In igen6_probe(), igen6_pvt will be allocated with kzalloc()<br /> 2. In igen6_register_mci(), mci-&gt;pvt_info will point to<br /> &amp;igen6_pvt-&gt;imc[mc]<br /> <br /> During rmmod:<br /> 1. In mci_release() in edac_mc.c, it will kfree(mci-&gt;pvt_info)<br /> 2. In igen6_remove(), it will kfree(igen6_pvt);<br /> <br /> Fix this issue by setting mci-&gt;pvt_info to NULL to avoid the double<br /> kfree.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: atomisp: Add check for rgby_data memory allocation failure<br /> <br /> In ia_css_3a_statistics_allocate(), there is no check on the allocation<br /> result of the rgby_data memory. If rgby_data is not successfully<br /> allocated, it may trigger the assert(host_stats-&gt;rgby_data) assertion in<br /> ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/cpum_sf: Fix and protect memory allocation of SDBs with mutex<br /> <br /> Reservation of the PMU hardware is done at first event creation<br /> and is protected by a pair of mutex_lock() and mutex_unlock().<br /> After reservation of the PMU hardware the memory<br /> required for the PMUs the event is to be installed on is<br /> allocated by allocate_buffers() and alloc_sampling_buffer().<br /> This done outside of the mutex protection.<br /> Without mutex protection two or more concurrent invocations of<br /> perf_event_init() may run in parallel.<br /> This can lead to allocation of Sample Data Blocks (SDBs)<br /> multiple times for the same PMU.<br /> Prevent this and protect memory allocation of SDBs by<br /> mutex.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c<br /> <br /> Add error pointer checks after calling otx2_mbox_get_rsp().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix soft lockups in fib6_select_path under high next hop churn<br /> <br /> Soft lockups have been observed on a cluster of Linux-based edge routers<br /> located in a highly dynamic environment. Using the `bird` service, these<br /> routers continuously update BGP-advertised routes due to frequently<br /> changing nexthop destinations, while also managing significant IPv6<br /> traffic. The lockups occur during the traversal of the multipath<br /> circular linked-list in the `fib6_select_path` function, particularly<br /> while iterating through the siblings in the list. The issue typically<br /> arises when the nodes of the linked list are unexpectedly deleted<br /> concurrently on a different core—indicated by their &amp;#39;next&amp;#39; and<br /> &amp;#39;previous&amp;#39; elements pointing back to the node itself and their reference<br /> count dropping to zero. This results in an infinite loop, leading to a<br /> soft lockup that triggers a system panic via the watchdog timer.<br /> <br /> Apply RCU primitives in the problematic code sections to resolve the<br /> issue. Where necessary, update the references to fib6_siblings to<br /> annotate or use the RCU APIs.<br /> <br /> Include a test script that reproduces the issue. The script<br /> periodically updates the routing table while generating a heavy load<br /> of outgoing IPv6 traffic through multiple iperf3 clients. It<br /> consistently induces infinite soft lockups within a couple of minutes.<br /> <br /> Kernel log:<br /> <br /> 0 [ffffbd13003e8d30] machine_kexec at ffffffff8ceaf3eb<br /> 1 [ffffbd13003e8d90] __crash_kexec at ffffffff8d0120e3<br /> 2 [ffffbd13003e8e58] panic at ffffffff8cef65d4<br /> 3 [ffffbd13003e8ed8] watchdog_timer_fn at ffffffff8d05cb03<br /> 4 [ffffbd13003e8f08] __hrtimer_run_queues at ffffffff8cfec62f<br /> 5 [ffffbd13003e8f70] hrtimer_interrupt at ffffffff8cfed756<br /> 6 [ffffbd13003e8fd0] __sysvec_apic_timer_interrupt at ffffffff8cea01af<br /> 7 [ffffbd13003e8ff0] sysvec_apic_timer_interrupt at ffffffff8df1b83d<br /> -- --<br /> 8 [ffffbd13003d3708] asm_sysvec_apic_timer_interrupt at ffffffff8e000ecb<br /> [exception RIP: fib6_select_path+299]<br /> RIP: ffffffff8ddafe7b RSP: ffffbd13003d37b8 RFLAGS: 00000287<br /> RAX: ffff975850b43600 RBX: ffff975850b40200 RCX: 0000000000000000<br /> RDX: 000000003fffffff RSI: 0000000051d383e4 RDI: ffff975850b43618<br /> RBP: ffffbd13003d3800 R8: 0000000000000000 R9: ffff975850b40200<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffffbd13003d3830<br /> R13: ffff975850b436a8 R14: ffff975850b43600 R15: 0000000000000007<br /> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018<br /> 9 [ffffbd13003d3808] ip6_pol_route at ffffffff8ddb030c<br /> 10 [ffffbd13003d3888] ip6_pol_route_input at ffffffff8ddb068c<br /> 11 [ffffbd13003d3898] fib6_rule_lookup at ffffffff8ddf02b5<br /> 12 [ffffbd13003d3928] ip6_route_input at ffffffff8ddb0f47<br /> 13 [ffffbd13003d3a18] ip6_rcv_finish_core.constprop.0 at ffffffff8dd950d0<br /> 14 [ffffbd13003d3a30] ip6_list_rcv_finish.constprop.0 at ffffffff8dd96274<br /> 15 [ffffbd13003d3a98] ip6_sublist_rcv at ffffffff8dd96474<br /> 16 [ffffbd13003d3af8] ipv6_list_rcv at ffffffff8dd96615<br /> 17 [ffffbd13003d3b60] __netif_receive_skb_list_core at ffffffff8dc16fec<br /> 18 [ffffbd13003d3be0] netif_receive_skb_list_internal at ffffffff8dc176b3<br /> 19 [ffffbd13003d3c50] napi_gro_receive at ffffffff8dc565b9<br /> 20 [ffffbd13003d3c80] ice_receive_skb at ffffffffc087e4f5 [ice]<br /> 21 [ffffbd13003d3c90] ice_clean_rx_irq at ffffffffc0881b80 [ice]<br /> 22 [ffffbd13003d3d20] ice_napi_poll at ffffffffc088232f [ice]<br /> 23 [ffffbd13003d3d80] __napi_poll at ffffffff8dc18000<br /> 24 [ffffbd13003d3db8] net_rx_action at ffffffff8dc18581<br /> 25 [ffffbd13003d3e40] __do_softirq at ffffffff8df352e9<br /> 26 [ffffbd13003d3eb0] run_ksoftirqd at ffffffff8ceffe47<br /> 27 [ffffbd13003d3ec0] smpboot_thread_fn at ffffffff8cf36a30<br /> 28 [ffffbd13003d3ee8] kthread at ffffffff8cf2b39f<br /> 29 [ffffbd13003d3f28] ret_from_fork at ffffffff8ce5fa64<br /> 30 [ffffbd13003d3f50] ret_from_fork_asm at ffffffff8ce03cbb

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> 9p/xen: fix release of IRQ<br /> <br /> Kernel logs indicate an IRQ was double-freed.<br /> <br /> Pass correct device ID during IRQ release.<br /> <br /> [Dominique: remove confusing variable reset to 0]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/pci: Fix potential double remove of hotplug slot<br /> <br /> In commit 6ee600bfbe0f ("s390/pci: remove hotplug slot when releasing the<br /> device") the zpci_exit_slot() was moved from zpci_device_reserved() to<br /> zpci_release_device() with the intention of keeping the hotplug slot<br /> around until the device is actually removed.<br /> <br /> Now zpci_release_device() is only called once all references are<br /> dropped. Since the zPCI subsystem only drops its reference once the<br /> device is in the reserved state it follows that zpci_release_device()<br /> must only deal with devices in the reserved state. Despite that it<br /> contains code to tear down from both configured and standby state. For<br /> the standby case this already includes the removal of the hotplug slot<br /> so would cause a double removal if a device was ever removed in<br /> either configured or standby state.<br /> <br /> Instead of causing a potential double removal in a case that should<br /> never happen explicitly WARN_ON() if a device in non-reserved state is<br /> released and get rid of the dead code cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: wl128x: Fix atomicity violation in fmc_send_cmd()<br /> <br /> Atomicity violation occurs when the fmc_send_cmd() function is executed<br /> simultaneously with the modification of the fmdev-&gt;resp_skb value.<br /> Consider a scenario where, after passing the validity check within the<br /> function, a non-null fmdev-&gt;resp_skb variable is assigned a null value.<br /> This results in an invalid fmdev-&gt;resp_skb variable passing the validity<br /> check. As seen in the later part of the function, skb = fmdev-&gt;resp_skb;<br /> when the invalid fmdev-&gt;resp_skb passes the check, a null pointer<br /> dereference error may occur at line 478, evt_hdr = (void *)skb-&gt;data;<br /> <br /> To address this issue, it is recommended to include the validity check of<br /> fmdev-&gt;resp_skb within the locked section of the function. This<br /> modification ensures that the value of fmdev-&gt;resp_skb does not change<br /> during the validation process, thereby maintaining its validity.<br /> <br /> This possible bug is found by an experimental static analysis tool<br /> developed by our team. This tool analyzes the locking APIs<br /> to extract function pairs that can be concurrently executed, and then<br /> analyzes the instructions in the paired functions to identify possible<br /> concurrency bugs including data races and atomicity violations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore<br /> <br /> The dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because<br /> the code calls kmalloc() while holding it, which can sleep:<br /> <br /> # echo 1 &gt; /proc/powerpc/vcpudispatch_stats<br /> BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh<br /> preempt_count: 1, expected: 0<br /> 3 locks held by sh/199:<br /> #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438<br /> #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4<br /> #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4<br /> CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152<br /> Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries<br /> Call Trace:<br /> dump_stack_lvl+0x130/0x148 (unreliable)<br /> __might_resched+0x174/0x410<br /> kmem_cache_alloc_noprof+0x340/0x3d0<br /> alloc_dtl_buffers+0x124/0x1ac<br /> vcpudispatch_stats_write+0x2a8/0x5f4<br /> proc_reg_write+0xf4/0x150<br /> vfs_write+0xfc/0x438<br /> ksys_write+0x88/0x148<br /> system_call_exception+0x1c4/0x5a0<br /> system_call_common+0xf4/0x258

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Mark raw_tp arguments with PTR_MAYBE_NULL<br /> <br /> Arguments to a raw tracepoint are tagged as trusted, which carries the<br /> semantics that the pointer will be non-NULL. However, in certain cases,<br /> a raw tracepoint argument may end up being NULL. More context about this<br /> issue is available in [0].<br /> <br /> Thus, there is a discrepancy between the reality, that raw_tp arguments<br /> can actually be NULL, and the verifier&amp;#39;s knowledge, that they are never<br /> NULL, causing explicit NULL checks to be deleted, and accesses to such<br /> pointers potentially crashing the kernel.<br /> <br /> To fix this, mark raw_tp arguments as PTR_MAYBE_NULL, and then special<br /> case the dereference and pointer arithmetic to permit it, and allow<br /> passing them into helpers/kfuncs; these exceptions are made for raw_tp<br /> programs only. Ensure that we don&amp;#39;t do this when ref_obj_id &gt; 0, as in<br /> that case this is an acquired object and doesn&amp;#39;t need such adjustment.<br /> <br /> The reason we do mask_raw_tp_trusted_reg logic is because other will<br /> recheck in places whether the register is a trusted_reg, and then<br /> consider our register as untrusted when detecting the presence of the<br /> PTR_MAYBE_NULL flag.<br /> <br /> To allow safe dereference, we enable PROBE_MEM marking when we see loads<br /> into trusted pointers with PTR_MAYBE_NULL.<br /> <br /> While trusted raw_tp arguments can also be passed into helpers or kfuncs<br /> where such broken assumption may cause issues, a future patch set will<br /> tackle their case separately, as PTR_TO_BTF_ID (without PTR_TRUSTED) can<br /> already be passed into helpers and causes similar problems. Thus, they<br /> are left alone for now.<br /> <br /> It is possible that these checks also permit passing non-raw_tp args<br /> that are trusted PTR_TO_BTF_ID with null marking. In such a case,<br /> allowing dereference when pointer is NULL expands allowed behavior, so<br /> won&amp;#39;t regress existing programs, and the case of passing these into<br /> helpers is the same as above and will be dealt with later.<br /> <br /> Also update the failure case in tp_btf_nullable selftest to capture the<br /> new behavior, as the verifier will no longer cause an error when<br /> directly dereference a raw tracepoint argument marked as __nullable.<br /> <br /> [0]: https://lore.kernel.org/bpf/ZrCZS6nisraEqehw@jlelli-thinkpadt14gen4.remote.csb