Export limit exceeded: 414025 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Export limit exceeded: 414025 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Search

Search Results (414025 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-83756 1 Microsoft 17 Windows 10 21h2, Windows 10 21h2, Windows 10 22h2 and 14 more 2026-10-23 7.8 High
Use after free in Windows Win32 Kernel Subsystem allows an authorized attacker to elevate privileges locally.
CVE-2026-83777 1 Microsoft 23 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 20 more 2026-10-23 8.8 High
Heap-based buffer overflow in Windows Bluetooth Service allows an unauthorized attacker to elevate privileges over an adjacent network.
CVE-2026-83785 1 Microsoft 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more 2026-10-23 7 High
Use after free in Windows COM+ Event System Service allows an authorized attacker to elevate privileges locally.
CVE-2026-98882 1 Linux 2 Linux, Linux Kernel 2026-10-23 N/A
In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Add range checks for dec_output_info If the driver's dec_output_info contains invalid data the driver can write in invalid memory. Add a range check for that. This fixes this smatch error: drivers/media/platform/chips-media/wave5/wave5-vpuapi.c:588 wave5_vpu_dec_get_output_info() error: buffer overflow 'inst->frame_buf' 64 <= 127
CVE-2026-98897 1 Linux 2 Linux, Linux Kernel 2026-10-23 N/A
In the Linux kernel, the following vulnerability has been resolved: ksmbd: don't hold ci->m_lock while waiting for a lease break ack When a cifs.ko client caches a read-handle (RH) lease via deferred close and a conflicting open arrives, ksmbd breaks the lease and waits for the acknowledgment in wait_for_break_ack() for up to OPLOCK_WAIT_TIME (35s). __smb_break_all_levII_oplock() runs that wait while holding ci->m_lock for read. cifs.ko reacts to a handle-lease break by closing the deferred handle rather than sending a lease break acknowledgment. That close path (close_id_del_oplock() -> opinfo_del()) takes ci->m_lock for write and is exactly what would wake the waiter, but it blocks on the read lock held by the waiting thread. The break is then resolved only by the 35s timeout, so xfstests generic/001 takes ~78s with leases enabled versus ~4s with oplocks only. Collect the target opinfos (each pinned with a reference) while holding ci->m_lock, then break them after releasing it, matching how smb_grant_oplock() already breaks a conflicting lease using only a reference. The reference keeps the opinfo (and its conn and lease) alive across the unlocked window, and a close racing the break is handled by the existing OPLOCK_CLOSING state check. Apply the same fix to the parent lease break paths.
CVE-2026-98908 1 Linux 2 Linux, Linux Kernel 2026-10-23 N/A
In the Linux kernel, the following vulnerability has been resolved: net: microchip: sparx5: clean up PSFP resources on flower setup failure sparx5_tc_flower_psfp_setup() allocates PSFP stream gate, flow meter and stream filter resources before adding VCAP actions. If a later step fails, the resources allocated earlier in the function are not unwound. Add error paths to release the stream filter, flow meter and stream gate when setup fails after they have been acquired. Also make sparx5_psfp_fm_add() return the acquired flow-meter id before the existing-flow-meter early return. When an existing flow meter is reused, sparx5_psfp_fm_get() increments its pool reference count, but the caller previously kept psfp_fmid as 0. If a later setup step failed, the error path could try to delete flow-meter id 0 instead of the reused flow meter, leaving the incremented reference behind.
CVE-2026-98916 1 Linux 2 Linux, Linux Kernel 2026-10-23 N/A
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: check link is beaconing for color change When trying to do a color change, validate that the link is beaconing first, to avoid calling the driver with an invalid link.
CVE-2026-98920 1 Linux 2 Linux, Linux Kernel 2026-10-23 N/A
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing alloc tagging of direct mempool allocations Commit 1d78d56c43ef ("netfs: Fix folio_queue ENOMEM in writeback by adding a mempool") added a mempool for the folio_queues and made the request, subrequest and folio_queue allocations distinguish between writeback and everything else. Writeback is part of memory reclaim and must not fail due to ENOMEM, so it allocates under GFP_NOFS through mempool_alloc(), which may dip into the pool's reserve and, if that runs empty, wait for elements to be returned. The GFP_KERNEL paths, which can return -ENOMEM to their callers, invoke the pool's ->alloc() callback directly instead. The direct call, however, skips the alloc_hooks() wrapper that the mempool_alloc() macro provides. The pool callbacks, mempool_alloc_slab() and mempool_kmalloc(), call kmem_cache_alloc_noprof() and kmalloc_noprof() and rely on current->alloc_tag having been set by the caller. With CONFIG_MEM_ALLOC_PROFILING_DEBUG=y this leads to current->alloc_tag not set WARNING: ./include/linux/alloc_tag.h:161 at __alloc_tagging_slab_alloc_hook alloc_tag was not set WARNING: ./include/linux/alloc_tag.h:166 at __alloc_tagging_slab_free_hook at allocation and free time respectively, as reported when reading files on a CIFS mount. The allocations are also missing from /proc/allocinfo. Wrap the direct ->alloc() invocations in alloc_hooks() with a new mempool_alloc_noreserve() helper in include/linux/mempool.h, next to the other alloc_hooks()-wrapped macros such as mempool_alloc(). The GFP_KERNEL paths keep their failable allocation semantics, they just get tagged now.
CVE-2026-98937 1 Linux 2 Linux, Linux Kernel 2026-10-23 N/A
In the Linux kernel, the following vulnerability has been resolved: perf/core: Check kernel access when kernel callchains are requested perf_event_open() currently gates perf_allow_kernel() only on !attr.exclude_kernel. However, users can still request kernel callchain collection with attr.exclude_callchain_kernel == 0 even when attr.exclude_kernel == 1. That still requires kernel profiling privilege, but the existing check does not enforce it. Update the permission check to call perf_allow_kernel() when either kernel sampling is requested or kernel callchains are requested. This keeps permission checks aligned with requested data and prevents unprivileged use of kernel callchain capture.
CVE-2026-110804 1 Devolutions 2 Devolutions Server, Server 2026-10-23 4.3 Medium
Improperly controlled modification of JIT elevation settings in PAM checkout in Devolutions Server 2026.3.8.0 and earlier allows an authenticated user with PAM checkout access to delete arbitrary Active Directory groups or retain elevated privileges via client-supplied JIT elevation settings in a checkout update request.
CVE-2026-110805 1 Devolutions 2 Devolutions Server, Server 2026-10-23 2.6 Low
Server-side request forgery in PingOne groups endpoint in Devolutions Server 2026.3.8.0 and earlier allows an authenticated low-privileged user to exfiltrate the stored PingOne application secret via an attacker-controlled PingOne configuration in the request parameter.
CVE-2026-110806 1 Devolutions 2 Devolutions Server, Server 2026-10-23 6.5 Medium
Incorrect authorization in add-on properties in Devolutions Server 2026.3.8.0 and earlier allows an authenticated user with only View permission to obtain add-on passwords via the unredacted add-on properties returned in connection data.
CVE-2026-113145 1 Google 2 Android, Chrome 2026-10-23 8.8 High
Memory corruption in Messages in Google Chrome on on Android prior to 156.0.8078.47 allowed a remote attacker to potentially execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Low)
CVE-2026-113156 1 Google 2 Android, Chrome 2026-10-23 8.8 High
Use after free in Messages in Google Chrome on on Android prior to 156.0.8078.47 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Low)
CVE-2026-113157 2 Google, Microsoft 2 Chrome, Windows 2026-10-23 6.5 Medium
Information leak in ANGLE in Google Chrome on on Windows prior to 156.0.8078.47 allowed a remote attacker to leak sensitive information via a crafted HTML page. (Chromium security severity: Medium)
CVE-2026-113163 1 Google 2 Android, Chrome 2026-10-23 8.8 High
Use after free in WebGL in Google Chrome on on Android prior to 156.0.8078.47 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High)
CVE-2026-113164 1 Google 2 Android, Chrome 2026-10-23 8.8 High
Memory corruption in Voice in Google Chrome on on Android prior to 156.0.8078.47 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium)
CVE-2026-110287 1 Devolutions 2 Devolutions Server, Server 2026-10-23 4.3 Medium
Improper access control in asset contact password in Devolutions Server 2026.3.8.0 and earlier allows an authenticated user with general Edit but without Edit asset permission to modify the asset contact password via a crafted direct request to the partial-save endpoint.
CVE-2026-98765 1 Linux 1 Linux Kernel 2026-10-23 4.1 Medium
In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix wait for outstanding request completions The dummy-hcd driver emulates synchronize_irq() by waiting until its private callback_usage counter drops to 0 (with the private lock not held). This counter is incremented whenever a gadget driver callback occurs (which requires the private lock to be dropped), but not when a request completion handler is called. This is an oversight. Request completion is triggered by timer interrupts (emulating device IRQs in a real UDC), and the interrupt handlers are supposed to have completed when the synchronize_irq() emulation routine returns -- they aren't supposed to be in the middle of a completion callback. If this happens it can lead to a gadget driver's unbind routine running before all outstanding request completions have finished, maybe even allowing the gadget driver's module to be unloaded while a completion handler is still running. Fix the oversight by incrementing the callback_usage value across request completion callbacks.
CVE-2026-98766 1 Linux 1 Linux Kernel 2026-10-23 4.1 Medium
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed-vhub: cancel wake work on device removal wake_work is armed from the gadget .wakeup callback to resume suspended downstream ports, and it is never cancelled in ast_vhub_remove(), so a work item queued before or during removal can run after devm has freed vhub and its ports, a use-after-free. Cancelling the work alone is not sufficient: usb_gadget_wakeup() takes no lock and the unbind path never clears wakeup_en, so a remote-wakeup request in flight on another CPU can re-arm the work after the cancel and before vhub is freed. ast_vhub_del_dev() already clears d->registered under vhub->lock before unregistering the gadget. Refuse the wakeup in ast_vhub_udc_wakeup() once d->registered is clear: the check and the schedule_work() are then atomic against the unbind, so a wakeup that passed before the flag was cleared is drained by the cancel_work_sync() after the del_dev loop, and one that arrives later returns without arming. Also move INIT_WORK() to the top of ast_vhub_probe(), since the probe error path reuses ast_vhub_remove() and would otherwise cancel a never-initialized work item. This issue was found by an in-house static analysis tool.