Total
33315 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-37762 | 1 Linux | 1 Linux Kernel | 2025-11-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix missed dmabuf unpinning in error path of prepare_fb() Correct error handling in prepare_fb() to fix leaking resources when error happens. | ||||
| CVE-2025-39688 | 1 Linux | 1 Linux Kernel | 2025-11-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: nfsd: allow SC_STATUS_FREEABLE when searching via nfs4_lookup_stateid() The pynfs DELEG8 test fails when run against nfsd. It acquires a delegation and then lets the lease time out. It then tries to use the deleg stateid and expects to see NFS4ERR_DELEG_REVOKED, but it gets bad NFS4ERR_BAD_STATEID instead. When a delegation is revoked, it's initially marked with SC_STATUS_REVOKED, or SC_STATUS_ADMIN_REVOKED and later, it's marked with the SC_STATUS_FREEABLE flag, which denotes that it is waiting for s FREE_STATEID call. nfs4_lookup_stateid() accepts a statusmask that includes the status flags that a found stateid is allowed to have. Currently, that mask never includes SC_STATUS_FREEABLE, which means that revoked delegations are (almost) never found. Add SC_STATUS_FREEABLE to the always-allowed status flags, and remove it from nfsd4_delegreturn() since it's now always implied. | ||||
| CVE-2025-39930 | 1 Linux | 1 Linux Kernel | 2025-11-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: simple-card-utils: Don't use __free(device_node) at graph_util_parse_dai() commit 419d1918105e ("ASoC: simple-card-utils: use __free(device_node) for device node") uses __free(device_node) for dlc->of_node, but we need to keep it while driver is in use. Don't use __free(device_node) in graph_util_parse_dai(). | ||||
| 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-2025-37754 | 1 Linux | 1 Linux Kernel | 2025-11-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/i915/huc: Fix fence not released on early probe errors HuC delayed loading fence, introduced with commit 27536e03271da ("drm/i915/huc: track delayed HuC load with a fence"), is registered with object tracker early on driver probe but unregistered only from driver remove, which is not called on early probe errors. Since its memory is allocated under devres, then released anyway, it may happen to be allocated again to the fence and reused on future driver probes, resulting in kernel warnings that taint the kernel: <4> [309.731371] ------------[ cut here ]------------ <3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915] <4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0 ... <4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G U 6.14.0-CI_DRM_16362-gf0fd77956987+ #1 ... <4> [309.731700] RIP: 0010:debug_print_object+0x93/0xf0 ... <4> [309.731728] Call Trace: <4> [309.731730] <TASK> ... <4> [309.731949] __debug_object_init+0x17b/0x1c0 <4> [309.731957] debug_object_init+0x34/0x50 <4> [309.732126] __i915_sw_fence_init+0x34/0x60 [i915] <4> [309.732256] intel_huc_init_early+0x4b/0x1d0 [i915] <4> [309.732468] intel_uc_init_early+0x61/0x680 [i915] <4> [309.732667] intel_gt_common_init_early+0x105/0x130 [i915] <4> [309.732804] intel_root_gt_init_early+0x63/0x80 [i915] <4> [309.732938] i915_driver_probe+0x1fa/0xeb0 [i915] <4> [309.733075] i915_pci_probe+0xe6/0x220 [i915] <4> [309.733198] local_pci_probe+0x44/0xb0 <4> [309.733203] pci_device_probe+0xf4/0x270 <4> [309.733209] really_probe+0xee/0x3c0 <4> [309.733215] __driver_probe_device+0x8c/0x180 <4> [309.733219] driver_probe_device+0x24/0xd0 <4> [309.733223] __driver_attach+0x10f/0x220 <4> [309.733230] bus_for_each_dev+0x7d/0xe0 <4> [309.733236] driver_attach+0x1e/0x30 <4> [309.733239] bus_add_driver+0x151/0x290 <4> [309.733244] driver_register+0x5e/0x130 <4> [309.733247] __pci_register_driver+0x7d/0x90 <4> [309.733251] i915_pci_register_driver+0x23/0x30 [i915] <4> [309.733413] i915_init+0x34/0x120 [i915] <4> [309.733655] do_one_initcall+0x62/0x3f0 <4> [309.733667] do_init_module+0x97/0x2a0 <4> [309.733671] load_module+0x25ff/0x2890 <4> [309.733688] init_module_from_file+0x97/0xe0 <4> [309.733701] idempotent_init_module+0x118/0x330 <4> [309.733711] __x64_sys_finit_module+0x77/0x100 <4> [309.733715] x64_sys_call+0x1f37/0x2650 <4> [309.733719] do_syscall_64+0x91/0x180 <4> [309.733763] entry_SYSCALL_64_after_hwframe+0x76/0x7e <4> [309.733792] </TASK> ... <4> [309.733806] ---[ end trace 0000000000000000 ]--- That scenario is most easily reproducible with igt@i915_module_load@reload-with-fault-injection. Fix the issue by moving the cleanup step to driver release path. (cherry picked from commit 795dbde92fe5c6996a02a5b579481de73035e7bf) | ||||
| CVE-2024-52781 | 2 Dcnetworks, Dcnglobal | 12 Dcme-320, Dcme-320-l, Dcme-320-l Firmware and 9 more | 2025-11-06 | 9.8 Critical |
| DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L <=9.3.5.26, and DCME-720 <=9.1.5.11 are vulnerable to Remote Code Execution via /function/system/tool/traceroute.php. | ||||
| CVE-2024-52780 | 2 Dcnetworks, Dcnglobal | 12 Dcme-320, Dcme-320-l, Dcme-320-l Firmware and 9 more | 2025-11-06 | 9.8 Critical |
| DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L <=9.3.5.26, and DCME-720 <=9.1.5.11 are vulnerable to Remote Code Execution via /function/system/basic/mgmt_edit.php. | ||||
| CVE-2024-52779 | 2 Dcnetworks, Dcnglobal | 12 Dcme-320, Dcme-320-l, Dcme-320-l Firmware and 9 more | 2025-11-06 | 9.8 Critical |
| DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L <=9.3.5.26, and DCME-720 <=9.1.5.11 are vulnerable to Remote Code Execution via /function/audit/newstatistics/mon_stat_top10.php. | ||||
| CVE-2024-52778 | 2 Dcnetworks, Dcnglobal | 12 Dcme-320, Dcme-320-l, Dcme-320-l Firmware and 9 more | 2025-11-06 | 9.8 Critical |
| DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L <=9.3.5.26, and DCME-720 <=9.1.5.11 are vulnerable to Remote Code Execution via /function/audit/newstatistics/mon_stat_hist.php. | ||||
| CVE-2024-52777 | 2 Dcnetworks, Dcnglobal | 12 Dcme-320, Dcme-320-l, Dcme-320-l Firmware and 9 more | 2025-11-06 | 9.8 Critical |
| DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L, <=9.3.5.26, and DCME-720 <=9.1.5.11 are vulnerable to Remote Code Execution via /function/system/basic/license_update.php. | ||||
| 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-52782 | 2 Dcnetworks, Dcnglobal | 12 Dcme-320, Dcme-320-l, Dcme-320-l Firmware and 9 more | 2025-11-06 | 9.8 Critical |
| DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L <=9.3.5.26, and DCME-720 <=9.1.5.11 are vulnerable to Remote Code Execution via /function/audit/newstatistics/mon_stat_hist_new.php. | ||||
| 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-2348 | 1 Iroadau | 2 Fx2, Fx2 Firmware | 2025-11-06 | 4.3 Medium |
| A vulnerability was found in IROAD Dash Cam FX2 up to 20250308. It has been classified as problematic. Affected is an unknown function of the file /mnt/extsd/event/ of the component HTTP/RTSP. The manipulation leads to information disclosure. The attack needs to be initiated within the local network. The exploit has been disclosed to the public and may be used. | ||||
| CVE-2019-7238 | 1 Sonatype | 1 Nexus Repository Manager | 2025-11-06 | 9.8 Critical |
| Sonatype Nexus Repository Manager before 3.15.0 has Incorrect Access Control. | ||||
| CVE-2025-37790 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-11-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: mctp: Set SOCK_RCU_FREE Bind lookup runs under RCU, so ensure that a socket doesn't go away in the middle of a lookup. | ||||
| CVE-2025-23144 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-11-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: backlight: led_bl: Hold led_access lock when calling led_sysfs_disable() Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ... Indeed, led_sysfs_enable() has to be called with the led_access lock held. Hold the lock when calling led_sysfs_disable(). | ||||
| 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-2019-11634 | 1 Citrix | 2 Receiver, Workspace | 2025-11-06 | 9.8 Critical |
| Citrix Workspace App before 1904 for Windows has Incorrect Access Control. | ||||
| CVE-2019-13272 | 6 Canonical, Debian, Fedoraproject and 3 more | 25 Ubuntu Linux, Debian Linux, Fedora and 22 more | 2025-11-06 | 7.8 High |
| In the Linux kernel before 5.1.17, ptrace_link in kernel/ptrace.c mishandles the recording of the credentials of a process that wants to create a ptrace relationship, which allows local users to obtain root access by leveraging certain scenarios with a parent-child process relationship, where a parent drops privileges and calls execve (potentially allowing control by an attacker). One contributing factor is an object lifetime issue (which can also cause a panic). Another contributing factor is incorrect marking of a ptrace relationship as privileged, which is exploitable through (for example) Polkit's pkexec helper with PTRACE_TRACEME. NOTE: SELinux deny_ptrace might be a usable workaround in some environments. | ||||