Total
12677 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-12275 | 2 Azure-access, Azure Access Technology | 6 Blu-ic2, Blu-ic2 Firmware, Blu-ic4 and 3 more | 2025-11-07 | 9.8 Critical |
| Mail Configuration File Manipulation + Command Execution.This issue affects BLU-IC2: through 1.19.5; BLU-IC4: through 1.19.5. | ||||
| CVE-2024-8445 | 1 Redhat | 3 Directory Server, Enterprise Linux, Rhel Els | 2025-11-06 | 5.7 Medium |
| The fix for CVE-2024-2199 in 389-ds-base was insufficient to cover all scenarios. In certain product versions, an authenticated user may cause a server crash while modifying `userPassword` using malformed input. | ||||
| CVE-2024-2199 | 1 Redhat | 4 Directory Server, Directory Server E4s, Enterprise Linux and 1 more | 2025-11-06 | 5.7 Medium |
| A denial of service vulnerability was found in 389-ds-base ldap server. This issue may allow an authenticated user to cause a server crash while modifying `userPassword` using malformed input. | ||||
| CVE-2024-1481 | 1 Redhat | 1 Enterprise Linux | 2025-11-06 | 5.3 Medium |
| A flaw was found in FreeIPA. This issue may allow a remote attacker to craft a HTTP request with parameters that can be interpreted as command arguments to kinit on the FreeIPA server, which can lead to a denial of service. | ||||
| CVE-2022-49767 | 1 Linux | 1 Linux Kernel | 2025-11-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: 9p/trans_fd: always use O_NONBLOCK read/write syzbot is reporting hung task at p9_fd_close() [1], for p9_mux_poll_stop() from p9_conn_destroy() from p9_fd_close() is failing to interrupt already started kernel_read() from p9_fd_read() from p9_read_work() and/or kernel_write() from p9_fd_write() from p9_write_work() requests. Since p9_socket_open() sets O_NONBLOCK flag, p9_mux_poll_stop() does not need to interrupt kernel_read()/kernel_write(). However, since p9_fd_open() does not set O_NONBLOCK flag, but pipe blocks unless signal is pending, p9_mux_poll_stop() needs to interrupt kernel_read()/kernel_write() when the file descriptor refers to a pipe. In other words, pipe file descriptor needs to be handled as if socket file descriptor. We somehow need to interrupt kernel_read()/kernel_write() on pipes. A minimal change, which this patch is doing, is to set O_NONBLOCK flag from p9_fd_open(), for O_NONBLOCK flag does not affect reading/writing of regular files. But this approach changes O_NONBLOCK flag on userspace- supplied file descriptors (which might break userspace programs), and O_NONBLOCK flag could be changed by userspace. It would be possible to set O_NONBLOCK flag every time p9_fd_read()/p9_fd_write() is invoked, but still remains small race window for clearing O_NONBLOCK flag. If we don't want to manipulate O_NONBLOCK flag, we might be able to surround kernel_read()/kernel_write() with set_thread_flag(TIF_SIGPENDING) and recalc_sigpending(). Since p9_read_work()/p9_write_work() works are processed by kernel threads which process global system_wq workqueue, signals could not be delivered from remote threads when p9_mux_poll_stop() from p9_conn_destroy() from p9_fd_close() is called. Therefore, calling set_thread_flag(TIF_SIGPENDING)/recalc_sigpending() every time would be needed if we count on signals for making kernel_read()/kernel_write() non-blocking. [Dominique: add comment at Christian's suggestion] | ||||
| CVE-2025-40325 | 1 Linux | 2 Kernel, Linux Kernel | 2025-11-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: md/raid10: wait barrier before returning discard request with REQ_NOWAIT raid10_handle_discard should wait barrier before returning a discard bio which has REQ_NOWAIT. And there is no need to print warning calltrace if a discard bio has REQ_NOWAIT flag. Quality engineer usually checks dmesg and reports error if dmesg has warning/error calltrace. | ||||
| CVE-2023-39191 | 3 Fedoraproject, Linux, Redhat | 4 Fedora, Linux Kernel, Enterprise Linux and 1 more | 2025-11-06 | 8.2 High |
| An improper input validation flaw was found in the eBPF subsystem in the Linux kernel. The issue occurs due to a lack of proper validation of dynamic pointers within user-supplied eBPF programs prior to executing them. This may allow an attacker with CAP_BPF privileges to escalate privileges and execute arbitrary code in the context of the kernel. | ||||
| CVE-2024-3657 | 1 Redhat | 5 Directory Server, Directory Server E4s, Directory Server Eus and 2 more | 2025-11-06 | 7.5 High |
| A flaw was found in 389-ds-base. A specially-crafted LDAP query can potentially cause a failure on the directory server, leading to a denial of service | ||||
| CVE-2025-37798 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-11-06 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog() After making all ->qlen_notify() callbacks idempotent, now it is safe to remove the check of qlen!=0 from both fq_codel_dequeue() and codel_qdisc_dequeue(). | ||||
| CVE-2025-59596 | 2 Absolute, Microsoft | 2 Secure Access, Windows | 2025-11-06 | N/A |
| CVE-2025-59596 is a denial-of-service vulnerability in Secure Access Windows client versions 12.0 to 14.10 that is addressed in version 14.12. If a local networking policy is active, attackers on an adjacent network may be able to send a crafted packet and cause the client system to crash. | ||||
| CVE-2025-62507 | 1 Redis | 1 Redis | 2025-11-06 | 8.8 High |
| Redis is an open source, in-memory database that persists on disk. In versions 8.2.0 and above, a user can run the XACKDEL command with multiple ID's and trigger a stack buffer overflow, which may potentially lead to remote code execution. This issue is fixed in version 8.2.3. To workaround this issue without patching the redis-server executable is to prevent users from executing XACKDEL operation. This can be done using ACL to restrict XACKDEL command. | ||||
| CVE-2025-37789 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-11-06 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix nested key length validation in the set() action It's not safe to access nla_len(ovs_key) if the data is smaller than the netlink header. Check that the attribute is OK first. | ||||
| CVE-2025-6558 | 5 Apple, Debian, Google and 2 more | 10 Ipados, Iphone Os, Macos and 7 more | 2025-11-06 | 8.8 High |
| Insufficient validation of untrusted input in ANGLE and GPU in Google Chrome prior to 138.0.7204.157 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2021-4034 | 7 Canonical, Oracle, Polkit Project and 4 more | 37 Ubuntu Linux, Http Server, Zfs Storage Appliance Kit and 34 more | 2025-11-06 | 7.8 High |
| A local privilege escalation vulnerability was found on polkit's pkexec utility. The pkexec application is a setuid tool designed to allow unprivileged users to run commands as privileged users according predefined policies. The current version of pkexec doesn't handle the calling parameters count correctly and ends trying to execute environment variables as commands. An attacker can leverage this by crafting environment variables in such a way it'll induce pkexec to execute arbitrary code. When successfully executed the attack can cause a local privilege escalation given unprivileged users administrative rights on the target machine. | ||||
| CVE-2025-12305 | 1 Quequnlong | 1 Shiyi-blog | 2025-11-05 | 6.3 Medium |
| A vulnerability was found in quequnlong shiyi-blog up to 1.2.1. This impacts an unknown function of the file src/main/java/com/mojian/controller/SysJobController.java of the component Job Handler. The manipulation results in deserialization. The attack can be executed remotely. The exploit has been made public and could be used. | ||||
| CVE-2025-43458 | 1 Apple | 7 Ios, Ipados, Iphone Os and 4 more | 2025-11-05 | 4.3 Medium |
| This issue was addressed through improved state management. This issue is fixed in iOS 18.7.2 and iPadOS 18.7.2. Processing maliciously crafted web content may lead to an unexpected process crash. | ||||
| CVE-2025-43365 | 1 Apple | 3 Ios, Ipados, Iphone Os | 2025-11-05 | 2.8 Low |
| A denial-of-service issue was addressed with improved input validation. This issue is fixed in iOS 18.7.2 and iPadOS 18.7.2. An unprivileged process may be able to terminate a root processes. | ||||
| CVE-2019-18860 | 5 Canonical, Debian, Opensuse and 2 more | 5 Ubuntu Linux, Debian Linux, Leap and 2 more | 2025-11-05 | 6.1 Medium |
| Squid before 4.9, when certain web browsers are used, mishandles HTML in the host (aka hostname) parameter to cachemgr.cgi. | ||||
| CVE-2025-37747 | 1 Linux | 1 Linux Kernel | 2025-11-05 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: perf: Fix hang while freeing sigtrap event Perf can hang while freeing a sigtrap event if a related deferred signal hadn't managed to be sent before the file got closed: perf_event_overflow() task_work_add(perf_pending_task) fput() task_work_add(____fput()) task_work_run() ____fput() perf_release() perf_event_release_kernel() _free_event() perf_pending_task_sync() task_work_cancel() -> FAILED rcuwait_wait_event() Once task_work_run() is running, the list of pending callbacks is removed from the task_struct and from this point on task_work_cancel() can't remove any pending and not yet started work items, hence the task_work_cancel() failure and the hang on rcuwait_wait_event(). Task work could be changed to remove one work at a time, so a work running on the current task can always cancel a pending one, however the wait / wake design is still subject to inverted dependencies when remote targets are involved, as pictured by Oleg: T1 T2 fd = perf_event_open(pid => T2->pid); fd = perf_event_open(pid => T1->pid); close(fd) close(fd) <IRQ> <IRQ> perf_event_overflow() perf_event_overflow() task_work_add(perf_pending_task) task_work_add(perf_pending_task) </IRQ> </IRQ> fput() fput() task_work_add(____fput()) task_work_add(____fput()) task_work_run() task_work_run() ____fput() ____fput() perf_release() perf_release() perf_event_release_kernel() perf_event_release_kernel() _free_event() _free_event() perf_pending_task_sync() perf_pending_task_sync() rcuwait_wait_event() rcuwait_wait_event() Therefore the only option left is to acquire the event reference count upon queueing the perf task work and release it from the task work, just like it was done before 3a5465418f5f ("perf: Fix event leak upon exec and file release") but without the leaks it fixed. Some adjustments are necessary to make it work: * A child event might dereference its parent upon freeing. Care must be taken to release the parent last. * Some places assuming the event doesn't have any reference held and therefore can be freed right away must instead put the reference and let the reference counting to its job. | ||||
| CVE-2025-23162 | 1 Linux | 1 Linux Kernel | 2025-11-05 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Don't try to trigger a full GT reset if VF VFs don't have access to the GDRST(0x941c) register that driver uses to reset a GT. Attempt to trigger a reset using debugfs: $ cat /sys/kernel/debug/dri/0000:00:02.1/gt0/force_reset or due to a hang condition detected by the driver leads to: [ ] xe 0000:00:02.1: [drm] GT0: trying reset from force_reset [xe] [ ] xe 0000:00:02.1: [drm] GT0: reset queued [ ] xe 0000:00:02.1: [drm] GT0: reset started [ ] ------------[ cut here ]------------ [ ] xe 0000:00:02.1: [drm] GT0: VF is trying to write 0x1 to an inaccessible register 0x941c+0x0 [ ] WARNING: CPU: 3 PID: 3069 at drivers/gpu/drm/xe/xe_gt_sriov_vf.c:996 xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] RIP: 0010:xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] Call Trace: [ ] <TASK> [ ] ? show_regs+0x6c/0x80 [ ] ? __warn+0x93/0x1c0 [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? report_bug+0x182/0x1b0 [ ] ? handle_bug+0x6e/0xb0 [ ] ? exc_invalid_op+0x18/0x80 [ ] ? asm_exc_invalid_op+0x1b/0x20 [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? xe_gt_tlb_invalidation_reset+0xef/0x110 [xe] [ ] ? __mutex_unlock_slowpath+0x41/0x2e0 [ ] xe_mmio_write32+0x64/0x150 [xe] [ ] do_gt_reset+0x2f/0xa0 [xe] [ ] gt_reset_worker+0x14e/0x1e0 [xe] [ ] process_one_work+0x21c/0x740 [ ] worker_thread+0x1db/0x3c0 Fix that by sending H2G VF_RESET(0x5507) action instead. | ||||