Vulnerabilities

In Apache Linkis

This vulnerability exists in USB Pratirodh due to the usage of a weaker cryptographic algorithm (hash) SHA1 in user login component. A local attacker with administrative privileges could exploit this vulnerability to obtain the password of USB Pratirodh on the targeted system.<br /> <br /> Successful exploitation of this vulnerability could allow the attacker to take control of the application and modify the access control of registered users or devices on the targeted system.<br />

This vulnerability exists in AppSamvid software due to the usage of a weaker cryptographic algorithm (hash) SHA1 in user login component. An attacker with local administrative privileges could exploit this to obtain the password of AppSamvid on the targeted system.<br /> <br /> Successful exploitation of this vulnerability could allow the attacker to take complete control of the application on the targeted system.

This vulnerability exists in AppSamvid software due to the usage of vulnerable and outdated components. An attacker with local administrative privileges could exploit this by placing malicious DLLs on the targeted system.<br /> <br /> Successful exploitation of this vulnerability could allow the attacker to execute arbitrary code on the targeted system.

<br /> In Blue Planet® products through 22.12, a misconfiguration in the SAML implementation allows for privilege escalation. Only products using SAML authentication are affected.<br /> <br /> Blue Planet® has released software updates that address this vulnerability for the affected products. Customers are advised to upgrade their Blue Planet products to the latest software version as soon as possible. The software updates can be downloaded from the Ciena Support Portal.<br /> <br />

Deserialization of Untrusted Data vulnerability in Apache InLong.This issue affects Apache InLong: from 1.8.0 through 1.10.0, the attackers can <br /> <br /> use the specific payload to read from an arbitrary file. Users are advised to upgrade to Apache InLong&amp;#39;s 1.11.0 or cherry-pick [1] to solve it.<br /> <br /> [1] https://github.com/apache/inlong/pull/9673

Cross-Site Scripting stored vulnerability in Gophish affecting version 0.12.1. This vulnerability could allow an attacker to store a malicious JavaScript payload in the campaign menu and trigger the payload when the campaign is removed from the menu.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: fix lockdep positive in sk_diag_dump_icons()<br /> <br /> syzbot reported a lockdep splat [1].<br /> <br /> Blamed commit hinted about the possible lockdep<br /> violation, and code used unix_state_lock_nested()<br /> in an attempt to silence lockdep.<br /> <br /> It is not sufficient, because unix_state_lock_nested()<br /> is already used from unix_state_double_lock().<br /> <br /> We need to use a separate subclass.<br /> <br /> This patch adds a distinct enumeration to make things<br /> more explicit.<br /> <br /> Also use swap() in unix_state_double_lock() as a clean up.<br /> <br /> v2: add a missing inline keyword to unix_state_lock_nested()<br /> <br /> [1]<br /> WARNING: possible circular locking dependency detected<br /> 6.8.0-rc1-syzkaller-00356-g8a696a29c690 #0 Not tainted<br /> <br /> syz-executor.1/2542 is trying to acquire lock:<br /> ffff88808b5df9e8 (rlock-AF_UNIX){+.+.}-{2:2}, at: skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863<br /> <br /> but task is already holding lock:<br /> ffff88808b5dfe70 (&amp;u-&gt;lock/1){+.+.}-{2:2}, at: unix_dgram_sendmsg+0xfc7/0x2200 net/unix/af_unix.c:2089<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #1 (&amp;u-&gt;lock/1){+.+.}-{2:2}:<br /> lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754<br /> _raw_spin_lock_nested+0x31/0x40 kernel/locking/spinlock.c:378<br /> sk_diag_dump_icons net/unix/diag.c:87 [inline]<br /> sk_diag_fill+0x6ea/0xfe0 net/unix/diag.c:157<br /> sk_diag_dump net/unix/diag.c:196 [inline]<br /> unix_diag_dump+0x3e9/0x630 net/unix/diag.c:220<br /> netlink_dump+0x5c1/0xcd0 net/netlink/af_netlink.c:2264<br /> __netlink_dump_start+0x5d7/0x780 net/netlink/af_netlink.c:2370<br /> netlink_dump_start include/linux/netlink.h:338 [inline]<br /> unix_diag_handler_dump+0x1c3/0x8f0 net/unix/diag.c:319<br /> sock_diag_rcv_msg+0xe3/0x400<br /> netlink_rcv_skb+0x1df/0x430 net/netlink/af_netlink.c:2543<br /> sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]<br /> netlink_unicast+0x7e6/0x980 net/netlink/af_netlink.c:1367<br /> netlink_sendmsg+0xa37/0xd70 net/netlink/af_netlink.c:1908<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg net/socket.c:745 [inline]<br /> sock_write_iter+0x39a/0x520 net/socket.c:1160<br /> call_write_iter include/linux/fs.h:2085 [inline]<br /> new_sync_write fs/read_write.c:497 [inline]<br /> vfs_write+0xa74/0xca0 fs/read_write.c:590<br /> ksys_write+0x1a0/0x2c0 fs/read_write.c:643<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> -&gt; #0 (rlock-AF_UNIX){+.+.}-{2:2}:<br /> check_prev_add kernel/locking/lockdep.c:3134 [inline]<br /> check_prevs_add kernel/locking/lockdep.c:3253 [inline]<br /> validate_chain+0x1909/0x5ab0 kernel/locking/lockdep.c:3869<br /> __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137<br /> lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754<br /> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]<br /> _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162<br /> skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863<br /> unix_dgram_sendmsg+0x15d9/0x2200 net/unix/af_unix.c:2112<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg net/socket.c:745 [inline]<br /> ____sys_sendmsg+0x592/0x890 net/socket.c:2584<br /> ___sys_sendmsg net/socket.c:2638 [inline]<br /> __sys_sendmmsg+0x3b2/0x730 net/socket.c:2724<br /> __do_sys_sendmmsg net/socket.c:2753 [inline]<br /> __se_sys_sendmmsg net/socket.c:2750 [inline]<br /> __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2750<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> other info that might help us debug this:<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> llc: call sock_orphan() at release time<br /> <br /> syzbot reported an interesting trace [1] caused by a stale sk-&gt;sk_wq<br /> pointer in a closed llc socket.<br /> <br /> In commit ff7b11aa481f ("net: socket: set sock-&gt;sk to NULL after<br /> calling proto_ops::release()") Eric Biggers hinted that some protocols<br /> are missing a sock_orphan(), we need to perform a full audit.<br /> <br /> In net-next, I plan to clear sock-&gt;sk from sock_orphan() and<br /> amend Eric patch to add a warning.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline]<br /> BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline]<br /> BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline]<br /> BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468<br /> Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27<br /> <br /> CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0xc4/0x620 mm/kasan/report.c:488<br /> kasan_report+0xda/0x110 mm/kasan/report.c:601<br /> list_empty include/linux/list.h:373 [inline]<br /> waitqueue_active include/linux/wait.h:127 [inline]<br /> sock_def_write_space_wfree net/core/sock.c:3384 [inline]<br /> sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468<br /> skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080<br /> skb_release_all net/core/skbuff.c:1092 [inline]<br /> napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404<br /> e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970<br /> e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline]<br /> e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801<br /> __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576<br /> napi_poll net/core/dev.c:6645 [inline]<br /> net_rx_action+0x956/0xe90 net/core/dev.c:6778<br /> __do_softirq+0x21a/0x8de kernel/softirq.c:553<br /> run_ksoftirqd kernel/softirq.c:921 [inline]<br /> run_ksoftirqd+0x31/0x60 kernel/softirq.c:913<br /> smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164<br /> kthread+0x2c6/0x3a0 kernel/kthread.c:388<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242<br /> <br /> <br /> Allocated by task 5167:<br /> kasan_save_stack+0x33/0x50 mm/kasan/common.c:47<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:68<br /> unpoison_slab_object mm/kasan/common.c:314 [inline]<br /> __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340<br /> kasan_slab_alloc include/linux/kasan.h:201 [inline]<br /> slab_post_alloc_hook mm/slub.c:3813 [inline]<br /> slab_alloc_node mm/slub.c:3860 [inline]<br /> kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879<br /> alloc_inode_sb include/linux/fs.h:3019 [inline]<br /> sock_alloc_inode+0x25/0x1c0 net/socket.c:308<br /> alloc_inode+0x5d/0x220 fs/inode.c:260<br /> new_inode_pseudo+0x16/0x80 fs/inode.c:1005<br /> sock_alloc+0x40/0x270 net/socket.c:634<br /> __sock_create+0xbc/0x800 net/socket.c:1535<br /> sock_create net/socket.c:1622 [inline]<br /> __sys_socket_create net/socket.c:1659 [inline]<br /> __sys_socket+0x14c/0x260 net/socket.c:1706<br /> __do_sys_socket net/socket.c:1720 [inline]<br /> __se_sys_socket net/socket.c:1718 [inline]<br /> __x64_sys_socket+0x72/0xb0 net/socket.c:1718<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> Freed by task 0:<br /> kasan_save_stack+0x33/0x50 mm/kasan/common.c:47<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:68<br /> kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640<br /> poison_slab_object mm/kasan/common.c:241 [inline]<br /> __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257<br /> kasan_slab_free include/linux/kasan.h:184 [inline]<br /> slab_free_hook mm/slub.c:2121 [inlin<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmr: fix kernel panic when forwarding mcast packets<br /> <br /> The stacktrace was:<br /> [ 86.305548] BUG: kernel NULL pointer dereference, address: 0000000000000092<br /> [ 86.306815] #PF: supervisor read access in kernel mode<br /> [ 86.307717] #PF: error_code(0x0000) - not-present page<br /> [ 86.308624] PGD 0 P4D 0<br /> [ 86.309091] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 86.309883] CPU: 2 PID: 3139 Comm: pimd Tainted: G U 6.8.0-6wind-knet #1<br /> [ 86.311027] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014<br /> [ 86.312728] RIP: 0010:ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985)<br /> [ 86.313399] Code: f9 1f 0f 87 85 03 00 00 48 8d 04 5b 48 8d 04 83 49 8d 44 c5 00 48 8b 40 70 48 39 c2 0f 84 d9 00 00 00 49 8b 46 58 48 83 e0 fe b8 92 00 00 00 00 0f 84 55 ff ff ff 49 83 47 38 01 45 85 e4 0f<br /> [ 86.316565] RSP: 0018:ffffad21c0583ae0 EFLAGS: 00010246<br /> [ 86.317497] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> [ 86.318596] RDX: ffff9559cb46c000 RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 86.319627] RBP: ffffad21c0583b30 R08: 0000000000000000 R09: 0000000000000000<br /> [ 86.320650] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001<br /> [ 86.321672] R13: ffff9559c093a000 R14: ffff9559cc00b800 R15: ffff9559c09c1d80<br /> [ 86.322873] FS: 00007f85db661980(0000) GS:ffff955a79d00000(0000) knlGS:0000000000000000<br /> [ 86.324291] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 86.325314] CR2: 0000000000000092 CR3: 000000002f13a000 CR4: 0000000000350ef0<br /> [ 86.326589] Call Trace:<br /> [ 86.327036] <br /> [ 86.327434] ? show_regs (/build/work/knet/arch/x86/kernel/dumpstack.c:479)<br /> [ 86.328049] ? __die (/build/work/knet/arch/x86/kernel/dumpstack.c:421 /build/work/knet/arch/x86/kernel/dumpstack.c:434)<br /> [ 86.328508] ? page_fault_oops (/build/work/knet/arch/x86/mm/fault.c:707)<br /> [ 86.329107] ? do_user_addr_fault (/build/work/knet/arch/x86/mm/fault.c:1264)<br /> [ 86.329756] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)<br /> [ 86.330350] ? __irq_work_queue_local (/build/work/knet/kernel/irq_work.c:111 (discriminator 1))<br /> [ 86.331013] ? exc_page_fault (/build/work/knet/./arch/x86/include/asm/paravirt.h:693 /build/work/knet/arch/x86/mm/fault.c:1515 /build/work/knet/arch/x86/mm/fault.c:1563)<br /> [ 86.331702] ? asm_exc_page_fault (/build/work/knet/./arch/x86/include/asm/idtentry.h:570)<br /> [ 86.332468] ? ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985)<br /> [ 86.333183] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)<br /> [ 86.333920] ipmr_mfc_add (/build/work/knet/./include/linux/rcupdate.h:782 /build/work/knet/net/ipv4/ipmr.c:1009 /build/work/knet/net/ipv4/ipmr.c:1273)<br /> [ 86.334583] ? __pfx_ipmr_hash_cmp (/build/work/knet/net/ipv4/ipmr.c:363)<br /> [ 86.335357] ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470)<br /> [ 86.336135] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)<br /> [ 86.336854] ? ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470)<br /> [ 86.337679] do_ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:944)<br /> [ 86.338408] ? __pfx_unix_stream_read_actor (/build/work/knet/net/unix/af_unix.c:2862)<br /> [ 86.339232] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)<br /> [ 86.339809] ? aa_sk_perm (/build/work/knet/security/apparmor/include/cred.h:153 /build/work/knet/security/apparmor/net.c:181)<br /> [ 86.340342] ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:1415)<br /> [ 86.340859] raw_setsockopt (/build/work/knet/net/ipv4/raw.c:836)<br /> [ 86.341408] ? security_socket_setsockopt (/build/work/knet/security/security.c:4561 (discriminator 13))<br /> [ 86.342116] sock_common_setsockopt (/build/work/knet/net/core/sock.c:3716)<br /> [ 86.342747] do_sock_setsockopt (/build/work/knet/net/socket.c:2313)<br /> [ 86.343363] __sys_setsockopt (/build/work/knet/./include/linux/file.h:32 /build/work/kn<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pds_core: Prevent race issues involving the adminq<br /> <br /> There are multiple paths that can result in using the pdsc&amp;#39;s<br /> adminq.<br /> <br /> [1] pdsc_adminq_isr and the resulting work from queue_work(),<br /> i.e. pdsc_work_thread()-&gt;pdsc_process_adminq()<br /> <br /> [2] pdsc_adminq_post()<br /> <br /> When the device goes through reset via PCIe reset and/or<br /> a fw_down/fw_up cycle due to bad PCIe state or bad device<br /> state the adminq is destroyed and recreated.<br /> <br /> A NULL pointer dereference can happen if [1] or [2] happens<br /> after the adminq is already destroyed.<br /> <br /> In order to fix this, add some further state checks and<br /> implement reference counting for adminq uses. Reference<br /> counting was used because multiple threads can attempt to<br /> access the adminq at the same time via [1] or [2]. Additionally,<br /> multiple clients (i.e. pds-vfio-pci) can be using [2]<br /> at the same time.<br /> <br /> The adminq_refcnt is initialized to 1 when the adminq has been<br /> allocated and is ready to use. Users/clients of the adminq<br /> (i.e. [1] and [2]) will increment the refcnt when they are using<br /> the adminq. When the driver goes into a fw_down cycle it will<br /> set the PDSC_S_FW_DEAD bit and then wait for the adminq_refcnt<br /> to hit 1. Setting the PDSC_S_FW_DEAD before waiting will prevent<br /> any further adminq_refcnt increments. Waiting for the<br /> adminq_refcnt to hit 1 allows for any current users of the adminq<br /> to finish before the driver frees the adminq. Once the<br /> adminq_refcnt hits 1 the driver clears the refcnt to signify that<br /> the adminq is deleted and cannot be used. On the fw_up cycle the<br /> driver will once again initialize the adminq_refcnt to 1 allowing<br /> the adminq to be used again.