Vulnerabilities

Zoho ManageEngine ADAudit Plus versions below 7271 allows SQL Injection while getting aggregate report data.

Zohocorp ManageEngine PAM360 version 6601 is vulnerable to authorization vulnerability which allows a low-privileged user to perform admin actions. <br /> Note: This vulnerability affects only the PAM360 6600 version. No other versions are applicable to this vulnerability.

In mintplex-labs/anything-llm, a vulnerability exists due to improper input validation in the workspace update process. Specifically, the application fails to validate or format JSON data sent in an HTTP POST request to `/api/workspace/:workspace-slug/update`, allowing it to be executed as part of a database query without restrictions. This flaw enables users with a manager role to craft a request that includes nested write operations, effectively allowing them to create new Administrator accounts.

A memory corruption vulnerability in Fluent Bit versions 2.0.7 thru 3.0.3. This issue lies in the embedded http server’s parsing of trace requests and may result in denial of service conditions, information disclosure, or remote code execution.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb3: fix lock ordering potential deadlock in cifs_sync_mid_result<br /> <br /> Coverity spotted that the cifs_sync_mid_result function could deadlock<br /> <br /> "Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires<br /> lock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock"<br /> <br /> Addresses-Coverity: 1590401 ("Thread deadlock (ORDER_REVERSAL)")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb3: missing lock when picking channel<br /> <br /> Coverity spotted a place where we should have been holding the<br /> channel lock when accessing the ses channel index.<br /> <br /> Addresses-Coverity: 1582039 ("Data race condition (MISSING_LOCK)")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: fix missing hugetlb_lock for resv uncharge<br /> <br /> There is a recent report on UFFDIO_COPY over hugetlb:<br /> <br /> https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/<br /> <br /> 350: lockdep_assert_held(&amp;hugetlb_lock);<br /> <br /> Should be an issue in hugetlb but triggered in an userfault context, where<br /> it goes into the unlikely path where two threads modifying the resv map<br /> together. Mike has a fix in that path for resv uncharge but it looks like<br /> the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()<br /> will update the cgroup pointer, so it requires to be called with the lock<br /> held.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix the pre-flush when appending to a file in writethrough mode<br /> <br /> In netfs_perform_write(), when the file is marked NETFS_ICTX_WRITETHROUGH<br /> or O_*SYNC or RWF_*SYNC was specified, write-through caching is performed<br /> on a buffered file. When setting up for write-through, we flush any<br /> conflicting writes in the region and wait for the write to complete,<br /> failing if there&amp;#39;s a write error to return.<br /> <br /> The issue arises if we&amp;#39;re writing at or above the EOF position because we<br /> skip the flush and - more importantly - the wait. This becomes a problem<br /> if there&amp;#39;s a partial folio at the end of the file that is being written out<br /> and we want to make a write to it too. Both the already-running write and<br /> the write we start both want to clear the writeback mark, but whoever is<br /> second causes a warning looking something like:<br /> <br /> ------------[ cut here ]------------<br /> R=00000012: folio 11 is not under writeback<br /> WARNING: CPU: 34 PID: 654 at fs/netfs/write_collect.c:105<br /> ...<br /> CPU: 34 PID: 654 Comm: kworker/u386:27 Tainted: G S ...<br /> ...<br /> Workqueue: events_unbound netfs_write_collection_worker<br /> ...<br /> RIP: 0010:netfs_writeback_lookup_folio<br /> <br /> Fix this by making the flush-and-wait unconditional. It will do nothing if<br /> there are no folios in the pagecache and will return quickly if there are<br /> no folios in the region specified.<br /> <br /> Further, move the WBC attachment above the flush call as the flush is going<br /> to attach a WBC and detach it again if it is not present - and since we<br /> need one anyway we might as well share it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpll: fix dpll_pin_on_pin_register() for multiple parent pins<br /> <br /> In scenario where pin is registered with multiple parent pins via<br /> dpll_pin_on_pin_register(..), all belonging to the same dpll device.<br /> A second call to dpll_pin_on_pin_unregister(..) would cause a call trace,<br /> as it tries to use already released registration resources (due to fix<br /> introduced in b446631f355e). In this scenario pin was registered twice,<br /> so resources are not yet expected to be release until each registered<br /> pin/pin pair is unregistered.<br /> <br /> Currently, the following crash/call trace is produced when ice driver is<br /> removed on the system with installed E810T NIC which includes dpll device:<br /> <br /> WARNING: CPU: 51 PID: 9155 at drivers/dpll/dpll_core.c:809 dpll_pin_ops+0x20/0x30<br /> RIP: 0010:dpll_pin_ops+0x20/0x30<br /> Call Trace:<br /> ? __warn+0x7f/0x130<br /> ? dpll_pin_ops+0x20/0x30<br /> dpll_msg_add_pin_freq+0x37/0x1d0<br /> dpll_cmd_pin_get_one+0x1c0/0x400<br /> ? __nlmsg_put+0x63/0x80<br /> dpll_pin_event_send+0x93/0x140<br /> dpll_pin_on_pin_unregister+0x3f/0x100<br /> ice_dpll_deinit_pins+0xa1/0x230 [ice]<br /> ice_remove+0xf1/0x210 [ice]<br /> <br /> Fix by adding a parent pointer as a cookie when creating a registration,<br /> also when searching for it. For the regular pins pass NULL, this allows to<br /> create separated registration for each parent the pin is registered with.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix LAG and VF lock dependency in ice_reset_vf()<br /> <br /> 9f74a3dfcf83 ("ice: Fix VF Reset paths when interface in a failed over<br /> aggregate"), the ice driver has acquired the LAG mutex in ice_reset_vf().<br /> The commit placed this lock acquisition just prior to the acquisition of<br /> the VF configuration lock.<br /> <br /> If ice_reset_vf() acquires the configuration lock via the ICE_VF_RESET_LOCK<br /> flag, this could deadlock with ice_vc_cfg_qs_msg() because it always<br /> acquires the locks in the order of the VF configuration lock and then the<br /> LAG mutex.<br /> <br /> Lockdep reports this violation almost immediately on creating and then<br /> removing 2 VF:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 6.8.0-rc6 #54 Tainted: G W O<br /> ------------------------------------------------------<br /> kworker/60:3/6771 is trying to acquire lock:<br /> ff40d43e099380a0 (&amp;vf-&gt;cfg_lock){+.+.}-{3:3}, at: ice_reset_vf+0x22f/0x4d0 [ice]<br /> <br /> but task is already holding lock:<br /> ff40d43ea1961210 (&amp;pf-&gt;lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]<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;pf-&gt;lag_mutex){+.+.}-{3:3}:<br /> __lock_acquire+0x4f8/0xb40<br /> lock_acquire+0xd4/0x2d0<br /> __mutex_lock+0x9b/0xbf0<br /> ice_vc_cfg_qs_msg+0x45/0x690 [ice]<br /> ice_vc_process_vf_msg+0x4f5/0x870 [ice]<br /> __ice_clean_ctrlq+0x2b5/0x600 [ice]<br /> ice_service_task+0x2c9/0x480 [ice]<br /> process_one_work+0x1e9/0x4d0<br /> worker_thread+0x1e1/0x3d0<br /> kthread+0x104/0x140<br /> ret_from_fork+0x31/0x50<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> -&gt; #0 (&amp;vf-&gt;cfg_lock){+.+.}-{3:3}:<br /> check_prev_add+0xe2/0xc50<br /> validate_chain+0x558/0x800<br /> __lock_acquire+0x4f8/0xb40<br /> lock_acquire+0xd4/0x2d0<br /> __mutex_lock+0x9b/0xbf0<br /> ice_reset_vf+0x22f/0x4d0 [ice]<br /> ice_process_vflr_event+0x98/0xd0 [ice]<br /> ice_service_task+0x1cc/0x480 [ice]<br /> process_one_work+0x1e9/0x4d0<br /> worker_thread+0x1e1/0x3d0<br /> kthread+0x104/0x140<br /> ret_from_fork+0x31/0x50<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> CPU0 CPU1<br /> ---- ----<br /> lock(&amp;pf-&gt;lag_mutex);<br /> lock(&amp;vf-&gt;cfg_lock);<br /> lock(&amp;pf-&gt;lag_mutex);<br /> lock(&amp;vf-&gt;cfg_lock);<br /> <br /> *** DEADLOCK ***<br /> 4 locks held by kworker/60:3/6771:<br /> #0: ff40d43e05428b38 ((wq_completion)ice){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0<br /> #1: ff50d06e05197e58 ((work_completion)(&amp;pf-&gt;serv_task)){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0<br /> #2: ff40d43ea1960e50 (&amp;pf-&gt;vfs.table_lock){+.+.}-{3:3}, at: ice_process_vflr_event+0x48/0xd0 [ice]<br /> #3: ff40d43ea1961210 (&amp;pf-&gt;lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]<br /> <br /> stack backtrace:<br /> CPU: 60 PID: 6771 Comm: kworker/60:3 Tainted: G W O 6.8.0-rc6 #54<br /> Hardware name:<br /> Workqueue: ice ice_service_task [ice]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x4a/0x80<br /> check_noncircular+0x12d/0x150<br /> check_prev_add+0xe2/0xc50<br /> ? save_trace+0x59/0x230<br /> ? add_chain_cache+0x109/0x450<br /> validate_chain+0x558/0x800<br /> __lock_acquire+0x4f8/0xb40<br /> ? lockdep_hardirqs_on+0x7d/0x100<br /> lock_acquire+0xd4/0x2d0<br /> ? ice_reset_vf+0x22f/0x4d0 [ice]<br /> ? lock_is_held_type+0xc7/0x120<br /> __mutex_lock+0x9b/0xbf0<br /> ? ice_reset_vf+0x22f/0x4d0 [ice]<br /> ? ice_reset_vf+0x22f/0x4d0 [ice]<br /> ? rcu_is_watching+0x11/0x50<br /> ? ice_reset_vf+0x22f/0x4d0 [ice]<br /> ice_reset_vf+0x22f/0x4d0 [ice]<br /> ? process_one_work+0x176/0x4d0<br /> ice_process_vflr_event+0x98/0xd0 [ice]<br /> ice_service_task+0x1cc/0x480 [ice]<br /> process_one_work+0x1e9/0x4d0<br /> worker_thread+0x1e1/0x3d0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x104/0x140<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x31/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> To avoid deadlock, we must acquire the LAG <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: check for NULL idev in ip_route_use_hint()<br /> <br /> syzbot was able to trigger a NULL deref in fib_validate_source()<br /> in an old tree [1].<br /> <br /> It appears the bug exists in latest trees.<br /> <br /> All calls to __in_dev_get_rcu() must be checked for a NULL result.<br /> <br /> [1]<br /> general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425<br /> Code: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf<br /> RSP: 0018:ffffc900015fee40 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0<br /> RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0<br /> RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000<br /> R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000<br /> R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000<br /> FS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231<br /> ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327<br /> ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline]<br /> ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638<br /> ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673<br /> __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline]<br /> __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620<br /> __netif_receive_skb_list net/core/dev.c:5672 [inline]<br /> netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764<br /> netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816<br /> xdp_recv_frames net/bpf/test_run.c:257 [inline]<br /> xdp_test_run_batch net/bpf/test_run.c:335 [inline]<br /> bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363<br /> bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376<br /> bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736<br /> __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115<br /> __do_sys_bpf kernel/bpf/syscall.c:5201 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5199 [inline]<br /> __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ax25: Fix netdev refcount issue<br /> <br /> The dev_tracker is added to ax25_cb in ax25_bind(). When the<br /> ax25 device is detaching, the dev_tracker of ax25_cb should be<br /> deallocated in ax25_kill_by_device() instead of the dev_tracker<br /> of ax25_dev. The log reported by ref_tracker is shown below:<br /> <br /> [ 80.884935] ref_tracker: reference already released.<br /> [ 80.885150] ref_tracker: allocated in:<br /> [ 80.885349] ax25_dev_device_up+0x105/0x540<br /> [ 80.885730] ax25_device_event+0xa4/0x420<br /> [ 80.885730] notifier_call_chain+0xc9/0x1e0<br /> [ 80.885730] __dev_notify_flags+0x138/0x280<br /> [ 80.885730] dev_change_flags+0xd7/0x180<br /> [ 80.885730] dev_ifsioc+0x6a9/0xa30<br /> [ 80.885730] dev_ioctl+0x4d8/0xd90<br /> [ 80.885730] sock_do_ioctl+0x1c2/0x2d0<br /> [ 80.885730] sock_ioctl+0x38b/0x4f0<br /> [ 80.885730] __se_sys_ioctl+0xad/0xf0<br /> [ 80.885730] do_syscall_64+0xc4/0x1b0<br /> [ 80.885730] entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> [ 80.885730] ref_tracker: freed in:<br /> [ 80.885730] ax25_device_event+0x272/0x420<br /> [ 80.885730] notifier_call_chain+0xc9/0x1e0<br /> [ 80.885730] dev_close_many+0x272/0x370<br /> [ 80.885730] unregister_netdevice_many_notify+0x3b5/0x1180<br /> [ 80.885730] unregister_netdev+0xcf/0x120<br /> [ 80.885730] sixpack_close+0x11f/0x1b0<br /> [ 80.885730] tty_ldisc_kill+0xcb/0x190<br /> [ 80.885730] tty_ldisc_hangup+0x338/0x3d0<br /> [ 80.885730] __tty_hangup+0x504/0x740<br /> [ 80.885730] tty_release+0x46e/0xd80<br /> [ 80.885730] __fput+0x37f/0x770<br /> [ 80.885730] __x64_sys_close+0x7b/0xb0<br /> [ 80.885730] do_syscall_64+0xc4/0x1b0<br /> [ 80.885730] entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> [ 80.893739] ------------[ cut here ]------------<br /> [ 80.894030] WARNING: CPU: 2 PID: 140 at lib/ref_tracker.c:255 ref_tracker_free+0x47b/0x6b0<br /> [ 80.894297] Modules linked in:<br /> [ 80.894929] CPU: 2 PID: 140 Comm: ax25_conn_rel_6 Not tainted 6.9.0-rc4-g8cd26fd90c1a #11<br /> [ 80.895190] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qem4<br /> [ 80.895514] RIP: 0010:ref_tracker_free+0x47b/0x6b0<br /> [ 80.895808] Code: 83 c5 18 4c 89 eb 48 c1 eb 03 8a 04 13 84 c0 0f 85 df 01 00 00 41 83 7d 00 00 75 4b 4c 89 ff 9<br /> [ 80.896171] RSP: 0018:ffff888009edf8c0 EFLAGS: 00000286<br /> [ 80.896339] RAX: 1ffff1100141ac00 RBX: 1ffff1100149463b RCX: dffffc0000000000<br /> [ 80.896502] RDX: 0000000000000001 RSI: 0000000000000246 RDI: ffff88800a0d6518<br /> [ 80.896925] RBP: ffff888009edf9b0 R08: ffff88806d3288d3 R09: 1ffff1100da6511a<br /> [ 80.897212] R10: dffffc0000000000 R11: ffffed100da6511b R12: ffff88800a4a31d4<br /> [ 80.897859] R13: ffff88800a4a31d8 R14: dffffc0000000000 R15: ffff88800a0d6518<br /> [ 80.898279] FS: 00007fd88b7fe700(0000) GS:ffff88806d300000(0000) knlGS:0000000000000000<br /> [ 80.899436] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 80.900181] CR2: 00007fd88c001d48 CR3: 000000000993e000 CR4: 00000000000006f0<br /> ...<br /> [ 80.935774] ref_tracker: sp%d@000000000bb9df3d has 1/1 users at<br /> [ 80.935774] ax25_bind+0x424/0x4e0<br /> [ 80.935774] __sys_bind+0x1d9/0x270<br /> [ 80.935774] __x64_sys_bind+0x75/0x80<br /> [ 80.935774] do_syscall_64+0xc4/0x1b0<br /> [ 80.935774] entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> <br /> Change ax25_dev-&gt;dev_tracker to the dev_tracker of ax25_cb<br /> in order to mitigate the bug.