Total
34065 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-43820 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-09-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: dm-raid: Fix WARN_ON_ONCE check for sync_thread in raid_resume rm-raid devices will occasionally trigger the following warning when being resumed after a table load because DM_RECOVERY_RUNNING is set: WARNING: CPU: 7 PID: 5660 at drivers/md/dm-raid.c:4105 raid_resume+0xee/0x100 [dm_raid] The failing check is: WARN_ON_ONCE(test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)); This check is designed to make sure that the sync thread isn't registered, but md_check_recovery can set MD_RECOVERY_RUNNING without the sync_thread ever getting registered. Instead of checking if MD_RECOVERY_RUNNING is set, check if sync_thread is non-NULL. | ||||
| CVE-2024-22316 | 1 Ibm | 1 Sterling File Gateway | 2025-09-29 | 4.3 Medium |
| IBM Sterling File Gateway 6.0.0.0 through 6.1.2.5 and 6.2.0.0 through 6.2.0.1 could allow an authenticated user to perform unauthorized actions to another user's data due to improper access controls. | ||||
| CVE-2023-47489 | 1 Combodo | 1 Itop | 2025-09-29 | 7.8 High |
| CSV injection in export as csv in Combodo iTop v.3.1.0-2-11973 allows a local attacker to execute arbitrary code via a crafted script to the export-v2.php and ajax.render.php components. | ||||
| CVE-2025-10868 | 1 Gitlab | 1 Gitlab | 2025-09-29 | 3.5 Low |
| An issue has been discovered in GitLab CE/EE affecting all versions from 17.4 before 18.2.7, 18.3 before 18.3.3, and 18.4 before 18.4.1 where certain string conversion methods exhibit performance degradation with large inputs. | ||||
| CVE-2024-56436 | 1 Huawei | 1 Harmonyos | 2025-09-27 | 5.5 Medium |
| Cross-process screen stack vulnerability in the UIExtension module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2024-56435 | 1 Huawei | 1 Harmonyos | 2025-09-27 | 6.2 Medium |
| Cross-process screen stack vulnerability in the UIExtension module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2024-56136 | 1 Zulip | 2 Zulip, Zulip Server | 2025-09-27 | 5.3 Medium |
| Zulip server provides an open-source team chat that helps teams stay productive and focused. Zulip Server 7.0 and above are vulnerable to an information disclose attack, where, if a Zulip server is hosting multiple organizations, an unauthenticated user can make a request and determine if an email address is in use by a user. Zulip Server 9.4 resolves the issue, as does the `main` branch of Zulip Server. Users are advised to upgrade. There are no known workarounds for this issue. | ||||
| CVE-2023-52881 | 2 Linux, Redhat | 6 Linux Kernel, Enterprise Linux, Rhel Aus and 3 more | 2025-09-27 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: tcp: do not accept ACK of bytes we never sent This patch is based on a detailed report and ideas from Yepeng Pan and Christian Rossow. ACK seq validation is currently following RFC 5961 5.2 guidelines: The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return". The "ignored" above implies that the processing of the incoming data segment continues, which means the ACK value is treated as acceptable. This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs that are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through. This can be refined for new (and possibly spoofed) flows, by not accepting ACK for bytes that were never sent. This greatly improves TCP security at a little cost. I added a Fixes: tag to make sure this patch will reach stable trees, even if the 'blamed' patch was adhering to the RFC. tp->bytes_acked was added in linux-4.2 Following packetdrill test (courtesy of Yepeng Pan) shows the issue at hand: 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1024) = 0 // ---------------- Handshake ------------------- // // when window scale is set to 14 the window size can be extended to // 65535 * (2^14) = 1073725440. Linux would accept an ACK packet // with ack number in (Server_ISN+1-1073725440. Server_ISN+1) // ,though this ack number acknowledges some data never // sent by the server. +0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14> +0 > S. 0:0(0) ack 1 <...> +0 < . 1:1(0) ack 1 win 65535 +0 accept(3, ..., ...) = 4 // For the established connection, we send an ACK packet, // the ack packet uses ack number 1 - 1073725300 + 2^32, // where 2^32 is used to wrap around. // Note: we used 1073725300 instead of 1073725440 to avoid possible // edge cases. // 1 - 1073725300 + 2^32 = 3221241997 // Oops, old kernels happily accept this packet. +0 < . 1:1001(1000) ack 3221241997 win 65535 // After the kernel fix the following will be replaced by a challenge ACK, // and prior malicious frame would be dropped. +0 > . 1:1(0) ack 1001 | ||||
| CVE-2024-37313 | 1 Nextcloud | 2 Nextcloud Server, Server | 2025-09-26 | 7.3 High |
| Nextcloud server is a self hosted personal cloud system. Under some circumstance it was possible to bypass the second factor of 2FA after successfully providing the user credentials. It is recommended that the Nextcloud Server is upgraded to 26.0.13, 27.1.8 or 28.0.4 and Nextcloud Enterprise Server is upgraded to 21.0.9.17, 22.2.10.22, 23.0.12.17, 24.0.12.13, 25.0.13.8, 26.0.13, 27.1.8 or 28.0.4. | ||||
| CVE-2022-48664 | 1 Linux | 2 Linux, Linux Kernel | 2025-09-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: fix hang during unmount when stopping a space reclaim worker Often when running generic/562 from fstests we can hang during unmount, resulting in a trace like this: Sep 07 11:52:00 debian9 unknown: run fstests generic/562 at 2022-09-07 11:52:00 Sep 07 11:55:32 debian9 kernel: INFO: task umount:49438 blocked for more than 120 seconds. Sep 07 11:55:32 debian9 kernel: Not tainted 6.0.0-rc2-btrfs-next-122 #1 Sep 07 11:55:32 debian9 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Sep 07 11:55:32 debian9 kernel: task:umount state:D stack: 0 pid:49438 ppid: 25683 flags:0x00004000 Sep 07 11:55:32 debian9 kernel: Call Trace: Sep 07 11:55:32 debian9 kernel: <TASK> Sep 07 11:55:32 debian9 kernel: __schedule+0x3c8/0xec0 Sep 07 11:55:32 debian9 kernel: ? rcu_read_lock_sched_held+0x12/0x70 Sep 07 11:55:32 debian9 kernel: schedule+0x5d/0xf0 Sep 07 11:55:32 debian9 kernel: schedule_timeout+0xf1/0x130 Sep 07 11:55:32 debian9 kernel: ? lock_release+0x224/0x4a0 Sep 07 11:55:32 debian9 kernel: ? lock_acquired+0x1a0/0x420 Sep 07 11:55:32 debian9 kernel: ? trace_hardirqs_on+0x2c/0xd0 Sep 07 11:55:32 debian9 kernel: __wait_for_common+0xac/0x200 Sep 07 11:55:32 debian9 kernel: ? usleep_range_state+0xb0/0xb0 Sep 07 11:55:32 debian9 kernel: __flush_work+0x26d/0x530 Sep 07 11:55:32 debian9 kernel: ? flush_workqueue_prep_pwqs+0x140/0x140 Sep 07 11:55:32 debian9 kernel: ? trace_clock_local+0xc/0x30 Sep 07 11:55:32 debian9 kernel: __cancel_work_timer+0x11f/0x1b0 Sep 07 11:55:32 debian9 kernel: ? close_ctree+0x12b/0x5b3 [btrfs] Sep 07 11:55:32 debian9 kernel: ? __trace_bputs+0x10b/0x170 Sep 07 11:55:32 debian9 kernel: close_ctree+0x152/0x5b3 [btrfs] Sep 07 11:55:32 debian9 kernel: ? evict_inodes+0x166/0x1c0 Sep 07 11:55:32 debian9 kernel: generic_shutdown_super+0x71/0x120 Sep 07 11:55:32 debian9 kernel: kill_anon_super+0x14/0x30 Sep 07 11:55:32 debian9 kernel: btrfs_kill_super+0x12/0x20 [btrfs] Sep 07 11:55:32 debian9 kernel: deactivate_locked_super+0x2e/0xa0 Sep 07 11:55:32 debian9 kernel: cleanup_mnt+0x100/0x160 Sep 07 11:55:32 debian9 kernel: task_work_run+0x59/0xa0 Sep 07 11:55:32 debian9 kernel: exit_to_user_mode_prepare+0x1a6/0x1b0 Sep 07 11:55:32 debian9 kernel: syscall_exit_to_user_mode+0x16/0x40 Sep 07 11:55:32 debian9 kernel: do_syscall_64+0x48/0x90 Sep 07 11:55:32 debian9 kernel: entry_SYSCALL_64_after_hwframe+0x63/0xcd Sep 07 11:55:32 debian9 kernel: RIP: 0033:0x7fcde59a57a7 Sep 07 11:55:32 debian9 kernel: RSP: 002b:00007ffe914217c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 Sep 07 11:55:32 debian9 kernel: RAX: 0000000000000000 RBX: 00007fcde5ae8264 RCX: 00007fcde59a57a7 Sep 07 11:55:32 debian9 kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000055b57556cdd0 Sep 07 11:55:32 debian9 kernel: RBP: 000055b57556cba0 R08: 0000000000000000 R09: 00007ffe91420570 Sep 07 11:55:32 debian9 kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 Sep 07 11:55:32 debian9 kernel: R13: 000055b57556cdd0 R14: 000055b57556ccb8 R15: 0000000000000000 Sep 07 11:55:32 debian9 kernel: </TASK> What happens is the following: 1) The cleaner kthread tries to start a transaction to delete an unused block group, but the metadata reservation can not be satisfied right away, so a reservation ticket is created and it starts the async metadata reclaim task (fs_info->async_reclaim_work); 2) Writeback for all the filler inodes with an i_size of 2K starts (generic/562 creates a lot of 2K files with the goal of filling metadata space). We try to create an inline extent for them, but we fail when trying to insert the inline extent with -ENOSPC (at cow_file_range_inline()) - since this is not critical, we fallback to non-inline mode (back to cow_file_range()), reserve extents ---truncated--- | ||||
| CVE-2024-2431 | 2 Palo Alto Networks, Paloaltonetworks | 2 Globalprotect App, Globalprotect | 2025-09-26 | 5.5 Medium |
| An issue in the Palo Alto Networks GlobalProtect app enables a non-privileged user to disable the GlobalProtect app in configurations that allow a user to disable GlobalProtect with a passcode. | ||||
| CVE-2024-2432 | 2 Palo Alto Networks, Paloaltonetworks | 2 Globalprotect App, Globalprotect | 2025-09-26 | 4.5 Medium |
| A privilege escalation (PE) vulnerability in the Palo Alto Networks GlobalProtect app on Windows devices enables a local user to execute programs with elevated privileges. However, execution requires that the local user is able to successfully exploit a race condition. | ||||
| CVE-2024-57955 | 1 Huawei | 1 Harmonyos | 2025-09-26 | 6.1 Medium |
| Arbitrary write vulnerability in the Gallery module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2024-57954 | 1 Huawei | 1 Harmonyos | 2025-09-26 | 6.2 Medium |
| Permission verification vulnerability in the media library module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2024-56438 | 1 Huawei | 2 Emui, Harmonyos | 2025-09-26 | 6 Medium |
| Vulnerability of improper memory address protection in the HUKS module Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2025-46593 | 1 Huawei | 1 Harmonyos | 2025-09-26 | 5.1 Medium |
| Process residence vulnerability in abnormal scenarios in the print module Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2025-46589 | 1 Huawei | 1 Harmonyos | 2025-09-26 | 4.4 Medium |
| Vulnerability of unauthorized access in the app lock module Impact: Successful exploitation of this vulnerability will affect integrity and confidentiality. | ||||
| CVE-2025-46588 | 1 Huawei | 1 Harmonyos | 2025-09-26 | 4.4 Medium |
| Vulnerability of unauthorized access in the app lock module Impact: Successful exploitation of this vulnerability will affect integrity and confidentiality. | ||||
| CVE-2025-31171 | 1 Huawei | 1 Harmonyos | 2025-09-26 | 6.8 Medium |
| File read permission bypass vulnerability in the kernel file system module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2025-2713 | 1 Google | 1 Gvisor | 2025-09-26 | 7.8 High |
| Google gVisor's runsc component exhibited a local privilege escalation vulnerability due to incorrect handling of file access permissions, which allowed unprivileged users to access restricted files. This occurred because the process initially ran with root-like permissions until the first fork. | ||||