Export limit exceeded: 415527 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 415527 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 25952 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (25952 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-98569 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ip_gre: Reject enabling collect metadata through changelink ipgre_netlink_parms() can enable collect_md on an existing GRE, GRETAP or ERSPAN device. Unlike newlink, changelink does not enforce metadata tunnel uniqueness. Converting a non-metadata device can therefore replace the metadata receive entry for another device of the same type in the same netns. Deleting either device then clears the shared entry, breaking metadata receive lookup for the surviving device. If parameter validation fails after collect_md is set, deleting the modified device can also clear an entry it never owned. Reject enabling metadata mode in both changelink callbacks before any encapsulation or tunnel parameters are modified. Allow requests that repeat the metadata attribute on an existing metadata device. | ||||
| CVE-2026-98573 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix pull-bound underflow in skb_checksum_setup_ipv6() skb_maybe_pull_tail() subtracts skb_headlen(skb) from the unsigned max argument and passes the result to __pskb_pull_tail() as a signed int. The function does not ensure that max is at least skb_headlen(skb). This can happen while parsing IPv6 extension headers when an skb already has a linear area larger than MAX_IPV6_HDR_LEN. Once the parser needs data beyond the linear area, max - skb_headlen(skb) wraps and is converted to a negative delta. __pskb_pull_tail() then passes that negative length to skb_copy_bits(), where it can become a very large copy length. Pass the requested length itself as the pull bound at the three extension-header call sites, so the delta can no longer go negative. | ||||
| CVE-2026-98576 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 5.3 Medium |
| In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: fix slab-out-of-bounds reads when logging service names nfc_llcp_wks_sap() and nfc_llcp_build_sdreq_tlv() pass non-null- terminated strings to pr_debug() using the %s format specifier. The buffers are allocated via kmemdup() or come from netlink attributes and are not guaranteed to be null-terminated, causing __dynamic_pr_debug() to read beyond the allocated region: KASAN: slab-out-of-bounds Read in __dynamic_pr_debug Fix both call sites by using %.*s with the explicit length to limit the output to the actual length of the string. | ||||
| CVE-2026-98591 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 6.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix bounds check for skb-backed dynptrs The skb_pointer_if_linear() function checks whether a memory region of length len starting at offset off into the skb is in the linear area, and returns a pointer to the region if so. The check currently subtracts between skb_headlen and offset of the check, and since skb_headlen is unsigned the subtraction can underflow. This causes the bounds check to spuriously pass and generate an arbitrary pointer of the form *(skb->data + off). The only user of this helper is currently skb-backed BPF dynptr code. Returning the wrong pointer leads to the dynptr erroneously being backed with invalid memory. Ensure the subtraction cannot underflow, and fail the check if it would. Use u64 arithmetic to also prevent overflow when calculating (skb_headlen(skb) - off) since off is unsigned. | ||||
| CVE-2026-98600 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 6.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame() While rfcomm_recv_frame() verifies that skb->len is at least sizeof(*hdr) + 1 (4 bytes: 3-byte header + 1-byte FCS), an RFCOMM frame with an extended 2-byte length field (!__test_ea(hdr->len)) has a 4-byte header plus a 1-byte FCS (5 bytes minimum, sizeof(*hdr) + 2). When a 4-byte RFCOMM frame with EA == 0 arrives: 1. The initial skb->len < sizeof(*hdr) + 1 check passes (4 < 4 is false). 2. Trimming the FCS byte decrements skb->len to 3. 3. If __check_fcs() succeeds, skb_pull(skb, 4) fails (4 > 3) and returns NULL without advancing skb->data. 4. Because the return value of skb_pull() is ignored, the un-pulled 3-byte struct rfcomm_hdr remains at skb->data and is either queued as application payload via rfcomm_recv_data() or parsed as a multiplexer control command via rfcomm_recv_mcc() on DLCI 0. Fix this by extending the length check in rfcomm_recv_frame() to also require skb->len >= sizeof(*hdr) + 2 when !__test_ea(hdr->len). | ||||
| CVE-2026-98603 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 2.5 Low |
| In the Linux kernel, the following vulnerability has been resolved: ovpn: replace bind when clearing stale local source The UDP output fallback clears bind->local in place when the remembered source address is no longer usable. The bind is RCU-published and read locklessly by concurrent TX, so an IPv6 reader can observe a torn address. Retry the route lookup with source address autoselection without modifying the bind. After a successful lookup, revalidate the bind and route key under peer->lock, reset the dst cache, and best-effort publish a replacement bind with a wildcard local address. Do not cache the resolved dst when clearing the local source. Replacing the source invalidates all per-CPU cache entries, while dst_cache_set_ip4 and dst_cache_set_ip6 update only the current CPU slot. The current packet can still use the resolved route; if bind allocation fails, a later cache miss retries the repair. | ||||
| CVE-2026-35562 | 4 Amazon, Apple, Linux and 1 more | 5 Amazon Athena Odbc Driver, Athena Odbc, Macos and 2 more | 2026-10-20 | 7.5 High |
| Allocation of resources without limits in the parsing components in Amazon Athena ODBC driver before 2.1.0.0 might allow a threat actor to cause a denial of service by delivering crafted input that triggers excessive resource consumption during the driver's parsing operations. To remediate this issue, users should upgrade to version 2.1.0.0. | ||||
| CVE-2026-35560 | 4 Amazon, Apple, Linux and 1 more | 5 Amazon Athena Odbc Driver, Athena Odbc, Macos and 2 more | 2026-10-20 | 7.4 High |
| Improper certificate validation in the identity provider connection components in Amazon Athena ODBC driver before 2.1.0.0 might allow a man-in-the-middle threat actor to intercept authentication credentials due to insufficient default transport security when connecting to identity providers. This only applies to connections with external identity providers and does not apply to connections with Athena. To remediate this issue, users should upgrade to version 2.1.0.0. | ||||
| CVE-2026-35559 | 4 Amazon, Apple, Linux and 1 more | 5 Amazon Athena Odbc Driver, Athena Odbc, Macos and 2 more | 2026-10-20 | 6.5 Medium |
| Out-of-bounds write in the query processing components in Amazon Athena ODBC driver before 2.1.0.0 might allow a threat actor to crash the driver by using specially crafted data that is processed by the driver during query operations. To remediate this issue, users should upgrade to version 2.1.0.0. | ||||
| CVE-2026-35558 | 4 Amazon, Apple, Linux and 1 more | 5 Amazon Athena Odbc Driver, Athena Odbc, Macos and 2 more | 2026-10-20 | 7.8 High |
| Improper neutralization of special elements in the authentication components in Amazon Athena ODBC driver before 2.1.0.0 might allow a threat actor to execute arbitrary code or redirect authentication flows by using specially crafted connection parameters that are processed by the driver during user-initiated authentication. To remediate this issue, users should upgrade to version 2.1.0.0. | ||||
| CVE-2026-5485 | 2 Amazon, Linux | 3 Amazon Athena Odbc Driver, Athena Odbc, Linux Kernel | 2026-10-20 | 7.8 High |
| OS command injection in the browser-based authentication component in Amazon Athena ODBC driver before 2.0.5.1 on Linux might allow a threat actor to execute arbitrary code by using specially crafted connection parameters that are loaded by the driver during a local user-initiated connection. To remediate this issue, users should upgrade to version 2.0.5.1 or later. | ||||
| CVE-2026-35561 | 4 Amazon, Apple, Linux and 1 more | 5 Amazon Athena Odbc Driver, Athena Odbc, Macos and 2 more | 2026-10-20 | 7.4 High |
| Insufficient authentication security controls in the browser-based authentication components in Amazon Athena ODBC driver before 2.1.0.0 might allow a threat actor to intercept or hijack authentication sessions due to insufficient protections in the browser-based authentication flows. To remediate this issue, users should upgrade to version 2.1.0.0. | ||||
| CVE-2026-98158 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ppp_async: drop the errored frame instead of resetting its headroom ppp_receive_nonmp_frame() prepends a two-byte direction tag before running the pass/active BPF filters: *(__be16 *)skb_push(skb, 2) = htons(PPP_FILTER_INBOUND_TAG); Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in ppp_async's process_input_packet() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from dev_alloc_skb() carries NET_SKB_PAD: err: if (skb) { /* make skb appear as freshly allocated */ skb_trim(skb, 0); skb_reserve(skb, - skb_headroom(skb)); } ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head: skbuff: skb_under_panic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev:<NULL> kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x13e/0x230 Call Trace: skb_push+0xbd/0x100 ppp_receive_nonmp_frame+0x48a/0x1d10 ppp_input+0x4e9/0x2f80 ppp_async_process+0x2a/0xe0 tasklet_action_common+0x20f/0x8a0 handle_softirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt Zeroing the headroom violates the NET_SKB_PAD guarantee that dev_alloc_skb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled ppp_decompress_frame() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason. Rather than restore the headroom, drop the errored frame - as ppp_synctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read. The original V1 of this patch made room in ppp_receive_nonmp_frame() with skb_cow_head(); Eric pointed out that fixing the root cause in the transport is the right approach. Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied. | ||||
| CVE-2026-98157 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation The poll_msec sysfs store file uses simple_strtoul() which accepts an unsigned long, but the target field (poll_msec) is unsigned int. On 64-bit systems, a value > UINT_MAX is silently truncated when stored. Fix the mismatch by using kstrtouint() instead. This rejects values larger than UINT_MAX at parse time, making truncation impossible. Also add a check for value < 1 to reject the 0-delay case, which would cause the poll work to spin without delay and consume 100% CPU. | ||||
| CVE-2026-98155 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Address potential out-of-bounds read in resp_worker() Although 'commit 2feec5ae5df7 ("accel/qaic: Handle DBC deactivation if the owner went away")' fixes the scenario it was intended for by walking the message and only decoding QAIC_TRANS_DEACTIVATE_FROM_DEV, if present, it skipped over the bounds checking code that is included in decode_message(). This could lead to issues such as reading past the slab allocation's end, infinite loops or kernel panics. For those issues to happen, a malformed wire message is needed to be sent from the device. Instead of duplicating the bounds checking code already present in decode_message(), use the function inside resp_worker(). | ||||
| CVE-2026-98154 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix -EIO cleanup order in queue_rq On -EIO, the RDMA queue_rq path reports a host path error and then still cleans up the command and unmaps the SQE DMA. The path error helper completes the request, so that is double cleanup and DMA unmap after the request is already complete. Unmap the SQE first, then report the host path error. Skip the outer command cleanup on that path. | ||||
| CVE-2026-80726 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 8.8 High |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-98506 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 4.1 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: do not dissolve gigantic pages without runtime support dissolve_free_hugetlb_folio() doesn't check hstate_is_gigantic_no_runtime(h) though remove_hugetlb_folio()/ update_and_free_hugetlb_folio() silently bail for such folios, so it frees a still-listed folio and, on vmemmap restore failure, the add_hugetlb_folio() rollback corrupts the free list. | ||||
| CVE-2026-64524 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 7.7 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/hyperv: validate resolution_count and fix WIN8 fallback A SYNTHVID_RESOLUTION_RESPONSE with resolution_count > 64 walks past the supported_resolution[SYNTHVID_MAX_RESOLUTION_COUNT] array in the parse loop. Bound resolution_count against the array size, folded into the existing zero-check. When the WIN10 resolution probe fails, the caller in hyperv_connect_vsp() left hv->screen_*_max / preferred_* unpopulated, which sets mode_config.max_width / max_height to 0 and makes drm_internal_framebuffer_create() reject every userspace framebuffer with -EINVAL. The pre-WIN10 branch had the same gap for preferred_width / preferred_height. Use a single post-probe fallback guarded by screen_width_max == 0 so both paths converge on the WIN8 defaults. | ||||
| CVE-2026-98467 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Fix null ptr deref on nested wp/unmap, teardown race Commit 7270cc9157f4 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU notifiers") introduced VNCR_EL2 invalidation in both kvm_nested_s2_unmap() and kvm_nested_s2_wp(). However at the point of this being performed concurrent stage 2 teardown of a nested guest can cause kvm->arch.mmu.pgt to be set to NULL. This happens in kvm_flush_shadow_all() -> kvm_arch_flush_shadow_all() -> kvm_free_stage2_pgd() and is performed under the kvm->mmu_lock. Commit ec14c272408a ("KVM: arm64: nv: Unmap/flush shadow stage 2 page tables") introduced the teardown of the entire nested MMU range, which then invokes stage2_apply_range() with resched=true: mmu_notifier_invalidate_range_start() -> ... -> kvm_mmu_notifier_invalidate_range_start() -> kvm_mmu_unmap_gfn_range() -> kvm_unmap_gfn_range() -> kvm_nested_s2_unmap() -> kvm_stage2_unmap_range() -> __unmap_stage2_range() -> stage2_apply_range() This means that stage2_apply_range() can drop the kvm->mmu_lock and thus concurrent progress can be made in lockstep with kvm_arch_flush_shadow_all(). If kvm_arch_flush_shadow_all() advances ahead of stage2_apply_range() and completes its operation it guarantees a NULL pointer deref. Since kvm_free_stage2_pgd() is performed under the kvm->mmu_lock this will either be observed NULL or not and serialised against kvm_free_stage2_pgd(). Resolve the issue by abstracting the invalidation to a new function, kvm_invalidate_vncr_ipa_all(), and check that the pgt is non-NULL before dereferencing it. | ||||