Total
289036 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-22013 | 2025-04-08 | N/A | ||
| 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 | 2025-04-08 | N/A | ||
| 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 | 2025-04-08 | N/A | ||
| 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 | 2025-04-08 | N/A | ||
| 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(). | ||||
| CVE-2025-22009 | 2025-04-08 | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: regulator: dummy: force synchronous probing Sometimes I get a NULL pointer dereference at boot time in kobject_get() with the following call stack: anatop_regulator_probe() devm_regulator_register() regulator_register() regulator_resolve_supply() kobject_get() By placing some extra BUG_ON() statements I could verify that this is raised because probing of the 'dummy' regulator driver is not completed ('dummy_regulator_rdev' is still NULL). In the JTAG debugger I can see that dummy_regulator_probe() and anatop_regulator_probe() can be run by different kernel threads (kworker/u4:*). I haven't further investigated whether this can be changed or if there are other possibilities to force synchronization between these two probe routines. On the other hand I don't expect much boot time penalty by probing the 'dummy' regulator synchronously. | ||||
| CVE-2025-22008 | 2025-04-08 | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: regulator: check that dummy regulator has been probed before using it Due to asynchronous driver probing there is a chance that the dummy regulator hasn't already been probed when first accessing it. | ||||
| CVE-2024-56830 | 2025-04-08 | 5.4 Medium | ||
| The Net::EasyTCP package 0.15 through 0.26 for Perl uses Perl's builtin rand() if no strong randomization module is present. | ||||
| CVE-2024-54092 | 2025-04-08 | 9.8 Critical | ||
| A vulnerability has been identified in Industrial Edge Device Kit - arm64 V1.17 (All versions), Industrial Edge Device Kit - arm64 V1.18 (All versions), Industrial Edge Device Kit - arm64 V1.19 (All versions), Industrial Edge Device Kit - arm64 V1.20 (All versions < V1.20.2-1), Industrial Edge Device Kit - arm64 V1.21 (All versions < V1.21.1-1), Industrial Edge Device Kit - x86-64 V1.17 (All versions), Industrial Edge Device Kit - x86-64 V1.18 (All versions), Industrial Edge Device Kit - x86-64 V1.19 (All versions), Industrial Edge Device Kit - x86-64 V1.20 (All versions < V1.20.2-1), Industrial Edge Device Kit - x86-64 V1.21 (All versions < V1.21.1-1), Industrial Edge Own Device (IEOD) (All versions < V1.21.1-1-a), Industrial Edge Virtual Device (All versions < V1.21.1-1-a), SCALANCE LPE9413 (6GK5998-3GS01-2AC2) (All versions), SIMATIC IPC BX-39A Industrial Edge Device (All versions < V3.0), SIMATIC IPC BX-59A Industrial Edge Device (All versions < V3.0), SIMATIC IPC127E Industrial Edge Device (All versions < V3.0), SIMATIC IPC227E Industrial Edge Device (All versions < V3.0), SIMATIC IPC427E Industrial Edge Device (All versions < V3.0), SIMATIC IPC847E Industrial Edge Device (All versions < V3.0). Affected devices do not properly enforce user authentication on specific API endpoints when identity federation is used. This could facilitate an unauthenticated remote attacker to circumvent authentication and impersonate a legitimate user. Successful exploitation requires that identity federation is currently or has previously been used and the attacker has learned the identity of a legitimate user. | ||||
| CVE-2024-54091 | 2025-04-08 | 7.8 High | ||
| A vulnerability has been identified in Solid Edge SE2024 (All versions < V224.0 Update 12), Solid Edge SE2025 (All versions < V225.0 Update 3). The affected application contains an out of bounds write past the end of an allocated buffer while parsing X_T data or a specially crafted file in X_T format. This could allow an attacker to execute code in the context of the current process. | ||||
| CVE-2024-54015 | 2025-04-08 | 7.5 High | ||
| A vulnerability has been identified in SIPROTEC 5 6MD84 (CP300) (All versions < V9.90), SIPROTEC 5 6MD85 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 6MD86 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 6MD89 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 6MU85 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7KE85 (CP300) (All versions >= V8.80), SIPROTEC 5 7SA82 (CP150) (All versions < V9.90), SIPROTEC 5 7SA86 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7SA87 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7SD82 (CP150) (All versions < V9.90), SIPROTEC 5 7SD86 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7SD87 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7SJ81 (CP150) (All versions < V9.90), SIPROTEC 5 7SJ82 (CP150) (All versions < V9.90), SIPROTEC 5 7SJ85 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7SJ86 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7SK82 (CP150) (All versions < V9.90), SIPROTEC 5 7SK85 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7SL82 (CP150) (All versions < V9.90), SIPROTEC 5 7SL86 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7SL87 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7SS85 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7ST85 (CP300) (All versions >= V8.80 < V9.68), SIPROTEC 5 7ST86 (CP300) (All versions), SIPROTEC 5 7SX82 (CP150) (All versions < V9.90), SIPROTEC 5 7SX85 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7SY82 (CP150) (All versions < V9.90), SIPROTEC 5 7UM85 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7UT82 (CP150) (All versions < V9.90), SIPROTEC 5 7UT85 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7UT86 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7UT87 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7VE85 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7VK87 (CP300) (All versions >= V8.80 < V9.90), SIPROTEC 5 7VU85 (CP300) (All versions < V9.90), SIPROTEC 5 Communication Module ETH-BA-2EL (Rev.2) (All versions < V9.90), SIPROTEC 5 Communication Module ETH-BB-2FO (Rev. 2) (All versions < V9.90), SIPROTEC 5 Communication Module ETH-BD-2FO (All versions >= V8.80 < V9.90), SIPROTEC 5 Compact 7SX800 (CP050) (All versions >= V9.50 < V9.90). Affected devices do not properly validate SNMP GET requests. This could allow an unauthenticated, remote attacker to retrieve sensitive information of the affected devices with SNMPv2 GET requests using default credentials. | ||||
| CVE-2024-41796 | 2025-04-08 | 6.5 Medium | ||
| A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices allows to change the login password without knowing the current password. In combination with a prepared CSRF attack (CVE-2024-41795) an unauthenticated attacker could be able to set the password to an attacker-controlled value. | ||||
| CVE-2024-41795 | 2025-04-08 | 6.5 Medium | ||
| 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 | 2025-04-08 | 10 Critical | ||
| 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 | 2025-04-08 | 8.6 High | ||
| 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-2024-41792 | 2025-04-08 | 8.6 High | ||
| 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-2024-41791 | 2025-04-08 | 7.3 High | ||
| 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 | 2025-04-08 | 9.1 Critical | ||
| 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 | 2025-04-08 | 9.1 Critical | ||
| 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 | 2025-04-08 | 9.1 Critical | ||
| 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-2024-23814 | 2025-04-08 | 5.3 Medium | ||
| The integrated ICMP service of the network stack of affected devices can be forced to exhaust its available memory resources when receiving specially crafted messages targeting IP fragment re-assembly. This could allow an unauthenticated remote attacker to cause a temporary denial of service condition of the ICMP service, other communication services are not affected. Affected devices will resume normal operation after the attack terminates. | ||||