Export limit exceeded: 416256 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 416256 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (416256 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-111551 | 2026-10-28 | N/A | ||
| Several Kafka deserialization paths read a size or count field from input data and use it directly to allocate an array, collection, or byte buffer, with no check against the bytes actually available. A small crafted input can therefore declare a very large size and force a multi-gigabyte allocation. The affected paths are, in Kafka Streams, ProcessorRecordContext (header count), ChangedDeserializer (varint value length), CombinedKeySchema (foreign-key length, which could also produce a negative size), ProcessorMetadata (key length), and AssignmentInfo group-assignment decoding; and, in the clients library, ListDeserializer (used by ListSerde). Impact: An attacker can trigger the oversized allocation and raise an OutOfMemoryError that crashes the affected consumer or Kafka Streams thread; the broker and the rest of the cluster are unaffected. The reachable surface depends on the path: writing a crafted record to a Streams application's internal changelog or repartition topics, or committing crafted offset metadata to its consumer group (Streams internal paths); writing a crafted record to any topic that a consumer reads with ListSerde (ListDeserializer); or, as a member of a Streams consumer group, returning crafted assignment data when elected leader (AssignmentInfo). Because a crafted record remains in its topic, the error can recur on restart. The record size limit (max.message.bytes) does not help, because the allocation is driven by a size field rather than by the input's length. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Where authorization is enabled, restrict write access to each application's internal topics and consumer group to its own principal, and restrict who can produce to topics that are consumed with ListSerde. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: these deserialization paths validate the declared size against the remaining input before allocating and reject input that fails the check. | ||||
| CVE-2026-85908 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-28 | 7.8 High |
| Heap-based buffer overflow in Windows Win32K - GRFX allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-111496 | 2026-10-28 | N/A | ||
| Kafka Streams derives its stream-time clock from record timestamps. PunctuationSchedule.next() computed the next punctuation time as timestamp + (intervalsMissed + 1) * interval with no overflow check. A record with a timestamp at or near Long.MAX_VALUE advances stream time to that value, so the next stream-time punctuation overflows to a negative time. PunctuationQueue then re-queues that time and loops on it indefinitely while holding a lock, stalling the StreamThread. Impact: A single record is enough. The affected StreamThread stops processing, and because the record stays in the topic the hang returns on restart; an application whose partitions are all affected becomes unresponsive. Only the Streams application is affected, not the brokers or the cluster. Triggering it needs write access to a source topic whose topology uses stream-time punctuation, and a broker that stores the record: brokers from Apache Kafka 4.0.0 reject such a timestamp by default (log.message.timestamp.after.max.ms, one hour), so it is reachable only on older brokers or where that bound has been relaxed. Mitigation: Upgrade Kafka Streams to 4.2.2, 4.3.2, or 4.4.0. As defense in depth, keep log.message.timestamp.after.max.ms bounded on source topics and restrict write access to them. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the next punctuation time is computed with overflow-checked arithmetic (clamped to Long.MAX_VALUE), and a rescheduled punctuation is re-queued only when its time moves forward. | ||||
| CVE-2026-85927 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-28 | 7.8 High |
| Heap-based buffer overflow in Windows Universal Plug and Play (UPnP) Device Host allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-99177 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-28 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Fix page dirtying in sev_gmem_post_populate() set_page_dirty() requires that the caller holds some kind of lock to ensure that the page's mapping does not concurrently go away. That is not the case for a random page we got from get_user_pages_fast(), so use set_page_dirty_lock(). [sean: tag for stable] | ||||
| CVE-2026-99181 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-28 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: autofs: ignore notification errors from a replaced pipe autofs_notify_daemon() takes a reference to the current notification pipe under wq_mutex, then drops the mutex before writing the request. The write can block while the daemon enters catatonic mode and installs a replacement pipe. If the old pipe's reader is then closed, the delayed write returns -EPIPE and the generic error path enters catatonic mode again. That transition acts on the current superblock state, closes the replacement pipe, and releases the new daemon generation's wait queues. Only enter catatonic mode when the pipe which failed is still the current pipe. Factor the already-locked transition so the identity check and state change are atomic with respect to another replacement. This was reproduced on v7.3-rc5-337-gff47652a4b66c in a local QEMU guest. An unprivileged UID 65534 lookup filled the old packet pipe before a normal CATATONIC/SETPIPEFD restart. On the unmodified kernel, the new pipe received HUP and both a pending victim lookup and a later lookup failed with ENOENT in two out of two fresh-mount runs. With this change, the new pipe remained active, received an intact 304-byte request, and both victim lookups completed in two out of two runs. Normal lookup and restart-without-a-blocked-writer controls passed. No KASAN, oops, refcount, or lock diagnostic was observed. A source reproducer and complete local logs are available privately on request. The demonstrated impact is limited to denial of a shared autofs service during a legitimate daemon restart. No memory corruption, information leak, privilege escalation, or code execution primitive was observed. | ||||
| CVE-2026-99188 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-28 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: stmmac: dwmac1000: clear the RGMII status interrupt Since commit 2e2c878a3141 ("net: stmmac: remove SGMII/RGMII/SMII interrupt handling") nothing on the RGMII path reads GMAC_RGSMIIIS, so RGSMIIIS stays pending behind GMAC_INT_MASK from the first link change on. stmmac_resume() resets the MAC in stmmac_hw_setup(); the reset sets GMAC_INT_MASK to 0 until dwmac1000_core_init() writes the mask again, and the pending status storms the line: dwmac_dma_interrupt: unexpected status 04000000 A register dump at the first message on ODROID-HC4 showed it: core int_status 00000001 int_mask 00000000 pmt 00000000 rgsmiiis 0000000d When the resume thread runs on the CPU that takes the MAC interrupt, the storm starves it: a soft lockup, then a watchdog reset or a hang. Read GMAC_RGSMIIIS in dwmac1000_irq_status() when the status is not masked, as the driver did before 2e2c878a3141; the read clears it. Wake-on-LAN resume from s2idle with the resume thread and the MAC interrupt on one CPU: Helios64 (dwmac-rk), 7.3-rc6, soft-locked in 3 of 3 resumes without a fix and in 0 of 10 with this patch; it ran with an out-of-tree dwmac-rk change that keeps the GMAC powered across suspend. ODROID-HC4 (dwmac-meson8b): 0 of 10 with this patch, 2 of 2 without a fix on a 7.3-rc5 build. irq_rgmii_n went up by one per resume. | ||||
| CVE-2026-99193 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-28 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: ti: icssm-prueth: Move setting of netops to fix crash icssm_prueth_netdev_init() calls of_phy_get_and_connect() before ndev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash"). | ||||
| CVE-2026-99201 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-28 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: netlink: avoid hashing the network namespace pointer The netlink rhashtable key includes a raw struct net pointer and a user-controlled port ID. Both /proc/net/netlink and socket diagnostics expose the table's bucket order. By binding and rebinding chosen NETLINK_USERSOCK port IDs, an unprivileged reader can distinguish equal buckets and recover the low bits of the Jenkins hash. Its 32-bit seed and the limited set of kernel-image slides can then be searched offline to recover the address of init_net. Use the namespace's unique, non-address net_cookie in the comparison key instead. It is assigned before the per-net initializers run and remains unchanged for the namespace's lifetime. The lookup key and object hash are still built by netlink_compare_arg_init(), keeping lookup, insertion, removal and rehashing consistent while preserving namespace separation. Neither public table walker needs to change. Reading the socket's namespace cookie in netlink_compare() is safe under RCU, including during namespace teardown. netlink_release() removes the socket from the hash table and defers its final put with call_rcu(). cleanup_net() runs the per-net exit methods and waits for outstanding RCU callbacks with rcu_barrier() before freeing namespace storage. Unlike ns.ns_id, net_cookie is also available and initialized during setup_net() in older stable kernels, making the change straightforward to backport to v5.15 and later. | ||||
| CVE-2026-99207 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-28 | N/A |
| 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-85368 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-28 | 7.8 High |
| Heap-based buffer overflow in Windows TCP/IP allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-70216 | 1 Microsoft | 23 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 20 more | 2026-10-28 | 5.5 Medium |
| Insufficient granularity of access control in Windows Mobile Device Management allows an authorized attacker to perform tampering locally. | ||||
| CVE-2026-70222 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-28 | 7.8 High |
| Relative path traversal in Windows Shell allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-85369 | 1 Microsoft | 17 Windows 10 21h2, Windows 10 21h2, Windows 10 22h2 and 14 more | 2026-10-28 | 8.2 High |
| Out-of-bounds read in Windows Hyper-V allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-85928 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-28 | 9.8 Critical |
| Heap-based buffer overflow in Windows Volume Manager Extension Driver allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-70223 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-28 | 7 High |
| Use after free in Windows Console Driver allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-85930 | 1 Microsoft | 17 Windows 10 21h2, Windows 10 21h2, Windows 10 22h2 and 14 more | 2026-10-28 | 7 High |
| Use after free in Windows Image Acquisition allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-70225 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-28 | 7.8 High |
| Access of resource using incompatible type ('type confusion') in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-70005 | 1 Microsoft | 5 Windows Server 2019, Windows Server 2019 (server Core Installation), Windows Server 2022 and 2 more | 2026-10-28 | 5.9 Medium |
| Weak authentication in Active Directory Federation Services (AD FS) allows an unauthorized attacker to bypass a security feature over a network. | ||||
| CVE-2026-70227 | 1 Microsoft | 12 Windows 11 23h2, Windows 11 23h2, Windows 11 24h2 and 9 more | 2026-10-28 | 5.5 Medium |
| Out-of-bounds read in Windows Device Association Service allows an authorized attacker to disclose information locally. | ||||