Vulnerabilities

A vulnerability was found in LabVantage LIMS 2017. It has been rated as problematic. This issue affects some unknown processing of the file /labvantage/rc?command=page&page=LV_ViewSampleSpec&oosonly=Y&_sdialog=Y. The manipulation of the argument sdcid/keyid1 leads to cross site scripting. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-269153 was assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

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

The Sina Extension for Elementor (Slider, Gallery, Form, Modal, Data Table, Tab, Particle, Free Elementor Widgets & Elementor Templates) plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘url’ parameter in all versions up to, and including, 3.5.4 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

A vulnerability was found in LabVantage LIMS 2017. It has been declared as problematic. This vulnerability affects unknown code of the file /labvantage/rc?command=file&file=WEB-CORE/elements/files/filesembedded.jsp&size=32. The manipulation of the argument height/width leads to cross site scripting. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-269152. 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 /> bpf: Use VM_MAP instead of VM_ALLOC for ringbuf<br /> <br /> After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages<br /> after mapping"), non-VM_ALLOC mappings will be marked as accessible<br /> in __get_vm_area_node() when KASAN is enabled. But now the flag for<br /> ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access<br /> after vmap() returns. Because the ringbuf area is created by mapping<br /> allocated pages, so use VM_MAP instead.<br /> <br /> After the change, info in /proc/vmallocinfo also changes from<br /> [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user<br /> to<br /> [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: bnx2fc: Make bnx2fc_recv_frame() mp safe<br /> <br /> Running tests with a debug kernel shows that bnx2fc_recv_frame() is<br /> modifying the per_cpu lport stats counters in a non-mpsafe way. Just boot<br /> a debug kernel and run the bnx2fc driver with the hardware enabled.<br /> <br /> [ 1391.699147] BUG: using smp_processor_id() in preemptible [00000000] code: bnx2fc_<br /> [ 1391.699160] caller is bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]<br /> [ 1391.699174] CPU: 2 PID: 4355 Comm: bnx2fc_l2_threa Kdump: loaded Tainted: G B<br /> [ 1391.699180] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013<br /> [ 1391.699183] Call Trace:<br /> [ 1391.699188] dump_stack_lvl+0x57/0x7d<br /> [ 1391.699198] check_preemption_disabled+0xc8/0xd0<br /> [ 1391.699205] bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]<br /> [ 1391.699215] ? do_raw_spin_trylock+0xb5/0x180<br /> [ 1391.699221] ? bnx2fc_npiv_create_vports.isra.0+0x4e0/0x4e0 [bnx2fc]<br /> [ 1391.699229] ? bnx2fc_l2_rcv_thread+0xb7/0x3a0 [bnx2fc]<br /> [ 1391.699240] bnx2fc_l2_rcv_thread+0x1af/0x3a0 [bnx2fc]<br /> [ 1391.699250] ? bnx2fc_ulp_init+0xc0/0xc0 [bnx2fc]<br /> [ 1391.699258] kthread+0x364/0x420<br /> [ 1391.699263] ? _raw_spin_unlock_irq+0x24/0x50<br /> [ 1391.699268] ? set_kthread_struct+0x100/0x100<br /> [ 1391.699273] ret_from_fork+0x22/0x30<br /> <br /> Restore the old get_cpu/put_cpu code with some modifications to reduce the<br /> size of the critical section.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codecs: wcd938x: fix incorrect used of portid<br /> <br /> Mixer controls have the channel id in mixer-&gt;reg, which is not same<br /> as port id. port id should be derived from chan_info array.<br /> So fix this. Without this, its possible that we could corrupt<br /> struct wcd938x_sdw_priv by accessing port_map array out of range<br /> with channel id instead of port id.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: max9759: fix underflow in speaker_gain_control_put()<br /> <br /> Check for negative values of "priv-&gt;gain" to prevent an out of bounds<br /> access. The concern is that these might come from the user via:<br /> -&gt; snd_ctl_elem_write_user()<br /> -&gt; snd_ctl_elem_write()<br /> -&gt; kctl-&gt;put()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: mxsfb: Fix NULL pointer dereference<br /> <br /> mxsfb should not ever dereference the NULL pointer which<br /> drm_atomic_get_new_bridge_state is allowed to return.<br /> Assume a fixed format instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net, neigh: Do not trigger immediate probes on NUD_FAILED from neigh_managed_work<br /> <br /> syzkaller was able to trigger a deadlock for NTF_MANAGED entries [0]:<br /> <br /> kworker/0:16/14617 is trying to acquire lock:<br /> ffffffff8d4dd370 (&amp;tbl-&gt;lock){++-.}-{2:2}, at: ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652<br /> [...]<br /> but task is already holding lock:<br /> ffffffff8d4dd370 (&amp;tbl-&gt;lock){++-.}-{2:2}, at: neigh_managed_work+0x35/0x250 net/core/neighbour.c:1572<br /> <br /> The neighbor entry turned to NUD_FAILED state, where __neigh_event_send()<br /> triggered an immediate probe as per commit cd28ca0a3dd1 ("neigh: reduce<br /> arp latency") via neigh_probe() given table lock was held.<br /> <br /> One option to fix this situation is to defer the neigh_probe() back to<br /> the neigh_timer_handler() similarly as pre cd28ca0a3dd1. For the case<br /> of NTF_MANAGED, this deferral is acceptable given this only happens on<br /> actual failure state and regular / expected state is NUD_VALID with the<br /> entry already present.<br /> <br /> The fix adds a parameter to __neigh_event_send() in order to communicate<br /> whether immediate probe is allowed or disallowed. Existing call-sites<br /> of neigh_event_send() default as-is to immediate probe. However, the<br /> neigh_managed_work() disables it via use of neigh_event_send_probe().<br /> <br /> [0] <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_deadlock_bug kernel/locking/lockdep.c:2956 [inline]<br /> check_deadlock kernel/locking/lockdep.c:2999 [inline]<br /> validate_chain kernel/locking/lockdep.c:3788 [inline]<br /> __lock_acquire.cold+0x149/0x3ab kernel/locking/lockdep.c:5027<br /> lock_acquire kernel/locking/lockdep.c:5639 [inline]<br /> lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5604<br /> __raw_write_lock_bh include/linux/rwlock_api_smp.h:202 [inline]<br /> _raw_write_lock_bh+0x2f/0x40 kernel/locking/spinlock.c:334<br /> ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652<br /> ip6_finish_output2+0x1070/0x14f0 net/ipv6/ip6_output.c:123<br /> __ip6_finish_output net/ipv6/ip6_output.c:191 [inline]<br /> __ip6_finish_output+0x61e/0xe90 net/ipv6/ip6_output.c:170<br /> ip6_finish_output+0x32/0x200 net/ipv6/ip6_output.c:201<br /> NF_HOOK_COND include/linux/netfilter.h:296 [inline]<br /> ip6_output+0x1e4/0x530 net/ipv6/ip6_output.c:224<br /> dst_output include/net/dst.h:451 [inline]<br /> NF_HOOK include/linux/netfilter.h:307 [inline]<br /> ndisc_send_skb+0xa99/0x17f0 net/ipv6/ndisc.c:508<br /> ndisc_send_ns+0x3a9/0x840 net/ipv6/ndisc.c:650<br /> ndisc_solicit+0x2cd/0x4f0 net/ipv6/ndisc.c:742<br /> neigh_probe+0xc2/0x110 net/core/neighbour.c:1040<br /> __neigh_event_send+0x37d/0x1570 net/core/neighbour.c:1201<br /> neigh_event_send include/net/neighbour.h:470 [inline]<br /> neigh_managed_work+0x162/0x250 net/core/neighbour.c:1574<br /> process_one_work+0x9ac/0x1650 kernel/workqueue.c:2307<br /> worker_thread+0x657/0x1110 kernel/workqueue.c:2454<br /> kthread+0x2e9/0x3a0 kernel/kthread.c:377<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macsec: Fix offload support for NETDEV_UNREGISTER event<br /> <br /> Current macsec netdev notify handler handles NETDEV_UNREGISTER event by<br /> releasing relevant SW resources only, this causes resources leak in case<br /> of macsec HW offload, as the underlay driver was not notified to clean<br /> it&amp;#39;s macsec offload resources.<br /> <br /> Fix by calling the underlay driver to clean it&amp;#39;s relevant resources<br /> by moving offload handling from macsec_dellink() to macsec_common_dellink()<br /> when handling NETDEV_UNREGISTER event.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: Forward wakeup to smc socket waitqueue after fallback<br /> <br /> When we replace TCP with SMC and a fallback occurs, there may be<br /> some socket waitqueue entries remaining in smc socket-&gt;wq, such<br /> as eppoll_entries inserted by userspace applications.<br /> <br /> After the fallback, data flows over TCP/IP and only clcsocket-&gt;wq<br /> will be woken up. Applications can&amp;#39;t be notified by the entries<br /> which were inserted in smc socket-&gt;wq before fallback. So we need<br /> a mechanism to wake up smc socket-&gt;wq at the same time if some<br /> entries remaining in it.<br /> <br /> The current workaround is to transfer the entries from smc socket-&gt;wq<br /> to clcsock-&gt;wq during the fallback. But this may cause a crash<br /> like this:<br /> <br /> general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E 5.16.0+ #107<br /> RIP: 0010:__wake_up_common+0x65/0x170<br /> Call Trace:<br /> <br /> __wake_up_common_lock+0x7a/0xc0<br /> sock_def_readable+0x3c/0x70<br /> tcp_data_queue+0x4a7/0xc40<br /> tcp_rcv_established+0x32f/0x660<br /> ? sk_filter_trim_cap+0xcb/0x2e0<br /> tcp_v4_do_rcv+0x10b/0x260<br /> tcp_v4_rcv+0xd2a/0xde0<br /> ip_protocol_deliver_rcu+0x3b/0x1d0<br /> ip_local_deliver_finish+0x54/0x60<br /> ip_local_deliver+0x6a/0x110<br /> ? tcp_v4_early_demux+0xa2/0x140<br /> ? tcp_v4_early_demux+0x10d/0x140<br /> ip_sublist_rcv_finish+0x49/0x60<br /> ip_sublist_rcv+0x19d/0x230<br /> ip_list_rcv+0x13e/0x170<br /> __netif_receive_skb_list_core+0x1c2/0x240<br /> netif_receive_skb_list_internal+0x1e6/0x320<br /> napi_complete_done+0x11d/0x190<br /> mlx5e_napi_poll+0x163/0x6b0 [mlx5_core]<br /> __napi_poll+0x3c/0x1b0<br /> net_rx_action+0x27c/0x300<br /> __do_softirq+0x114/0x2d2<br /> irq_exit_rcu+0xb4/0xe0<br /> common_interrupt+0xba/0xe0<br /> <br /> <br /> <br /> The crash is caused by privately transferring waitqueue entries from<br /> smc socket-&gt;wq to clcsock-&gt;wq. The owners of these entries, such as<br /> epoll, have no idea that the entries have been transferred to a<br /> different socket wait queue and still use original waitqueue spinlock<br /> (smc socket-&gt;wq.wait.lock) to make the entries operation exclusive,<br /> but it doesn&amp;#39;t work. The operations to the entries, such as removing<br /> from the waitqueue (now is clcsock-&gt;wq after fallback), may cause a<br /> crash when clcsock waitqueue is being iterated over at the moment.<br /> <br /> This patch tries to fix this by no longer transferring wait queue<br /> entries privately, but introducing own implementations of clcsock&amp;#39;s<br /> callback functions in fallback situation. The callback functions will<br /> forward the wakeup to smc socket-&gt;wq if clcsock-&gt;wq is actually woken<br /> up and smc socket-&gt;wq has remaining entries.