Export limit exceeded: 416937 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 416937 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (416937 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-85866 | 1 Microsoft | 20 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 17 more | 2026-10-29 | 4.7 Medium |
| Exposure of sensitive system information to an unauthorized control sphere in Windows ALPC allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-99207 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 5.6 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: target: Disable interrupts while holding delayed_cmd_lock target_do_delayed_work() takes dev->delayed_cmd_lock with a plain spin_lock(). It runs from system_percpu_wq, so interrupts stay enabled while the lock is held. Every other acquisition of that lock uses spin_lock_irqsave(): target_handle_task_attr() and transport_complete_ordered_sync() in target_core_transport.c, and target_non_ordered_release() in target_core_device.c. That was safe while every caller of transport_complete_task_attr() ran in process context: target_complete_ok_work() from target_completion_wq, transport_complete_qf() from dev->qf_work_queue, and transport_generic_request_failure() from the submit and execute paths. Since commit 06933066d88a ("scsi: target: Add support for completing commands from backend context") that is no longer true. With complete_type=1 on a fabric that sets direct_compl_supp, target_complete() runs target_complete_ok_work() inline in the backend's completion context, which target_complete_cmd_with_sense() documents as "May be called from interrupt context". For iblock that is the bio end_io. target_complete_ok_work() starts with transport_complete_task_attr(), which takes delayed_cmd_lock in two ways: - Every ORDERED command is put on dev->delayed_cmd_list by target_handle_task_attr() and dispatched from there by target_do_delayed_work(), which marks it SCF_TASK_ORDERED_SYNC. Its completion therefore goes through transport_complete_ordered_sync(). - A SIMPLE command that completes while an ORDERED command is pending drops the last reference to the killed dev->non_ordered, and percpu_ref_put() then runs target_non_ordered_release() in the completing context. Both take the lock and, if commands are waiting, call schedule_work(&dev->delayed_cmd_work), which queues on system_percpu_wq, i.e. on the CPU that took the completion. Further completions for the same queue are typically delivered there too, so one arriving while the work holds the lock spins on it forever. Reaching this needs complete_type=1, which is not the default (vhost-scsi, the only fabric with direct_compl_supp, defaults to TARGET_QUEUE_COMPL), a backend whose I/O completes from interrupt context, and ORDERED commands from the initiator. Linux virtio_scsi guests send only VIRTIO_SCSI_S_SIMPLE and never take the ordered path; any guest that uses the ORDERED task attribute, which vhost-scsi accepts, does. target_do_delayed_work() is a work item and always runs in process context, so spin_lock_irq() is sufficient. Found by inspection; no runtime report. A single ORDERED command goes through both acquisitions, so with CONFIG_PROVE_LOCKING the first one completed through direct completion should produce an inconsistent lock state report on delayed_cmd_lock (hardirq or softirq, depending on where the backend completes). | ||||
| CVE-2026-99208 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Zero OA buffer at allocation ttm_bo_type_kernel BOs are not guaranteed to be zeroed on allocation and may contain data from previously freed pages. Since the OA buffer is mmap'able by userspace, this can expose stale kernel memory contents. Streams opened with DRM_XE_OA_PROPERTY_OA_DISABLED allocate the OA buffer without calling xe_oa_init_oa_buffer(). Zero the buffer at allocation to prevent information disclosure through mmap. The existing zeroing in xe_oa_init_oa_buffer() remains necessary for zero report-id/timestamp detection on enable/re-enable. (cherry picked from commit 126c4c5388f9311a390b9b254a835b0cf0f55331) | ||||
| CVE-2026-99210 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 4.1 Medium |
| In the Linux kernel, the following vulnerability has been resolved: accel/rocket: clear rdev on device init failure rocket_probe() stores the return value from rocket_device_init() in the file-scoped rdev pointer before checking whether it is an error pointer. If rocket_device_init() fails, rdev is left as an ERR_PTR. The rdev pointer is also used as the marker for whether the shared rocket device has already been initialized. A later core probe can therefore see a non-NULL rdev, skip rocket_device_init(), and dereference the error pointer when reading rdev->num_cores. Save the error code and clear rdev before returning from the rocket_device_init() failure path. | ||||
| CVE-2026-93011 | 1 Redhat | 4 Ceph Storage, Enterprise Linux, Openshift and 1 more | 2026-10-29 | 5.3 Medium |
| A flaw was found in dnsmasq. After a reduction of internal domain-name buffer sizes, the DNSSEC validator can write a few bytes past a name buffer when converting names to and from DNS wire format. An attacker who can cause the server to validate a crafted DNSSEC response may overwrite a small amount of adjacent heap metadata. DNSSEC support is not compiled in by default and must also be enabled at runtime. | ||||
| CVE-2026-93006 | 1 Redhat | 4 Ceph Storage, Enterprise Linux, Openshift and 1 more | 2026-10-29 | 6.8 Medium |
| A flaw was found in dnsmasq. The TFTP server can serve the wrong file contents because a recently used transfer cache is not invalidated when a transfer finishes. An attacker on the local network who can request a TFTP file may cause a later client to receive previously cached data instead of the requested file. In PXE network-boot environments this can substitute attacker-chosen boot content for a victim machine. | ||||
| CVE-2026-93010 | 1 Redhat | 4 Ceph Storage, Enterprise Linux, Openshift and 1 more | 2026-10-29 | 4.3 Medium |
| A flaw was found in dnsmasq. When DHCP leasequery is enabled without listing allowed source addresses, the server does not check who sent the query. A host on the local network can request DHCP lease records and learn assigned addresses, MAC addresses, hostnames, and related lease metadata. The feature is off unless an administrator turns it on. | ||||
| CVE-2026-93009 | 1 Redhat | 4 Ceph Storage, Enterprise Linux, Openshift and 1 more | 2026-10-29 | 4.3 Medium |
| A flaw was found in dnsmasq. The DHCPv6 client hostname parser can read one byte past the end of a crafted FQDN option because it checks the next label length before confirming the pointer is still inside the option. An attacker on the local network can trigger this with a single DHCPv6 packet. The extra byte is not returned to the client or logged, and no crash has been demonstrated. | ||||
| CVE-2026-115706 | 1 Elastic | 1 Elastic Cloud Enterprise | 2026-10-29 | 6.8 Medium |
| Authorization Bypass Through User-Controlled Key (CWE-639) in Elastic Cloud Enterprise (ECE) can lead to privilege escalation via Privilege Abuse (CAPEC-122). An attacker who controls any host in an ECE installation can obtain credentials that are reserved for other platform roles. These credentials can give the attacker full control of the ECE control plane and of the deployments that it manages. | ||||
| CVE-2026-115707 | 1 Elastic | 1 Elastic Cloud Enterprise | 2026-10-29 | 6.4 Medium |
| Insertion of Sensitive Information into Externally-Accessible File or Directory (CWE-538) in Elastic Cloud Enterprise (ECE) can lead to privilege escalation via Retrieve Embedded Sensitive Data (CAPEC-37). After the ECE certificate rotation procedure runs, data that it retains contains platform credentials and certificate authority private keys, and lower-privileged platform components can read this data. An attacker who controls any host in the installation can use this data to get full control of the ECE control plane and of the deployments that it manages. | ||||
| CVE-2026-111073 | 1 Apache | 1 Kafka | 2026-10-29 | 6.5 Medium |
| The broker-side PushTelemetry API (KIP-714) validates only the compressed size of a client's metrics payload against telemetry.max.bytes (default 1 MB) before decompressing it. ClientTelemetryUtils.decompress() then decompresses the payload with no limit on the decompressed output size, growing a heap buffer until the compressed input is exhausted. A small, highly compressible payload (for example gzip-compressed zeros) can therefore expand to hundreds of megabytes of broker heap. Impact: An authenticated client can send a PushTelemetry request with a small compressed payload that decompresses to a very large size, consuming broker heap out of proportion to the request size. Repeated or concurrent requests can exhaust the broker heap and cause an OutOfMemoryError, degrading or crashing the broker; a client that targets multiple brokers can affect cluster availability. PushTelemetry is available to any authenticated client and is not gated by an ACL. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.1, or 4.4.0. On affected versions there is no configuration that fully prevents the amplification, because telemetry.max.bytes bounds only the compressed size; lowering telemetry.max.bytes reduces the worst-case decompressed size proportionally and is a partial mitigation. Resolution: - From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: ClientTelemetryUtils.decompress() enforces a maximum decompressed size equal to telemetry.max.bytes (default 1 MB). Decompression reads in bounded chunks and aborts with a TelemetryTooLargeException once the decompressed total exceeds the limit, so an over-large or highly compressible payload is rejected instead of being fully expanded in heap. The decompressed size is therefore bounded by default. | ||||
| CVE-2026-85867 | 1 Microsoft | 27 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 24 more | 2026-10-29 | 7.8 High |
| Heap-based buffer overflow in Windows Remote Access Connection Manager allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-85868 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-29 | 7 High |
| Use after free in Windows Common Log File System Driver allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-85869 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-29 | 7.8 High |
| Heap-based buffer overflow in Microsoft Windows Search Component allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-85870 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-29 | 7 High |
| Heap-based buffer overflow in Windows Common Log File System Driver allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-85871 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-29 | 7.8 High |
| Heap-based buffer overflow in Windows Kernel-Mode Drivers allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-85872 | 1 Microsoft | 23 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 20 more | 2026-10-29 | 7.8 High |
| Use after free in Windows Storage VSP Driver allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-112256 | 1 Opentext | 1 Advanced Authentication Server | 2026-10-29 | N/A |
| Acceptance of extraneous untrusted data with trusted data vulnerability in OpenText Advanced Authentication Server allows Accessing Functionality Not Properly Constrained by ACLs. This issue affects Advanced Authentication Server: from 6.4.0.0 through 6.4.3.8, from 6.5.0.0 through 6.5.0.10, and from 6.6.0.0 through 6.6.1.0. | ||||
| CVE-2026-112255 | 1 Opentext | 1 Advanced Authentication Server | 2026-10-29 | N/A |
| Initialization of a resource with an insecure default vulnerability in OpenText Advanced Authentication Server allows Excessive Allocation. This issue affects Advanced Authentication Server: from 6.4.0.0 through 6.4.3.x, from 6.5.0.0 through 6.5.0.x, and from 6.6.0.0 through 6.6.1.0. The fix for this is issue is to create a secure configuration. The 6.6.2.0 release has a best practice entry if the configuration is unsecure. A secure configuration is to NOT allow creation/recreation of Unauthenticated Endpoints. If creation/recreation of Unauthenticated Endpoints is required, you should only allow it from trusted networks. To remedy this issue, change your configuration to NOT allow creation/recreation of Unauthenticated Endpoints. If you require Unauthenticated Endpoints, you MUST change your configuration to use a non-empty whitelist to specify the trusted networks. An empty whitelist will allow all networks to create/recreate endpoints. | ||||
| CVE-2026-99103 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: workqueue: Fix unbound pool lifetime for pending pwqs KASAN reports a use-after-free of an unbound worker_pool in node_activate_pending_pwq(): BUG: KASAN: slab-use-after-free in _raw_spin_trylock+0x6d/0x120 Read of size 4 at addr ffff8880089ce000 by task kworker/u22:0/318 CPU: 1 UID: 0 PID: 318 Comm: kworker/u22:0 Not tainted 7.2.0 #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: 0x0 (flush-8:0) Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xce/0x610 kasan_report+0xce/0x100 _raw_spin_trylock+0x6d/0x120 pwq_dec_nr_in_flight+0x4b4/0xcb0 process_one_work+0x921/0x11a0 worker_thread+0x4d0/0xd20 kthread+0x2de/0x3c0 ret_from_fork+0x3aa/0x620 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 311: alloc_pwq+0x439/0xca0 apply_wqattrs_prepare+0x75e/0xd10 apply_workqueue_attrs_locked+0x44/0xa0 wq_nice_store+0x350/0x450 Freed by task 0: kfree+0x127/0x3b0 rcu_core+0x523/0x1780 handle_softirqs+0x1b3/0x610 Last potentially related work creation: put_unbound_pool+0x3f3/0x7d0 pwq_release_workfn+0x494/0x8e0 kthread_worker_fn+0x1ff/0x790 Canceling the last inactive work skips pwq_dec_nr_active(), so an empty pwq can remain on pending_pwqs when its refcnt reaches zero. pwq_release_workfn() currently puts the pool before removing that pwq. If this drops the last pool reference, the pool can be RCU-freed while the pwq remains reachable, and node_activate_pending_pwq() may trylock the freed pool->lock. Remove the pwq from pending_pwqs before putting the pool. | ||||