Export limit exceeded: 408207 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (408207 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-98391 | 1 Linux | 1 Linux Kernel | 2026-10-14 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe: Guard page-fault worker with runtime PM check During VM teardown, the VM's runtime PM reference is dropped asynchronously, allowing the device to autosuspend while stale page faults belonging to the now-dead VM are still queued. When the page-fault worker later tries to ack one of these, it calls into guc_ct_send_locked() on an already-suspended device, tripping: Assertion `!xe_pm_runtime_suspended(xe)` failed! WARNING at xe_device.c:1267 xe_device_assert_mem_access+0x11c/0x140 [xe] A live VM/exec queue always holds a PM reference while it has outstanding work, so if the device is suspended at ack time, the owning context is already gone and the fault is stale. Take a runtime PM reference across the entire pagefault queue worker to safely deliver acks for torn-down VMs. v3: - Move PM ref to the generic xe_pagefault_queue_work using guard(xe_pm_runtime)(xe) instead of tracking it in the GuC backend(Matt Brost). v2: - Hold PM ref across the entire batch (begin/end) instead of per-ack. This prevents the device from autosuspending mid-batch, which would leave write_only acks written but the end flush skipped, and skip counter++, desyncing the cadence check.(Himal) - Add a comment explaining stale faults.(Himal) (cherry picked from commit fcc2431d2213dc4d04250c4f1ae87d9c3ae0d455) [Rodrigo: Added xe_device struct for compatibility while cherry-picking] | ||||
| CVE-2026-98390 | 1 Linux | 1 Linux Kernel | 2026-10-14 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: x86/amd_node: Avoid divide by zero on virtualized systems On a virtualized system, the number of nodes does not have a relationship to the number of roots. A Xen PVH dom0 can calculate roots_per_node as 0, which crashes with a divide by zero in: if (count++ % roots_per_node) because the underlying topology code on Xen ends up making num_nodes 2 and num_roots 1 and the integer division result is 0. The issue is seen with Xen, but it could affect other systems. Set roots_per_node to 1 in this case. Print a firmware bug when this is performed for non-virtualized systems. [ bp: Massage commit message. ] | ||||
| CVE-2026-98389 | 1 Linux | 1 Linux Kernel | 2026-10-14 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: skip gfx switch_power_profile during GPU reset During resume from GPU reset, the gfx idle work may invoke switch_power_profile before the reset completes. This causes the following assert error because the register access occurs without first releasing the GPU reset semaphore: [ 1576.768935] CR2: 0000559ea133ead0 CR3: 00000002e6c42000 CR4: 0000000000350ef0 [ 1576.768940] Call Trace: [ 1576.768944] <TASK> [ 1576.768953] amdgpu_device_rreg+0x21/0x50 [amdgpu] [ 1576.769158] smu_msg_v1_send_msg+0x1a4/0x6e0 [amdgpu] [ 1576.769437] smu_cmn_send_smc_msg_with_params_ext+0xba/0x120 [amdgpu] [ 1576.769721] smu_cmn_send_smc_msg_with_param+0x33/0x40 [amdgpu] [ 1576.769993] smu_v13_0_0_set_power_profile_mode+0x192/0x2b0 [amdgpu] [ 1576.770267] smu_bump_power_profile_mode+0x5d/0x80 [amdgpu] [ 1576.770538] smu_switch_power_profile+0xa4/0xf0 [amdgpu] [ 1576.770839] amdgpu_dpm_switch_power_profile+0x6f/0x90 [amdgpu] [ 1576.771210] amdgpu_gfx_profile_idle_work_handler+0xe9/0x130 [amdgpu] [ 1576.771460] process_one_work+0x23e/0x6f0 [ 1576.771491] worker_thread+0x1c4/0x380 [ 1576.771506] kthread+0x10c/0x150 [ 1576.771512] ? __pfx_worker_thread+0x10/0x10 [ 1576.771518] ? __pfx_kthread+0x10/0x10 [ 1576.771530] ret_from_fork+0x314/0x390 [ 1576.771537] ? __pfx_kthread+0x10/0x10 [ 1576.771546] ret_from_fork_asm+0x1a/0x30 (cherry picked from commit d93b1ff538ce9750c01e0dd0aa62575579c0fc08) | ||||
| CVE-2026-98388 | 1 Linux | 1 Linux Kernel | 2026-10-14 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: exec: do_close_on_exec() before taking exec_update_lock do_close_on_exec() currently happens while holding the exec_update_lock, which is used in a lot of places that access process state to synchronize access checks. I recently added another such use of exec_update_lock, causing a regression. do_close_on_exec() can block waiting for a reply from a filesystem. That means a hung filesystem can block codepaths that use exec_update_lock; and it also means that a FUSE filesystem which attempts to inspect the calling process can deadlock. To avoid such problems, move do_close_on_exec() before the exec_update_lock is taken, but after the FD table has been copied if necessary. I have looked through all the calls between the old and new position of the do_close_on_exec() call; there seems to be no file descriptor table access in between. | ||||
| CVE-2026-98387 | 1 Linux | 1 Linux Kernel | 2026-10-14 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix skcipher_walk return code handling in aes_s390 The return codes from skcipher_walk_virt() were not properly checked before entering the processing loops in ecb_aes_crypt() and ctr_aes_crypt(). If skcipher_walk_virt() fails, the walk structure may be in an undefined state, and attempting to process data could lead to incorrect behavior or accessing uninitialized memory. Add proper return code checking to ensure correct handling of the walk initialization and walk advance and eventually return to the caller with that return code. | ||||
| CVE-2026-98386 | 1 Linux | 1 Linux Kernel | 2026-10-14 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Use memset_io() to clear QLAFX00 request ring slot For QLAFX00 the request ring is ioremapped device I/O memory (ha->iobase + req_que_off), not DMA-coherent RAM, which is why the rest of the FX00 path accesses it through memcpy_toio() and the wrt_reg_* helpers. __qla2x00_alloc_iocbs() however zeroed the producer slot with a plain memset(). On architectures such as ARM64 a regular memset() may emit unaligned or block-zeroing instructions (e.g. DC ZVA) that are invalid on Device memory, leading to a synchronous external abort. Use memset_io() to clear the slot for QLAFX00, matching the I/O accessors used elsewhere on this ring. Other adapters keep the plain memset() on their DMA-coherent rings. The zero-fill is retained for FX00 because its IOCB builders (e.g. qlafx00_fxdisc_iocb()) copy only part of the entry and rely on the unused tail being pre-zeroed. | ||||
| CVE-2026-12613 | 1 Ministry Of Justice | 1 Uyap Document Editor | 2026-10-14 | 8.8 High |
| Deserialization of untrusted data vulnerability in Ministry of Justice General Directorate of Information Technology UYAP Document Editor on Windows and Linux and Ministry of Justice General Directorate of Information Technology UYAP Document Editor on MacOS allows Object Injection. This issue affects UYAP Document Editor: before 5.4.20; UYAP Document Editor: before 5.4.21. | ||||
| CVE-2026-18390 | 1 Ministry Of Justice | 1 Uyap Document Editor | 2026-10-14 | 7.8 High |
| Improper neutralization of special elements used in an OS command ('OS command injection') vulnerability in Ministry of Justice General Directorate of Information Technology UYAP Document Editor on Windows and Linux and Ministry of Justice General Directorate of Information Technology UYAP Document Editor on iOS allows OS Command Injection. This issue affects UYAP Document Editor: before 5.4.20; UYAP Document Editor: before 5.4.21. | ||||
| CVE-2026-37107 | 2026-10-14 | 9.8 Critical | ||
| An issue in HTMLy v.3.1.1 allows a remote attacker to escalate privileges via the get_feed function in the admin.php component | ||||
| CVE-2026-109667 | 1 Frappe | 1 Erpnext | 2026-10-14 | 8.8 High |
| Frappe ERPNext before 15.111.0 and 16.x before 16.22.0 contains a privilege escalation vulnerability in a record-creation endpoint that takes the record type from the request and inserts the record with permission checks disabled. Any authenticated user, including one holding no operational role, can supply a privileged record type to create privileged accounts and take full control of the site. | ||||
| CVE-2026-109662 | 1 Frappe | 1 Erpnext | 2026-10-14 | 6.1 Medium |
| Frappe ERPNext before 15.112.0 and 16.x before 16.23.0 contains a stored cross-site scripting vulnerability in a public portal form that accepts unauthenticated submissions and stores content later rendered with insufficient neutralisation. Unauthenticated attackers can submit crafted markup that executes in the browser sessions of staff who review the stored record. | ||||
| CVE-2026-109657 | 1 Frappe | 1 Erpnext | 2026-10-14 | 5.4 Medium |
| Frappe ERPNext 16.x before 16.27.0 contains a stored cross-site scripting vulnerability that allows users with edit rights to inject script through a record name rendered without escaping. Attackers can set a malicious record name so the script runs in the browser of any colleague who opens the page. | ||||
| CVE-2026-109652 | 1 Frappe | 1 Erpnext | 2026-10-14 | 8.8 High |
| Frappe ERPNext before 15.119.1 and 16.x before 16.32.0 contains a server-side template injection vulnerability because user-controlled message fields are not validated before template rendering, allowing expressions to run in an unrestricted context. Authenticated attackers holding a common operational role can inject template expressions to read and write arbitrary database data, delete documents, send outbound requests from the server, and send mail from the site. | ||||
| CVE-2026-109647 | 1 Frappe | 1 Erpnext | 2026-10-14 | 6.5 Medium |
| Frappe ERPNext before 15.106.0 and 16.x before 16.16.0 contains an SQL injection vulnerability in multiple endpoints caused by missing input validation. Authenticated attackers can send specially crafted requests to these endpoints to manipulate database queries and extract sensitive information from the ERPNext database. | ||||
| CVE-2026-109642 | 1 Frappe | 1 Erpnext | 2026-10-14 | 4.3 Medium |
| Frappe ERPNext before 15.110.0 and 16.x before 16.21.0 contains a missing authorization vulnerability in which certain endpoints fail to enforce proper authorization checks. Authenticated users can query these endpoints to read data beyond what their assigned role permits. | ||||
| CVE-2026-109637 | 1 Frappe | 1 Erpnext | 2026-10-14 | 6.5 Medium |
| Frappe ERPNext before 16.14.0 contains a missing authorization vulnerability that allows authenticated users to modify master data beyond their permitted role. Attackers can send requests to certain endpoints lacking proper authorization checks to make unauthorized changes to master data records. | ||||
| CVE-2026-109632 | 1 Frappe | 1 Erpnext | 2026-10-14 | 6.5 Medium |
| Frappe ERPNext before 15.121.0 and 16.x before 16.33.0 contains a missing authorization vulnerability in which certain endpoints fail to enforce proper authorization checks. Authenticated users can call these endpoints directly to read data beyond what their assigned role permits. | ||||
| CVE-2026-109627 | 1 Frappe | 1 Erpnext | 2026-10-14 | 6.5 Medium |
| Frappe ERPNext before 15.120.0 and 16.x before 16.33.0 contains a missing authorization vulnerability in which certain endpoints fail to enforce proper permission checks. Authenticated low-privileged users can request these endpoints directly to read financial data beyond what their assigned role permits. | ||||
| CVE-2026-109622 | 1 Frappe | 1 Erpnext | 2026-10-14 | 4.3 Medium |
| Frappe ERPNext before 15.121.0 and 16.x before 16.34.0 contains a missing authorization vulnerability in which certain endpoints fail to enforce proper authorization checks. Authenticated users can send requests to the affected endpoints to modify data beyond their permitted role, compromising data integrity. | ||||
| CVE-2026-109609 | 1 Frappe | 1 Erpnext | 2026-10-14 | 6.5 Medium |
| Frappe ERPNext before 15.119.1 and 16.x before 16.32.0 contains an SQL injection vulnerability in some endpoints that lack input validation. Authenticated attackers with low privileges can send specially crafted requests to these endpoints to inject SQL and extract sensitive information from the ERPNext database. | ||||