Total
31444 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2023-52942 | 1 Linux | 1 Linux Kernel | 2025-10-28 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Fix wrong check in update_parent_subparts_cpumask() It was found that the check to see if a partition could use up all the cpus from the parent cpuset in update_parent_subparts_cpumask() was incorrect. As a result, it is possible to leave parent with no effective cpu left even if there are tasks in the parent cpuset. This can lead to system panic as reported in [1]. Fix this probem by updating the check to fail the enabling the partition if parent's effective_cpus is a subset of the child's cpus_allowed. Also record the error code when an error happens in update_prstate() and add a test case where parent partition and child have the same cpu list and parent has task. Enabling partition in the child will fail in this case. [1] https://www.spinics.net/lists/cgroups/msg36254.html | |||||
| CVE-2023-52982 | 1 Linux | 1 Linux Kernel | 2025-10-28 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: fscache: Use wait_on_bit() to wait for the freeing of relinquished volume The freeing of relinquished volume will wake up the pending volume acquisition by using wake_up_bit(), however it is mismatched with wait_var_event() used in fscache_wait_on_volume_collision() and it will never wake up the waiter in the wait-queue because these two functions operate on different wait-queues. According to the implementation in fscache_wait_on_volume_collision(), if the wake-up of pending acquisition is delayed longer than 20 seconds (e.g., due to the delay of on-demand fd closing), the first wait_var_event_timeout() will timeout and the following wait_var_event() will hang forever as shown below: FS-Cache: Potential volume collision new=00000024 old=00000022 ...... INFO: task mount:1148 blocked for more than 122 seconds. Not tainted 6.1.0-rc6+ #1 task:mount state:D stack:0 pid:1148 ppid:1 Call Trace: <TASK> __schedule+0x2f6/0xb80 schedule+0x67/0xe0 fscache_wait_on_volume_collision.cold+0x80/0x82 __fscache_acquire_volume+0x40d/0x4e0 erofs_fscache_register_volume+0x51/0xe0 [erofs] erofs_fscache_register_fs+0x19c/0x240 [erofs] erofs_fc_fill_super+0x746/0xaf0 [erofs] vfs_get_super+0x7d/0x100 get_tree_nodev+0x16/0x20 erofs_fc_get_tree+0x20/0x30 [erofs] vfs_get_tree+0x24/0xb0 path_mount+0x2fa/0xa90 do_mount+0x7c/0xa0 __x64_sys_mount+0x8b/0xe0 do_syscall_64+0x30/0x60 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Considering that wake_up_bit() is more selective, so fix it by using wait_on_bit() instead of wait_var_event() to wait for the freeing of relinquished volume. In addition because waitqueue_active() is used in wake_up_bit() and clear_bit() doesn't imply any memory barrier, use clear_and_wake_up_bit() to add the missing memory barrier between cursor->flags and waitqueue_active(). | |||||
| CVE-2021-4454 | 1 Linux | 1 Linux Kernel | 2025-10-28 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: can: j1939: fix errant WARN_ON_ONCE in j1939_session_deactivate The conclusion "j1939_session_deactivate() should be called with a session ref-count of at least 2" is incorrect. In some concurrent scenarios, j1939_session_deactivate can be called with the session ref-count less than 2. But there is not any problem because it will check the session active state before session putting in j1939_session_deactivate_locked(). Here is the concurrent scenario of the problem reported by syzbot and my reproduction log. cpu0 cpu1 j1939_xtp_rx_eoma j1939_xtp_rx_abort_one j1939_session_get_by_addr [kref == 2] j1939_session_get_by_addr [kref == 3] j1939_session_deactivate [kref == 2] j1939_session_put [kref == 1] j1939_session_completed j1939_session_deactivate WARN_ON_ONCE(kref < 2) ===================================================== WARNING: CPU: 1 PID: 21 at net/can/j1939/transport.c:1088 j1939_session_deactivate+0x5f/0x70 CPU: 1 PID: 21 Comm: ksoftirqd/1 Not tainted 5.14.0-rc7+ #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014 RIP: 0010:j1939_session_deactivate+0x5f/0x70 Call Trace: j1939_session_deactivate_activate_next+0x11/0x28 j1939_xtp_rx_eoma+0x12a/0x180 j1939_tp_recv+0x4a2/0x510 j1939_can_recv+0x226/0x380 can_rcv_filter+0xf8/0x220 can_receive+0x102/0x220 ? process_backlog+0xf0/0x2c0 can_rcv+0x53/0xf0 __netif_receive_skb_one_core+0x67/0x90 ? process_backlog+0x97/0x2c0 __netif_receive_skb+0x22/0x80 | |||||
| CVE-2025-21992 | 1 Linux | 1 Linux Kernel | 2025-10-28 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: HID: ignore non-functional sensor in HP 5MP Camera The HP 5MP Camera (USB ID 0408:5473) reports a HID sensor interface that is not actually implemented. Attempting to access this non-functional sensor via iio_info causes system hangs as runtime PM tries to wake up an unresponsive sensor. [453] hid-sensor-hub 0003:0408:5473.0003: Report latency attributes: ffffffff:ffffffff [453] hid-sensor-hub 0003:0408:5473.0003: common attributes: 5:1, 2:1, 3:1 ffffffff:ffffffff Add this device to the HID ignore list since the sensor interface is non-functional by design and should not be exposed to userspace. | |||||
| CVE-2025-21994 | 1 Linux | 1 Linux Kernel | 2025-10-28 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix incorrect validation for num_aces field of smb_acl parse_dcal() validate num_aces to allocate posix_ace_state_array. if (num_aces > ULONG_MAX / sizeof(struct smb_ace *)) It is an incorrect validation that we can create an array of size ULONG_MAX. smb_acl has ->size field to calculate actual number of aces in request buffer size. Use this to check invalid num_aces. | |||||
| CVE-2025-22008 | 1 Linux | 1 Linux Kernel | 2025-10-28 | N/A | 5.5 MEDIUM |
| 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-2025-22013 | 1 Linux | 1 Linux Kernel | 2025-10-28 | N/A | 5.5 MEDIUM |
| 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-62604 | 1 Metersphere | 1 Metersphere | 2025-10-28 | N/A | 7.5 HIGH |
| MeterSphere is an open source continuous testing platform. Prior to version 2.10.25-lts, a logic flaw allows retrieval of arbitrary user information. This allows an unauthenticated attacker to log in to the system as any user. This issue has been patched in version 2.10.25-lts. | |||||
| CVE-2024-38226 | 1 Microsoft | 3 Office 2019, Office Long Term Servicing Channel, Publisher | 2025-10-28 | N/A | 7.3 HIGH |
| Microsoft Publisher Security Feature Bypass Vulnerability | |||||
| CVE-2025-21059 | 1 Samsung | 1 Health | 2025-10-28 | N/A | 6.2 MEDIUM |
| Improper authorization in Samsung Health prior to version 6.30.5.105 allows local attackers to access data in Samsung Health. | |||||
| CVE-2025-21064 | 1 Samsung | 1 Smart Switch | 2025-10-28 | N/A | 8.8 HIGH |
| Improper authentication in Smart Switch prior to version 3.7.66.6 allows adjacent attackers to access transferring data. | |||||
| CVE-2025-9063 | 1 Rockwellautomation | 1 Factorytalk View | 2025-10-28 | N/A | 9.8 CRITICAL |
| An authentication bypass security issue exists within FactoryTalk View Machine Edition Web Browser ActiveX control. Exploitation of this vulnerability allows unauthorized access to the PanelView Plus 7 Series B, including access to the file system, retrieval of diagnostic information, event logs, and more. | |||||
| CVE-2024-53975 | 1 Mozilla | 1 Firefox | 2025-10-28 | N/A | 5.4 MEDIUM |
| Accessing a non-secure HTTP site that uses a non-existent port may cause the SSL padlock icon in the location URL bar to, misleadingly, appear secure. This vulnerability affects Firefox for iOS < 133. | |||||
| CVE-2024-21413 | 1 Microsoft | 4 365 Apps, Office 2016, Office 2019 and 1 more | 2025-10-28 | N/A | 9.8 CRITICAL |
| Microsoft Outlook Remote Code Execution Vulnerability | |||||
| CVE-2024-21338 | 1 Microsoft | 9 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 6 more | 2025-10-28 | N/A | 7.8 HIGH |
| Windows Kernel Elevation of Privilege Vulnerability | |||||
| CVE-2024-21351 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2025-10-28 | N/A | 7.6 HIGH |
| Windows SmartScreen Security Feature Bypass Vulnerability | |||||
| CVE-2024-21410 | 1 Microsoft | 1 Exchange Server | 2025-10-28 | N/A | 9.8 CRITICAL |
| Microsoft Exchange Server Elevation of Privilege Vulnerability | |||||
| CVE-2024-21412 | 1 Microsoft | 9 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 6 more | 2025-10-28 | N/A | 8.1 HIGH |
| Internet Shortcut Files Security Feature Bypass Vulnerability | |||||
| CVE-2024-26169 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2025-10-28 | N/A | 7.8 HIGH |
| Windows Error Reporting Service Elevation of Privilege Vulnerability | |||||
| CVE-2024-29988 | 1 Microsoft | 9 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 6 more | 2025-10-28 | N/A | 8.8 HIGH |
| SmartScreen Prompt Security Feature Bypass Vulnerability | |||||