Vulnerabilities

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 /> wifi: ath11k: use work queue to process beacon tx event<br /> <br /> Commit 3a415daa3e8b ("wifi: ath11k: add P2P IE in beacon template")<br /> from Feb 28, 2024 (linux-next), leads to the following Smatch static<br /> checker warning:<br /> <br /> drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie()<br /> warn: sleeping in atomic context<br /> <br /> The reason is that ath11k_bcn_tx_status_event() will directly call might<br /> sleep function ath11k_wmi_cmd_send() during RCU read-side critical<br /> sections. The call trace is like:<br /> <br /> ath11k_bcn_tx_status_event()<br /> -&gt; rcu_read_lock()<br /> -&gt; ath11k_mac_bcn_tx_event()<br /> -&gt; ath11k_mac_setup_bcn_tmpl()<br /> ……<br /> -&gt; ath11k_wmi_bcn_tmpl()<br /> -&gt; ath11k_wmi_cmd_send()<br /> -&gt; rcu_read_unlock()<br /> <br /> Commit 886433a98425 ("ath11k: add support for BSS color change") added the<br /> ath11k_mac_bcn_tx_event(), commit 01e782c89108 ("ath11k: fix warning<br /> of RCU usage for ath11k_mac_get_arvif_by_vdev_id()") added the RCU lock<br /> to avoid warning but also introduced this BUG.<br /> <br /> Use work queue to avoid directly calling ath11k_mac_bcn_tx_event()<br /> during RCU critical sections. No need to worry about the deletion of vif<br /> because cancel_work_sync() will drop the work if it doesn&amp;#39;t start or<br /> block vif deletion until the running work is done.<br /> <br /> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

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 /> f2fs: fix to wait dio completion<br /> <br /> It should wait all existing dio write IOs before block removal,<br /> otherwise, previous direct write IO may overwrite data in the<br /> block which may be reused by other inode.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix out-of-bounds in dbNextAG() and diAlloc()<br /> <br /> In dbNextAG() , there is no check for the case where bmp-&gt;db_numag is<br /> greater or same than MAXAG due to a polluted image, which causes an<br /> out-of-bounds. Therefore, a bounds check should be added in dbMount().<br /> <br /> And in dbNextAG(), a check for the case where agpref is greater than<br /> bmp-&gt;db_numag should be added, so an out-of-bounds exception should be<br /> prevented.<br /> <br /> Additionally, a check for the case where agno is greater or same than<br /> MAXAG should be added in diAlloc() to prevent out-of-bounds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/tdx: Fix "in-kernel MMIO" check<br /> <br /> TDX only supports kernel-initiated MMIO operations. The handle_mmio()<br /> function checks if the #VE exception occurred in the kernel and rejects<br /> the operation if it did not.<br /> <br /> However, userspace can deceive the kernel into performing MMIO on its<br /> behalf. For example, if userspace can point a syscall to an MMIO address,<br /> syscall does get_user() or put_user() on it, triggering MMIO #VE. The<br /> kernel will treat the #VE as in-kernel MMIO.<br /> <br /> Ensure that the target MMIO address is within the kernel before decoding<br /> instruction.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error<br /> <br /> For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input<br /> arguments, zero the value for the case of an error as otherwise it could leak<br /> memory. For tracing, it is not needed given CAP_PERFMON can already read all<br /> kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped<br /> in here.<br /> <br /> Also, the MTU helpers mtu_len pointer value is being written but also read.<br /> Technically, the MEM_UNINIT should not be there in order to always force init.<br /> Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now<br /> implies two things actually: i) write into memory, ii) memory does not have<br /> to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory,<br /> ii) memory must be initialized. This means that for bpf_*_check_mtu() we&amp;#39;re<br /> readding the issue we&amp;#39;re trying to fix, that is, it would then be able to<br /> write back into things like .rodata BPF maps. Follow-up work will rework the<br /> MEM_UNINIT semantics such that the intent can be better expressed. For now<br /> just clear the *mtu_len on error path which can be lifted later again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RISC-V: KVM: Don&amp;#39;t zero-out PMU snapshot area before freeing data<br /> <br /> With the latest Linux-6.11-rc3, the below NULL pointer crash is observed<br /> when SBI PMU snapshot is enabled for the guest and the guest is forcefully<br /> powered-off.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508<br /> Oops [#1]<br /> Modules linked in: kvm<br /> CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3<br /> Hardware name: riscv-virtio,qemu (DT)<br /> epc : __kvm_write_guest_page+0x94/0xa6 [kvm]<br /> ra : __kvm_write_guest_page+0x54/0xa6 [kvm]<br /> epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0<br /> gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000<br /> t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0<br /> s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086<br /> a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0<br /> a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc<br /> s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000<br /> s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000<br /> s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001<br /> s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3<br /> t5 : ffffffff814126e0 t6 : ffffffff81412700<br /> status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d<br /> [] __kvm_write_guest_page+0x94/0xa6 [kvm]<br /> [] kvm_vcpu_write_guest+0x56/0x90 [kvm]<br /> [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm]<br /> [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm]<br /> [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm]<br /> [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm]<br /> [] kvm_destroy_vcpus+0x5a/0xda [kvm]<br /> [] kvm_arch_destroy_vm+0x14/0x28 [kvm]<br /> [] kvm_destroy_vm+0x168/0x2a0 [kvm]<br /> [] kvm_put_kvm+0x3c/0x58 [kvm]<br /> [] kvm_vm_release+0x22/0x2e [kvm]<br /> <br /> Clearly, the kvm_vcpu_write_guest() function is crashing because it is<br /> being called from kvm_pmu_clear_snapshot_area() upon guest tear down.<br /> <br /> To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to<br /> not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because<br /> the guest is anyway being tore down.<br /> <br /> The kvm_pmu_clear_snapshot_area() is also called when guest changes<br /> PMU snapshot area of a VCPU but even in this case the previous PMU<br /> snaphsot area must not be zeroed-out because the guest might have<br /> reclaimed the pervious PMU snapshot area for some other purpose.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Protect against overflow of ALIGN() during iova allocation<br /> <br /> Userspace can supply an iova and uptr such that the target iova alignment<br /> becomes really big and ALIGN() overflows which corrupts the selected area<br /> range during allocation. CONFIG_IOMMUFD_TEST can detect this:<br /> <br /> WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline]<br /> WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352<br /> Modules linked in:<br /> CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024<br /> RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline]<br /> RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352<br /> Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38<br /> RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293<br /> RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00<br /> RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000<br /> RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942<br /> R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010<br /> R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00<br /> FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274<br /> iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Cap the automatic alignment to the huge page size, which is probably a<br /> better idea overall. Huge automatic alignments can fragment and chew up<br /> the available IOVA space without any reason.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading<br /> <br /> The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn&amp;#39;t<br /> implemented, but driver expects number of handlers is<br /> NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by<br /> removing ID.<br /> <br /> Addresses-Coverity-ID: 1598775 ("Out-of-bounds read")

Funadmin 5.0.2 is vulnerable to SQL Injection via the selectFields parameter in the index method of \backend\controller\auth\Auth.php.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: always wait for both firmware loading attempts<br /> <br /> In &amp;#39;rtw_wait_firmware_completion()&amp;#39;, always wait for both (regular and<br /> wowlan) firmware loading attempts. Otherwise if &amp;#39;rtw_usb_intf_init()&amp;#39;<br /> has failed in &amp;#39;rtw_usb_probe()&amp;#39;, &amp;#39;rtw_usb_disconnect()&amp;#39; may issue<br /> &amp;#39;ieee80211_free_hw()&amp;#39; when one of &amp;#39;rtw_load_firmware_cb()&amp;#39; (usually<br /> the wowlan one) is still in progress, causing UAF detected by KASAN.