Vulnerabilities

An arbitrary file upload vulnerability in the component \Roaming\Omega of OmegaT v6.0.1 allows attackers to execute arbitrary code via uploading a crafted .conf file.

An arbitrary file upload vulnerability in the component \Users\username.BlackBoard of BlackBoard v2.0.0.2 allows attackers to execute arbitrary code via uploading a crafted .xml file.

Multiple endpoints in `oracle-sidecar` in versions 0.347.0 to 0.543.0 were found to be vulnerable to SQL injections.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix lock recursion<br /> <br /> afs_wake_up_async_call() can incur lock recursion. The problem is that it<br /> is called from AF_RXRPC whilst holding the -&gt;notify_lock, but it tries to<br /> take a ref on the afs_call struct in order to pass it to a work queue - but<br /> if the afs_call is already queued, we then have an extraneous ref that must<br /> be put... calling afs_put_call() may call back down into AF_RXRPC through<br /> rxrpc_kernel_shutdown_call(), however, which might try taking the<br /> -&gt;notify_lock again.<br /> <br /> This case isn&amp;#39;t very common, however, so defer it to a workqueue. The oops<br /> looks something like:<br /> <br /> BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646<br /> lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0<br /> CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351<br /> Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x47/0x70<br /> do_raw_spin_lock+0x3c/0x90<br /> rxrpc_kernel_shutdown_call+0x83/0xb0<br /> afs_put_call+0xd7/0x180<br /> rxrpc_notify_socket+0xa0/0x190<br /> rxrpc_input_split_jumbo+0x198/0x1d0<br /> rxrpc_input_data+0x14b/0x1e0<br /> ? rxrpc_input_call_packet+0xc2/0x1f0<br /> rxrpc_input_call_event+0xad/0x6b0<br /> rxrpc_input_packet_on_conn+0x1e1/0x210<br /> rxrpc_input_packet+0x3f2/0x4d0<br /> rxrpc_io_thread+0x243/0x410<br /> ? __pfx_rxrpc_io_thread+0x10/0x10<br /> kthread+0xcf/0xe0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x24/0x40<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx<br /> <br /> As the introduction of the support for vsock and unix sockets in sockmap,<br /> tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK.<br /> vsock and af_unix sockets have vsock_sock and unix_sock instead of<br /> inet_connection_sock. For these sockets, tls_get_ctx may return an invalid<br /> pointer and cause page fault in function tls_sw_ctx_rx.<br /> <br /> BUG: unable to handle page fault for address: 0000000000040030<br /> Workqueue: vsock-loopback vsock_loopback_work<br /> RIP: 0010:sk_psock_strp_data_ready+0x23/0x60<br /> Call Trace:<br /> ? __die+0x81/0xc3<br /> ? no_context+0x194/0x350<br /> ? do_page_fault+0x30/0x110<br /> ? async_page_fault+0x3e/0x50<br /> ? sk_psock_strp_data_ready+0x23/0x60<br /> virtio_transport_recv_pkt+0x750/0x800<br /> ? update_load_avg+0x7e/0x620<br /> vsock_loopback_work+0xd0/0x100<br /> process_one_work+0x1a7/0x360<br /> worker_thread+0x30/0x390<br /> ? create_worker+0x1a0/0x1a0<br /> kthread+0x112/0x130<br /> ? __kthread_cancel_work+0x40/0x40<br /> ret_from_fork+0x1f/0x40<br /> <br /> v2:<br /> - Add IS_ICSK check<br /> v3:<br /> - Update the commits in Fixes

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_pci: Fix admin vq cleanup by using correct info pointer<br /> <br /> vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq<br /> resources by virtio_pci_vq_info pointer. The info pointer of admin<br /> vq is stored in vp_dev-&gt;admin_vq.info instead of vp_dev-&gt;vqs[].<br /> Using the info pointer from vp_dev-&gt;vqs[] for admin vq causes a<br /> kernel NULL pointer dereference bug.<br /> In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer<br /> from vp_dev-&gt;admin_vq.info for admin vq to clean up the resources.<br /> Also make info ptr as argument of vp_del_vq() to be symmetric with<br /> vp_setup_vq().<br /> <br /> vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace:<br /> ==================================================================<br /> BUG: kernel NULL pointer dereference, address:0000000000000000<br /> ...<br /> CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1<br /> RIP: 0010:vp_reset+0x57/0x90 [virtio_pci]<br /> Call Trace:<br /> <br /> ...<br /> ? vp_reset+0x57/0x90 [virtio_pci]<br /> ? vp_reset+0x38/0x90 [virtio_pci]<br /> virtio_reset_device+0x1d/0x30<br /> remove_vq_common+0x1c/0x1a0 [virtio_net]<br /> virtnet_remove+0xa1/0xc0 [virtio_net]<br /> virtio_dev_remove+0x46/0xa0<br /> ...<br /> virtio_pci_driver_exit+0x14/0x810 [virtio_pci]<br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES<br /> <br /> While running ISER over SIW, the initiator machine encounters a warning<br /> from skb_splice_from_iter() indicating that a slab page is being used in<br /> send_page. To address this, it is better to add a sendpage_ok() check<br /> within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag<br /> should be disabled before entering the network stack.<br /> <br /> A similar issue has been discussed for NVMe in this thread:<br /> https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/<br /> <br /> WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320<br /> Call Trace:<br /> tcp_sendmsg_locked+0x368/0xe40<br /> siw_tx_hdt+0x695/0xa40 [siw]<br /> siw_qp_sq_process+0x102/0xb00 [siw]<br /> siw_sq_resume+0x39/0x110 [siw]<br /> siw_run_sq+0x74/0x160 [siw]<br /> kthread+0xd2/0x100<br /> ret_from_fork+0x34/0x40<br /> ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: Fix use-after-free of network namespace.<br /> <br /> Recently, we got a customer report that CIFS triggers oops while<br /> reconnecting to a server. [0]<br /> <br /> The workload runs on Kubernetes, and some pods mount CIFS servers<br /> in non-root network namespaces. The problem rarely happened, but<br /> it was always while the pod was dying.<br /> <br /> The root cause is wrong reference counting for network namespace.<br /> <br /> CIFS uses kernel sockets, which do not hold refcnt of the netns that<br /> the socket belongs to. That means CIFS must ensure the socket is<br /> always freed before its netns; otherwise, use-after-free happens.<br /> <br /> The repro steps are roughly:<br /> <br /> 1. mount CIFS in a non-root netns<br /> 2. drop packets from the netns<br /> 3. destroy the netns<br /> 4. unmount CIFS<br /> <br /> We can reproduce the issue quickly with the script [1] below and see<br /> the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled.<br /> <br /> When the socket is TCP, it is hard to guarantee the netns lifetime<br /> without holding refcnt due to async timers.<br /> <br /> Let&amp;#39;s hold netns refcnt for each socket as done for SMC in commit<br /> 9744d2bf1976 ("smc: Fix use-after-free in tcp_write_timer_handler().").<br /> <br /> Note that we need to move put_net() from cifs_put_tcp_session() to<br /> clean_demultiplex_info(); otherwise, __sock_create() still could touch a<br /> freed netns while cifsd tries to reconnect from cifs_demultiplex_thread().<br /> <br /> Also, maybe_get_net() cannot be put just before __sock_create() because<br /> the code is not under RCU and there is a small chance that the same<br /> address happened to be reallocated to another netns.<br /> <br /> [0]:<br /> CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting...<br /> CIFS: Serverclose failed 4 times, giving up<br /> Unable to handle kernel paging request at virtual address 14de99e461f84a07<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004<br /> CM = 0, WnR = 0<br /> [14de99e461f84a07] address between user and kernel address ranges<br /> Internal error: Oops: 0000000096000004 [#1] SMP<br /> Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs<br /> CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1<br /> Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018<br /> pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : fib_rules_lookup+0x44/0x238<br /> lr : __fib_lookup+0x64/0xbc<br /> sp : ffff8000265db790<br /> x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01<br /> x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580<br /> x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500<br /> x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002<br /> x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294<br /> x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000<br /> x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0<br /> x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500<br /> Call trace:<br /> fib_rules_lookup+0x44/0x238<br /> __fib_lookup+0x64/0xbc<br /> ip_route_output_key_hash_rcu+0x2c4/0x398<br /> ip_route_output_key_hash+0x60/0x8c<br /> tcp_v4_connect+0x290/0x488<br /> __inet_stream_connect+0x108/0x3d0<br /> inet_stream_connect+0x50/0x78<br /> kernel_connect+0x6c/0xac<br /> generic_ip_conne<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-multipath: defer partition scanning<br /> <br /> We need to suppress the partition scan from occuring within the<br /> controller&amp;#39;s scan_work context. If a path error occurs here, the IO will<br /> wait until a path becomes available or all paths are torn down, but that<br /> action also occurs within scan_work, so it would deadlock. Defer the<br /> partion scan to a different context that does not block scan_work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: KVM: Mark hrtimer to expire in hard interrupt context<br /> <br /> Like commit 2c0d278f3293f ("KVM: LAPIC: Mark hrtimer to expire in hard<br /> interrupt context") and commit 9090825fa9974 ("KVM: arm/arm64: Let the<br /> timer expire in hardirq context on RT"), On PREEMPT_RT enabled kernels<br /> unmarked hrtimers are moved into soft interrupt expiry mode by default.<br /> Then the timers are canceled from an preempt-notifier which is invoked<br /> with disabled preemption which is not allowed on PREEMPT_RT.<br /> <br /> The timer callback is short so in could be invoked in hard-IRQ context.<br /> So let the timer expire on hard-IRQ context even on -RT.<br /> <br /> This fix a "scheduling while atomic" bug for PREEMPT_RT enabled kernels:<br /> <br /> BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002<br /> Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns<br /> CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774<br /> Tainted: [W]=WARN<br /> Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022<br /> Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000<br /> 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830<br /> 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001<br /> 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140<br /> 00000000000003fe 0000000000000001 000000000000000d 0000000000000003<br /> 0000000000000030 00000000000003f3 000000000790c000 9000000116747830<br /> 90000000057ef000 0000000000000000 9000000005644830 0000000000000004<br /> 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868<br /> 900000000451b600 9000000005644830 9000000003a13998 0000000010000020<br /> 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d<br /> ...<br /> Call Trace:<br /> [] show_stack+0x38/0x180<br /> [] dump_stack_lvl+0x84/0xc0<br /> [] __schedule_bug+0x48/0x60<br /> [] __schedule+0x1114/0x1660<br /> [] schedule_rtlock+0x20/0x60<br /> [] rtlock_slowlock_locked+0x3f0/0x10a0<br /> [] rt_spin_lock+0x58/0x80<br /> [] hrtimer_cancel_wait_running+0x68/0xc0<br /> [] hrtimer_cancel+0x70/0x80<br /> [] kvm_restore_timer+0x50/0x1a0 [kvm]<br /> [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm]<br /> [] kvm_sched_in+0x34/0x60 [kvm]<br /> [] finish_task_switch.isra.0+0x140/0x2e0<br /> [] __schedule+0x450/0x1660<br /> [] schedule+0x30/0x180<br /> [] kvm_vcpu_block+0x70/0x120 [kvm]<br /> [] kvm_vcpu_halt+0x60/0x3e0 [kvm]<br /> [] kvm_handle_gspr+0x3f4/0x4e0 [kvm]<br /> [] kvm_handle_exit+0x1c8/0x260 [kvm]

Cross Site Scripting vulnerability in Gibbon before v.27.0.01 and fixed in v.28.0.00 allows a remote attacker to obtain sensitive information via the email parameter found in /Gibbon/modules/User Admin/user_manage_editProcess.php.

TOTOLINK A810R V4.1.2cu.5182_B20201026 is vulnerable to Buffer Overflow in downloadFlile.cgi.