Full List

Search

Recent Vulnerabilities

• CVE-2024-41795 • published on April 8, 2025 A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices is vulnerable to Cross-Site Request Forgery (CSRF) attacks. This could allow an unauthenticated attacker to change arbitrary device settings by tricking a legitimate device administrator to click on a malicious link.
• CVE-2024-41794 • published on April 8, 2025 A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). Affected devices contain hardcoded credentials for remote access to the device operating system with root privileges. This could allow unauthenticated remote attackers to gain full access to a device, if they are in possession of these credentials and if the ssh service is enabled (e.g., by exploitation of CVE-2024-41793).
• CVE-2024-41793 • published on April 8, 2025 A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices provides an endpoint that allows to enable the ssh service without authentication. This could allow an unauthenticated remote attacker to enable remote access to the device via ssh.
• CVE-2025-3064 • published on April 8, 2025 The WPFront User Role Editor plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 4.2.1. This is due to missing or incorrect nonce validation on the whitelist_options() function. This makes it possible for unauthenticated attackers to update the default role option that can be leveraged for privilege escalation via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. This is only exploitable on multisite instances.
• CVE-2025-3436 • published on April 8, 2025 The coreActivity: Activity Logging for WordPress plugin for WordPress is vulnerable to SQL Injection via the 'order' and 'orderby' parameters in all versions up to, and including, 2.7 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with Subscriber-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.
• CVE-2025-3433 • published on April 8, 2025 The Advanced Advertising System plugin for WordPress is vulnerable to Open Redirect in all versions up to, and including, 1.3.1. This is due to insufficient validation on the redirect url supplied via the 'redir' parameter. This makes it possible for unauthenticated attackers to redirect users to potentially malicious sites if they can successfully trick them into performing an action.
• CVE-2024-41792 • published on April 8, 2025 A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices contains a path traversal vulnerability. This could allow an unauthenticated attacker it to access arbitrary files on the device with root privileges.
• CVE-2025-3432 • published on April 8, 2025 The AAWP Obfuscator plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'data-aawp-web' parameter in all versions up to, and including, 1.0 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Author-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
• CVE-2024-41791 • published on April 8, 2025 A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices does not authenticate report creation requests. This could allow an unauthenticated remote attacker to read or clear the log files on the device, reset the device or set the date and time.
• CVE-2024-41790 • published on April 8, 2025 A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices does not sanitize the region parameter in specific POST requests. This could allow an authenticated remote attacker to execute arbitrary code with root privileges.
• CVE-2024-41789 • published on April 8, 2025 A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices does not sanitize the language parameter in specific POST requests. This could allow an authenticated remote attacker to execute arbitrary code with root privileges.
• CVE-2024-41788 • published on April 8, 2025 A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices does not sanitize the input parameters in specific GET requests. This could allow an authenticated remote attacker to execute arbitrary code with root privileges.
• CVE-2025-22017 • published on April 8, 2025 In the Linux kernel, the following vulnerability has been resolved: devlink: fix xa_alloc_cyclic() error handling In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will be returned, which will cause IS_ERR() to be false. Which can lead to dereference not allocated pointer (rel). Fix it by checking if err is lower than zero. This wasn't found in real usecase, only noticed. Credit to Pierre.
• CVE-2025-22016 • published on April 8, 2025 In the Linux kernel, the following vulnerability has been resolved: dpll: fix xa_alloc_cyclic() error handling In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will be returned, which will cause IS_ERR() to be false. Which can lead to dereference not allocated pointer (pin). Fix it by checking if err is lower than zero. This wasn't found in real usecase, only noticed. Credit to Pierre.
• CVE-2025-22015 • published on April 8, 2025 In the Linux kernel, the following vulnerability has been resolved: mm/migrate: fix shmem xarray update during migration A shmem folio can be either in page cache or in swap cache, but not at the same time. Namely, once it is in swap cache, folio-mapping should be NULL, and the folio is no longer in a shmem mapping. In __folio_migrate_mapping(), to determine the number of xarray entries to update, folio_test_swapbacked() is used, but that conflates shmem in page cache case and shmem in swap cache case. It leads to xarray multi-index entry corruption, since it turns a sibling entry to a normal entry during xas_store() (see [1] for a userspace reproduction). Fix it by only using folio_test_swapcache() to determine whether xarray is storing swap cache entries or not to choose the right number of xarray entries to update. [1] https://lore.kernel.org/linux-mm/Z8idPCkaJW1IChjT@casper.infradead.org/ Note: In __split_huge_page(), folio_test_anon() && folio_test_swapcache() is used to get swap_cache address space, but that ignores the shmem folio in swap cache case. It could lead to NULL pointer dereferencing when a in-swap-cache shmem folio is split at __xa_store(), since !folio_test_anon() is true and folio->mapping is NULL. But fortunately, its caller split_huge_page_to_list_to_order() bails out early with EBUSY when folio->mapping is NULL. So no need to take care of it here.
• CVE-2025-22014 • published on April 8, 2025 In the Linux kernel, the following vulnerability has been resolved: soc: qcom: pdr: Fix the potential deadlock When some client process A call pdr_add_lookup() to add the look up for the service and does schedule locator work, later a process B got a new server packet indicating locator is up and call pdr_locator_new_server() which eventually sets pdr-locator_init_complete to true which process A sees and takes list lock and queries domain list but it will timeout due to deadlock as the response will queued to the same qmi->wq and it is ordered workqueue and process B is not able to complete new server request work due to deadlock on list lock. Fix it by removing the unnecessary list iteration as the list iteration is already being done inside locator work, so avoid it here and just call schedule_work() here. Process A Process B process_scheduled_works() pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PDR: %s get domain list txn wait failed: %d\n", req->service_name, ret); Timeout error log due to deadlock: " PDR: tms/servreg get domain list txn wait failed: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110 " Thanks to Bjorn and Johan for letting me know that this commit also fixes an audio regression when using the in-kernel pd-mapper as that makes it easier to hit this race. [1]
• CVE-2025-22013 • published on April 8, 2025 In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state There are several problems with the way hyp code lazily saves the host's FPSIMD/SVE state, including: * Host SVE being discarded unexpectedly due to inconsistent configuration of TIF_SVE and CPACR_ELx.ZEN. This has been seen to result in QEMU crashes where SVE is used by memmove(), as reported by Eric Auger: https://issues.redhat.com/browse/RHEL-68997 * Host SVE state is discarded *after* modification by ptrace, which was an unintentional ptrace ABI change introduced with lazy discarding of SVE state. * The host FPMR value can be discarded when running a non-protected VM, where FPMR support is not exposed to a VM, and that VM uses FPSIMD/SVE. In these cases the hyp code does not save the host's FPMR before unbinding the host's FPSIMD/SVE/SME state, leaving a stale value in memory. Avoid these by eagerly saving and "flushing" the host's FPSIMD/SVE/SME state when loading a vCPU such that KVM does not need to save any of the host's FPSIMD/SVE/SME state. For clarity, fpsimd_kvm_prepare() is removed and the necessary call to fpsimd_save_and_flush_cpu_state() is placed in kvm_arch_vcpu_load_fp(). As 'fpsimd_state' and 'fpmr_ptr' should not be used, they are set to NULL; all uses of these will be removed in subsequent patches. Historical problems go back at least as far as v5.17, e.g. erroneous assumptions about TIF_SVE being clear in commit: 8383741ab2e773a9 ("KVM: arm64: Get rid of host SVE tracking/saving") ... and so this eager save+flush probably needs to be backported to ALL stable trees.
• CVE-2025-22012 • published on April 8, 2025 In the Linux kernel, the following vulnerability has been resolved: Revert "arm64: dts: qcom: sdm845: Affirm IDR0.CCTW on apps_smmu" There are reports that the pagetable walker cache coherency is not a given across the spectrum of SDM845/850 devices, leading to lock-ups and resets. It works fine on some devices (like the Dragonboard 845c, but not so much on the Lenovo Yoga C630). This unfortunately looks like a fluke in firmware development, where likely somewhere in the vast hypervisor stack, a change to accommodate for this was only introduced after the initial software release (which often serves as a baseline for products). Revert the change to avoid additional guesswork around crashes. This reverts commit 6b31a9744b8726c69bb0af290f8475a368a4b805.
• CVE-2025-22011 • published on April 8, 2025 In the Linux kernel, the following vulnerability has been resolved: ARM: dts: bcm2711: Fix xHCI power-domain During s2idle tests on the Raspberry CM4 the VPU firmware always crashes on xHCI power-domain resume: root@raspberrypi:/sys/power# echo freeze state [ 70.724347] xhci_suspend finished [ 70.727730] xhci_plat_suspend finished [ 70.755624] bcm2835-power bcm2835-power: Power grafx off [ 70.761127] USB: Set power to 0 [ 74.653040] USB: Failed to set power to 1 (-110) This seems to be caused because of the mixed usage of raspberrypi-power and bcm2835-power at the same time. So avoid the usage of the VPU firmware power-domain driver, which prevents the VPU crash.
• CVE-2025-22010 • published on April 8, 2025 In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix soft lockup during bt pages loop Driver runs a for-loop when allocating bt pages and mapping them with buffer pages. When a large buffer (e.g. MR over 100GB) is being allocated, it may require a considerable loop count. This will lead to soft lockup: watchdog: BUG: soft lockup - CPU#27 stuck for 22s! ... Call trace: hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2] hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2] hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2] alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2] hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x118/0x290 watchdog: BUG: soft lockup - CPU#35 stuck for 23s! ... Call trace: hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2] mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2] hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2] alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2] hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x120/0x2bc Add a cond_resched() to fix soft lockup during these loops. In order not to affect the allocation performance of normal-size buffer, set the loop count of a 100GB MR as the threshold to call cond_resched().