Vulnerabilities

COMFAST CF-XR11 V2.7.2 has a command injection vulnerability in function sub_424CB4. Attackers can send POST request messages to /usr/bin/webmgnt and inject commands into parameter iface.

A stored cross-site scripting (XSS) vulnerability in the Discussion section of Perfex CRM v1.1.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Content parameter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nouveau/firmware: use dma non-coherent allocator<br /> <br /> Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a<br /> BUG() on startup, when the iommu is enabled:<br /> <br /> kernel BUG at include/linux/scatterlist.h:187!<br /> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30<br /> Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019<br /> RIP: 0010:sg_init_one+0x85/0xa0<br /> Code: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54<br /> 24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 0b 0f 0b<br /> 0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00<br /> RSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffffa77600d87000 RCX: 000000000000002b<br /> RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffa77680d87000<br /> RBP: 000000000000e000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508<br /> R13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018<br /> FS: 00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0<br /> Call Trace:<br /> <br /> ? die+0x36/0x90<br /> ? do_trap+0xdd/0x100<br /> ? sg_init_one+0x85/0xa0<br /> ? do_error_trap+0x65/0x80<br /> ? sg_init_one+0x85/0xa0<br /> ? exc_invalid_op+0x50/0x70<br /> ? sg_init_one+0x85/0xa0<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? sg_init_one+0x85/0xa0<br /> nvkm_firmware_ctor+0x14a/0x250 [nouveau]<br /> nvkm_falcon_fw_ctor+0x42/0x70 [nouveau]<br /> ga102_gsp_booter_ctor+0xb4/0x1a0 [nouveau]<br /> r535_gsp_oneinit+0xb3/0x15f0 [nouveau]<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? nvkm_udevice_new+0x95/0x140 [nouveau]<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? ktime_get+0x47/0xb0<br /> <br /> Fix this by using the non-coherent allocator instead, I think there<br /> might be a better answer to this, but it involve ripping up some of<br /> APIs using sg lists.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: move stopping keep-alive into nvme_uninit_ctrl()<br /> <br /> Commit 4733b65d82bd ("nvme: start keep-alive after admin queue setup")<br /> moves starting keep-alive from nvme_start_ctrl() into<br /> nvme_init_ctrl_finish(), but don&amp;#39;t move stopping keep-alive into<br /> nvme_uninit_ctrl(), so keep-alive work can be started and keep pending<br /> after failing to start controller, finally use-after-free is triggered if<br /> nvme host driver is unloaded.<br /> <br /> This patch fixes kernel panic when running nvme/004 in case that connection<br /> failure is triggered, by moving stopping keep-alive into nvme_uninit_ctrl().<br /> <br /> This way is reasonable because keep-alive is now started in<br /> nvme_init_ctrl_finish().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/boot: Avoid possible physmem_info segment corruption<br /> <br /> When physical memory for the kernel image is allocated it does not<br /> consider extra memory required for offsetting the image start to<br /> match it with the lower 20 bits of KASLR virtual base address. That<br /> might lead to kernel access beyond its memory range.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: move dpu_encoder&amp;#39;s connector assignment to atomic_enable()<br /> <br /> For cases where the crtc&amp;#39;s connectors_changed was set without enable/active<br /> getting toggled , there is an atomic_enable() call followed by an<br /> atomic_disable() but without an atomic_mode_set().<br /> <br /> This results in a NULL ptr access for the dpu_encoder_get_drm_fmt() call in<br /> the atomic_enable() as the dpu_encoder&amp;#39;s connector was cleared in the<br /> atomic_disable() but not re-assigned as there was no atomic_mode_set() call.<br /> <br /> Fix the NULL ptr access by moving the assignment for atomic_enable() and also<br /> use drm_atomic_get_new_connector_for_encoder() to get the connector from<br /> the atomic_state.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/606729/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix IPsec RoCE MPV trace call<br /> <br /> Prevent the call trace below from happening, by not allowing IPsec<br /> creation over a slave, if master device doesn&amp;#39;t support IPsec.<br /> <br /> WARNING: CPU: 44 PID: 16136 at kernel/locking/rwsem.c:240 down_read+0x75/0x94<br /> Modules linked in: esp4_offload esp4 act_mirred act_vlan cls_flower sch_ingress mlx5_vdpa vringh vhost_iotlb vdpa mst_pciconf(OE) nfsv3 nfs_acl nfs lockd grace fscache netfs xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill cuse fuse rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_ipoib iw_cm ib_cm ipmi_ssif intel_rapl_msr intel_rapl_common amd64_edac edac_mce_amd kvm_amd kvm irqbypass crct10dif_pclmul crc32_pclmul mlx5_ib ghash_clmulni_intel sha1_ssse3 dell_smbios ib_uverbs aesni_intel crypto_simd dcdbas wmi_bmof dell_wmi_descriptor cryptd pcspkr ib_core acpi_ipmi sp5100_tco ccp i2c_piix4 ipmi_si ptdma k10temp ipmi_devintf ipmi_msghandler acpi_power_meter acpi_cpufreq ext4 mbcache jbd2 sd_mod t10_pi sg mgag200 drm_kms_helper syscopyarea sysfillrect mlx5_core sysimgblt fb_sys_fops cec<br /> ahci libahci mlxfw drm pci_hyperv_intf libata tg3 sha256_ssse3 tls megaraid_sas i2c_algo_bit psample wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: mst_pci]<br /> CPU: 44 PID: 16136 Comm: kworker/44:3 Kdump: loaded Tainted: GOE 5.15.0-20240509.el8uek.uek7_u3_update_v6.6_ipsec_bf.x86_64 #2<br /> Hardware name: Dell Inc. PowerEdge R7525/074H08, BIOS 2.0.3 01/15/2021<br /> Workqueue: events xfrm_state_gc_task<br /> RIP: 0010:down_read+0x75/0x94<br /> Code: 00 48 8b 45 08 65 48 8b 14 25 80 fc 01 00 83 e0 02 48 09 d0 48 83 c8 01 48 89 45 08 5d 31 c0 89 c2 89 c6 89 c7 e9 cb 88 3b 00 0b 48 8b 45 08 a8 01 74 b2 a8 02 75 ae 48 89 c2 48 83 ca 02 f0<br /> RSP: 0018:ffffb26387773da8 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffffa08b658af900 RCX: 0000000000000001<br /> RDX: 0000000000000000 RSI: ff886bc5e1366f2f RDI: 0000000000000000<br /> RBP: ffffa08b658af940 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0a9bfb31540<br /> R13: ffffa0a9bfb37900 R14: 0000000000000000 R15: ffffa0a9bfb37905<br /> FS: 0000000000000000(0000) GS:ffffa0a9bfb00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055a45ed814e8 CR3: 000000109038a000 CR4: 0000000000350ee0<br /> Call Trace:<br /> <br /> ? show_trace_log_lvl+0x1d6/0x2f9<br /> ? show_trace_log_lvl+0x1d6/0x2f9<br /> ? mlx5_devcom_for_each_peer_begin+0x29/0x60 [mlx5_core]<br /> ? down_read+0x75/0x94<br /> ? __warn+0x80/0x113<br /> ? down_read+0x75/0x94<br /> ? report_bug+0xa4/0x11d<br /> ? handle_bug+0x35/0x8b<br /> ? exc_invalid_op+0x14/0x75<br /> ? asm_exc_invalid_op+0x16/0x1b<br /> ? down_read+0x75/0x94<br /> ? down_read+0xe/0x94<br /> mlx5_devcom_for_each_peer_begin+0x29/0x60 [mlx5_core]<br /> mlx5_ipsec_fs_roce_tx_destroy+0xb1/0x130 [mlx5_core]<br /> tx_destroy+0x1b/0xc0 [mlx5_core]<br /> tx_ft_put+0x53/0xc0 [mlx5_core]<br /> mlx5e_xfrm_free_state+0x45/0x90 [mlx5_core]<br /> ___xfrm_state_destroy+0x10f/0x1a2<br /> xfrm_state_gc_task+0x81/0xa9<br /> process_one_work+0x1f1/0x3c6<br /> worker_thread+0x53/0x3e4<br /> ? process_one_work.cold+0x46/0x3c<br /> kthread+0x127/0x144<br /> ? set_kthread_struct+0x60/0x52<br /> ret_from_fork+0x22/0x2d<br /> <br /> ---[ end trace 5ef7896144d398e1 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: only decrement add_addr_accepted for MPJ req<br /> <br /> Adding the following warning ...<br /> <br /> WARN_ON_ONCE(msk-&gt;pm.add_addr_accepted == 0)<br /> <br /> ... before decrementing the add_addr_accepted counter helped to find a<br /> bug when running the "remove single subflow" subtest from the<br /> mptcp_join.sh selftest.<br /> <br /> Removing a &amp;#39;subflow&amp;#39; endpoint will first trigger a RM_ADDR, then the<br /> subflow closure. Before this patch, and upon the reception of the<br /> RM_ADDR, the other peer will then try to decrement this<br /> add_addr_accepted. That&amp;#39;s not correct because the attached subflows have<br /> not been created upon the reception of an ADD_ADDR.<br /> <br /> A way to solve that is to decrement the counter only if the attached<br /> subflow was an MP_JOIN to a remote id that was not 0, and initiated by<br /> the host receiving the RM_ADDR.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: only mark &amp;#39;subflow&amp;#39; endp as available<br /> <br /> Adding the following warning ...<br /> <br /> WARN_ON_ONCE(msk-&gt;pm.local_addr_used == 0)<br /> <br /> ... before decrementing the local_addr_used counter helped to find a bug<br /> when running the "remove single address" subtest from the mptcp_join.sh<br /> selftests.<br /> <br /> Removing a &amp;#39;signal&amp;#39; endpoint will trigger the removal of all subflows<br /> linked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() with<br /> rm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_used<br /> counter, which is wrong in this case because this counter is linked to<br /> &amp;#39;subflow&amp;#39; endpoints, and here it is a &amp;#39;signal&amp;#39; endpoint that is being<br /> removed.<br /> <br /> Now, the counter is decremented, only if the ID is being used outside<br /> of mptcp_pm_nl_rm_addr_or_subflow(), only for &amp;#39;subflow&amp;#39; endpoints, and<br /> if the ID is not 0 -- local_addr_used is not taking into account these<br /> ones. This marking of the ID as being available, and the decrement is<br /> done no matter if a subflow using this ID is currently available,<br /> because the subflow could have been closed before.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> char: xillybus: Check USB endpoints when probing device<br /> <br /> Ensure, as the driver probes the device, that all endpoints that the<br /> driver may attempt to access exist and are of the correct type.<br /> <br /> All XillyUSB devices must have a Bulk IN and Bulk OUT endpoint at<br /> address 1. This is verified in xillyusb_setup_base_eps().<br /> <br /> On top of that, a XillyUSB device may have additional Bulk OUT<br /> endpoints. The information about these endpoints&amp;#39; addresses is deduced<br /> from a data structure (the IDT) that the driver fetches from the device<br /> while probing it. These endpoints are checked in setup_channels().<br /> <br /> A XillyUSB device never has more than one IN endpoint, as all data<br /> towards the host is multiplexed in this single Bulk IN endpoint. This is<br /> why setup_channels() only checks OUT endpoints.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netem: fix return value if duplicate enqueue fails<br /> <br /> There is a bug in netem_enqueue() introduced by<br /> commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec")<br /> that can lead to a use-after-free.<br /> <br /> This commit made netem_enqueue() always return NET_XMIT_SUCCESS<br /> when a packet is duplicated, which can cause the parent qdisc&amp;#39;s q.qlen<br /> to be mistakenly incremented. When this happens qlen_notify() may be<br /> skipped on the parent during destruction, leaving a dangling pointer<br /> for some classful qdiscs like DRR.<br /> <br /> There are two ways for the bug happen:<br /> <br /> - If the duplicated packet is dropped by rootq-&gt;enqueue() and then<br /> the original packet is also dropped.<br /> - If rootq-&gt;enqueue() sends the duplicated packet to a different qdisc<br /> and the original packet is dropped.<br /> <br /> In both cases NET_XMIT_SUCCESS is returned even though no packets<br /> are enqueued at the netem qdisc.<br /> <br /> The fix is to defer the enqueue of the duplicate packet until after<br /> the original packet has been guaranteed to return NET_XMIT_SUCCESS.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: flowtable: initialise extack before use<br /> <br /> Fix missing initialisation of extack in flow offload.