Export limit exceeded: 17334 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 17334 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (17334 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-27652 | 1 Printerlogic | 2 Vasion Print, Virtual Appliance | 2025-11-03 | 9.8 Critical |
| Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.862 Application 20.0.2014 allows Server-Side Request Forgery: rfIDEAS V-2023-015. | ||||
| CVE-2025-27651 | 1 Printerlogic | 2 Vasion Print, Virtual Appliance | 2025-11-03 | 9.8 Critical |
| Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.862 Application 20.0.2014 allows Server-Side Request Forgery: Elatec V-2023-014. | ||||
| CVE-2025-27650 | 1 Printerlogic | 2 Vasion Print, Virtual Appliance | 2025-11-03 | 9.8 Critical |
| Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.862 Application 20.0.2014 allows Private Keys in Docker Overlay V-2023-013. | ||||
| CVE-2025-27649 | 1 Printerlogic | 2 Vasion Print, Virtual Appliance | 2025-11-03 | 9.8 Critical |
| Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.893 Application 20.0.2140 allows Incorrect Access Control: PHP V-2023-016. | ||||
| CVE-2025-27648 | 1 Printerlogic | 2 Vasion Print, Virtual Appliance | 2025-11-03 | 9.8 Critical |
| Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.913 Application 20.0.2253 allows Cross Tenant Password Exposure V-2024-003. | ||||
| CVE-2025-27647 | 1 Printerlogic | 2 Vasion Print, Virtual Appliance | 2025-11-03 | 9.8 Critical |
| Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.913 Application 20.0.2253 allows Addition of Partial Admin Users Without Authentication V-2024-002. | ||||
| CVE-2025-27646 | 1 Printerlogic | 2 Vasion Print, Virtual Appliance | 2025-11-03 | 9.8 Critical |
| Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.913 Application 20.0.2253 allows Edit User Account Exposure V-2024-001. | ||||
| CVE-2025-27645 | 1 Printerlogic | 2 Vasion Print, Virtual Appliance | 2025-11-03 | 9.8 Critical |
| Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.933 Application 20.0.2368 allows Insecure Extension Installation by Trusting HTTP Permission Methods on the Server Side V-2024-005. | ||||
| CVE-2025-27644 | 1 Printerlogic | 2 Vasion Print, Virtual Appliance | 2025-11-03 | 7.8 High |
| Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.933 Application 20.0.2368 allows Local Privilege Escalation V-2024-007. | ||||
| CVE-2025-27643 | 1 Printerlogic | 2 Vasion Print, Virtual Appliance | 2025-11-03 | 9.8 Critical |
| Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.933 Application 20.0.2368 allows Hardcoded AWS API Key V-2024-006. | ||||
| CVE-2025-27642 | 1 Printerlogic | 2 Vasion Print, Virtual Appliance | 2025-11-03 | 9.8 Critical |
| Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.933 Application 20.0.2368 allows Unauthenticated Driver Package Editing V-2024-008. | ||||
| CVE-2025-27641 | 1 Printerlogic | 2 Vasion Print, Virtual Appliance | 2025-11-03 | 9.8 Critical |
| Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.951 Application 20.0.2368 allows Unauthenticated APIs for Single-Sign On V-2024-009. | ||||
| CVE-2025-27639 | 1 Printerlogic | 2 Vasion Print, Virtual Appliance | 2025-11-03 | 8.8 High |
| Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.1002 Application 20.0.2614 allows Privilege Escalation V-2024-015. | ||||
| CVE-2025-27638 | 1 Printerlogic | 2 Vasion Print, Virtual Appliance | 2025-11-03 | 9.8 Critical |
| Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.1002 Application 20.0.2614 allows Hardcoded Password V-2024-013. | ||||
| CVE-2025-27637 | 1 Printerlogic | 2 Vasion Print, Virtual Appliance | 2025-11-03 | 6.1 Medium |
| Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.1002 Application 20.0.2614 allows Cross-Site Scripting V-2024-016. | ||||
| CVE-2025-22050 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: usbnet:fix NPE during rx_complete Missing usbnet_going_away Check in Critical Path. The usb_submit_urb function lacks a usbnet_going_away validation, whereas __usbnet_queue_skb includes this check. This inconsistency creates a race condition where: A URB request may succeed, but the corresponding SKB data fails to be queued. Subsequent processes: (e.g., rx_complete → defer_bh → __skb_unlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference (Kernel Panic). | ||||
| CVE-2025-22014 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: soc: qcom: pdr: Fix the potential deadlock When some client process A call pdr_add_lookup() to add the look up for the service and does schedule locator work, later a process B got a new server packet indicating locator is up and call pdr_locator_new_server() which eventually sets pdr->locator_init_complete to true which process A sees and takes list lock and queries domain list but it will timeout due to deadlock as the response will queued to the same qmi->wq and it is ordered workqueue and process B is not able to complete new server request work due to deadlock on list lock. Fix it by removing the unnecessary list iteration as the list iteration is already being done inside locator work, so avoid it here and just call schedule_work() here. Process A Process B process_scheduled_works() pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PDR: %s get domain list txn wait failed: %d\n", req->service_name, ret); Timeout error log due to deadlock: " PDR: tms/servreg get domain list txn wait failed: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110 " Thanks to Bjorn and Johan for letting me know that this commit also fixes an audio regression when using the in-kernel pd-mapper as that makes it easier to hit this race. [1] | ||||
| CVE-2025-22010 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| 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-21999 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: proc: fix UAF in proc_get_inode() Fix race between rmmod and /proc/XXX's inode instantiation. The bug is that pde->proc_ops don't belong to /proc, it belongs to a module, therefore dereferencing it after /proc entry has been registered is a bug unless use_pde/unuse_pde() pair has been used. use_pde/unuse_pde can be avoided (2 atomic ops!) because pde->proc_ops never changes so information necessary for inode instantiation can be saved _before_ proc_register() in PDE itself and used later, avoiding pde->proc_ops->... dereference. rmmod lookup sys_delete_module proc_lookup_de pde_get(de); proc_get_inode(dir->i_sb, de); mod->exit() proc_remove remove_proc_subtree proc_entry_rundown(de); free_module(mod); if (S_ISREG(inode->i_mode)) if (de->proc_ops->proc_read_iter) --> As module is already freed, will trigger UAF BUG: unable to handle page fault for address: fffffbfff80a702b PGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:proc_get_inode+0x302/0x6e0 RSP: 0018:ffff88811c837998 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007 RDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158 RBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20 R10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0 R13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001 FS: 00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> proc_lookup_de+0x11f/0x2e0 __lookup_slow+0x188/0x350 walk_component+0x2ab/0x4f0 path_lookupat+0x120/0x660 filename_lookup+0x1ce/0x560 vfs_statx+0xac/0x150 __do_sys_newstat+0x96/0x110 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e [adobriyan@gmail.com: don't do 2 atomic ops on the common path] | ||||
| CVE-2025-21975 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5: handle errors in mlx5_chains_create_table() In mlx5_chains_create_table(), the return value of mlx5_get_fdb_sub_ns() and mlx5_get_flow_namespace() must be checked to prevent NULL pointer dereferences. If either function fails, the function should log error message with mlx5_core_warn() and return error pointer. | ||||