Export limit exceeded: 413273 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (5860 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-98621 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: net: gue: reject invalid REMCSUM offsets The REMCSUM option carries an absolute checksum start and checksum field offset. gue_remcsum() passes them to skb_remcsum_process(), whose partial path stores offset - start in the u16 skb->csum_offset variable. If offset is less than start, this underflows. A forwarded packet can retain CHECKSUM_PARTIAL and reach a NETIF_F_HW_CSUM driver which trusts the metadata, leading skb_copy_and_csum_dev() to write two bytes about 64 KiB beyond the destination buffer. Reject reversed tuples in validate_gue_flags(), after the existing length validation, so all GUE parsers enforce the ordering in one place. | ||||
| CVE-2026-92157 | 2026-10-20 | 6.5 Medium | ||
| F´ (F Prime) is a framework that enables development and deployment of spaceflight and other embedded software applications. Prior to 4.3.0, Svc::FileDownlink SendPartial range validation is vulnerable because unchecked startOffset plus length arithmetic bypasses the range check and stores a wrapped m_endOffset that is inconsistent with m_byteOffset. When an existing source file is larger than a valid startOffset and a SendPartial command supplies a length whose U32 sum with that offset wraps below the file size, under standard F Prime assertion handling, the first data-packet transition reaches FW_ASSERT and aborts or resets the process, causing denial of service. This issue is fixed in version 4.3.0. | ||||
| CVE-2026-110735 | 1 Godotengine | 1 Godot Engine | 2026-10-20 | 2.5 Low |
| Godot Engine through 4.7.2 has a heap out-of-bounds write in the binary resource loader (core/io/resource_format_binary.cpp, ResourceLoaderBinary::get_unicode_string). A string length is read from the resource file into a signed 32-bit integer and compared against the destination buffer size with a signed comparison, which conditionally resizes the buffer. A negative length value skips the resize; the same value is then passed to the copy routine as an unsigned byte count, where it sign-extends to a huge value, copying file-controlled data far past the undersized heap allocation. The defect is reached when the product or an exported game loads a crafted binary resource file (.res). NOTE: the Supplier's position is that the research has identified "no security issues" because the required attacker access is outside of the current Godot Engine threat model. | ||||
| CVE-2026-110714 | 2026-10-20 | 6.5 Medium | ||
| libsmb2 through 6.2 contains an integer underflow vulnerability in decode_acl that allows malicious SMB servers to trigger heap out-of-bounds reads via crafted security descriptors. Attackers controlling a server or intercepting unsigned sessions can send an AclSize below 8 in a QUERY_INFO reply, bypassing ACE bounds checks and crashing the client. | ||||
| CVE-2026-101302 | 1 Freebsd | 1 Freebsd | 2026-10-20 | 6.5 Medium |
| TLS 1.3 embeds the actual record type as the last non-zero byte of the decrypted payload, optionally followed by zero padding. The code which searches for the inner record type had an off-by-one bug which could be triggered by an invalid frame, leading to an underflow followed by an unconditional NULL pointer dereference, causing a kernel panic. A remote TLS 1.3 peer can send a specially crafted record to trigger a kernel panic, resulting in a Denial of Service (DoS). | ||||
| CVE-2026-72003 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: cyw: fix heap overflow on a short auth frame brcmf_notify_auth_frame_rx() takes the frame length from the firmware event and copies the frame body with the management header offset subtracted: u32 mgmt_frame_len = e->datalen - sizeof(struct brcmf_rx_mgmt_data); ... memcpy(&mgmt_frame->u, frame, mgmt_frame_len - offsetof(struct ieee80211_mgmt, u)); The only length check is e->datalen >= sizeof(*rxframe), so mgmt_frame_len can be anything from 0 up. offsetof(struct ieee80211_mgmt, u) is 24. When mgmt_frame_len is below that, the subtraction wraps as an unsigned value to a huge length. The memcpy then runs far past the kzalloc'd buffer. A malicious or malfunctioning AP can make the frame short during the external SAE auth exchange, so this is a remotely triggered heap overflow. Reject frames shorter than the management header offset before the copy. | ||||
| CVE-2026-68479 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: validate firmware patch bounds rtlbt_parse_firmware() copies patch_length - 4 bytes before appending the firmware version. A malformed firmware patch shorter than the version field can make this subtraction underflow and turn the copy into an oversized read and write during Bluetooth setup. The existing patch_offset + patch_length check can also wrap on 32-bit architectures. Validate the patch length and range without arithmetic overflow before allocating or copying the patch. | ||||
| CVE-2026-68373 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 8.1 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: len -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off. | ||||
| CVE-2026-68315 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer. | ||||
| CVE-2026-68297 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX. | ||||
| CVE-2026-111881 | 1 Freerdp | 1 Freerdp | 2026-10-19 | 7.6 High |
| FreeRDP from 3.14.1 before 3.32.0 contains an integer underflow in the WinPR BMP writer, where a mismatched stride calculation passes SIZE_MAX - 3 to Stream_Zero for sub-byte images. A malicious RDP clipboard peer can return a crafted 1-bpp BMP processed by clipboard_synthesize_image_format_to_bmp for CF_DIB/CF_DIBV5, crashing the client or causing an out-of-bounds write. | ||||
| CVE-2026-68257 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608) | ||||
| CVE-2026-68158 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ] | ||||
| CVE-2026-68145 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op. | ||||
| CVE-2026-68125 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as assoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed. | ||||
| CVE-2026-68123 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it. | ||||
| CVE-2026-68108 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d) | ||||
| CVE-2026-64548 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 8.4 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data() When the scatterlist ring is full or nearly full, bpf_msg_push_data() enters a copy fallback path and computes copy + len for the page allocation size. Since len comes from BPF with arg3_type = ARG_ANYTHING and both are u32, a crafted len can wrap the sum to a small value, causing an undersized allocation followed by an out-of-bounds memcpy. BUG: unable to handle page fault for address: ffffed104089a402 Oops: Oops: 0000 [#1] SMP KASAN NOPTI Call Trace: __asan_memcpy (mm/kasan/shadow.c:105) bpf_msg_push_data (net/core/filter.c:2852 net/core/filter.c:2788) bpf_prog_9ed8b5711920a7d7+0x2e/0x36 sk_psock_msg_verdict (net/core/skmsg.c:934) tcp_bpf_sendmsg (net/ipv4/tcp_bpf.c:421 net/ipv4/tcp_bpf.c:584) __sys_sendto (net/socket.c:2206) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Add an overflow check before the allocation. | ||||
| CVE-2026-64531 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: reject oversized nested action attrs Open vSwitch stores generated flow actions as nlattrs, whose nla_len field is u16. Commit a1e64addf3ff ("net: openvswitch: remove misbehaving actions length check") allowed the total sw_flow_actions stream to grow beyond 64 KiB, which is valid, but also removed the last guard preventing a generated nested action attribute from exceeding U16_MAX. An oversized generated container can thus be closed with a truncated nla_len. A later dump or teardown then walks a structurally different stream than the one that was validated. In particular, an oversized nested CLONE/CT action may cause subsequent bytes in the generated stream to be interpreted as independent actions. Keep the larger total-action-stream behavior, but make nested action close reject generated containers that do not fit in nla_len, and return the error through all callers. For recursive SAMPLE, CLONE, DEC_TTL, and CHECK_PKT_LEN builders, trim resource-owning action-list tails in reverse construction order before discarding failed wrappers, so resources copied into the rejected tails are released before the wrappers are removed. Most failed outer wrappers are discarded by truncating actions_len after child resources have been released. CHECK_PKT_LEN also trims its parent after branch resources are gone. SET/TUNNEL close failures unwind their known tun_dst ownership directly, and SET_TO_MASKED has no external ownership and truncates on close failure. | ||||
| CVE-2026-64522 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix eswitch mode block underflow on IPsec acquire SA mlx5e_xfrm_add_state() handles acquire-flow temporary SAs by allocating software state and skipping hardware offload setup. That path jumps to the common success label before taking the eswitch mode block. After tunnel-mode validation was moved earlier, the common success label unconditionally calls mlx5_eswitch_unblock_mode(). For acquire SAs, this decrements esw->offloads.num_block_mode without a matching increment. Return directly after installing the acquire SA offload handle, so only the paths that successfully called mlx5_eswitch_block_mode() call the matching unblock. | ||||