Export limit exceeded: 416903 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (649 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-118769 | 1 Randombit | 1 Botan | 2026-10-29 | N/A |
| Botan is a C++ cryptography library. From 2.1.0 until 3.13.0, the Botan C API function botan_block_cipher_block_size converted a size_t block size to int without a bounds check. In an application that accepts external algorithm parameter strings and uses the FFI raw ECB mode, an attacker can select the variable-block-size Lion cipher so that the reported size is truncated, the caller allocates insufficient memory, and later block processing causes memory corruption. The C++ API and normally used C API modes such as CBC and CTR are unaffected. This issue is fixed in version 3.13.0. | ||||
| CVE-2026-98950 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 3.7 Low |
| In the Linux kernel, the following vulnerability has been resolved: flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect() bpf_flow_dissect() sanitizes the offsets returned by the BPF program with clamp_t(u16, ..., hlen). If hlen is bigger than 65535, the upper bound is truncated before the comparison. For instance, with hlen == 65536, both nhoff and thoff are forced to zero, even if the program returned sane values. This is the same class of bug as the one fixed in commit 99bda1ecbd56 ("flow_dissector: avoid u16 truncation of skb->len when computing thoff"). That fix does not cover the BPF path, because __skb_flow_dissect() returns early when a BPF flow dissector handles the packet. struct bpf_flow_keys stores nhoff and thoff as u16, so cap hlen to U16_MAX before clamping. Found by sashiko while reviewing the commit above. | ||||
| CVE-2026-106971 | 2026-10-29 | N/A | ||
| An integer overflow in the MessagePack\BufferUnpacker component of rybakit/msgpack versions prior to 0.11.0 allows attackers to cause a denial of service via crafted MessagePack input when the application runs on 32-bit PHP | ||||
| CVE-2026-98955 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 5.9 Medium |
| In the Linux kernel, the following vulnerability has been resolved: flow_dissector: avoid u16 truncation of skb->len when computing thoff __skb_flow_dissect() computes key_control->thoff using: key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen); min_t(u16, ...) casts both arguments to u16 before comparing them. Whenever skb->len (or hlen) modulo 65536 is smaller than nhoff, the truncated length wins and thoff is set to a bogus small value, even when the dissection succeeded. For example, an IPv4/TCP frame with skb->len == 65540 and nhoff == 34 gets thoff == 4, so callers such as skb_probe_transport_header() point the transport header inside the Ethernet header. Such skbs are not exotic: - At the time of commit d0c081b49137 ("flow_dissector: properly cap thoff field"), AF_PACKET with PACKET_VNET_HDR could already build GSO skbs larger than 64KB (MTU checks are skipped for GSO, and alloc_skb_with_frags() accepted up to MAX_SKB_FRAGS (17) order-0 pages on top of the linear part). - BIG TCP now makes skbs larger than 64KB common. - The following patch makes tun_get_user() dissect IFF_TAP frames before eth_type_trans() pulls the Ethernet header, so a GSO frame carrying a 65522..65535 byte L3 packet will be dissected with skb->len in [65536, 65549]. Compare as u32 instead. If the resulting offset cannot be represented in the u16 key_control->thoff, cap it to U16_MAX and report the dissection as failed rather than silently returning a wrong transport offset. thoff is still set on failure, as some callers (such as eth_get_headlen()) use it regardless of the return value. | ||||
| CVE-2026-115786 | 1 Zimbra | 1 Zimbra Collaboration Suite | 2026-10-28 | 6.5 Medium |
| A mailbox quota-accounting vulnerability in Zimbra Collaboration Suite (ZCS) allows an authenticated user to consume another user’s mailbox quota by repeatedly sharing and revoking a document. Creation of the recipient’s shared-file record charges the document size to mailbox-wide usage. Revocation deletes the record and reverses its folder counters without reversing the mailbox-wide charge. Repeated normal share notifications therefore accumulate quota usage after the visible records are gone. On accounts with a finite quota, this can prevent incoming mail and other size-increasing operations without recipient interaction. The issue affects ZCS 10.1.16 and 10.1.20. | ||||
| CVE-2026-99128 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-28 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: sctp: validate chunk length in the inqueue parser SCTP chunks always include a four-byte generic header, but sctp_inq_pop() currently accepts shorter declared lengths. A zero-length chunk leaves chunk_end at the current header. When ASCONF is covered by the association's SCTP-AUTH policy, sctp_assoc_bh_rcv() can continue before the state machine performs its normal chunk-length check. sctp_inq_pop() then returns the same malformed chunk repeatedly and the receive softirq can lock up. A remote SCTP peer can trigger this after establishing an association on a kernel built with CONFIG_IP_SCTP and configured with net.sctp.addip_enable=1 and net.sctp.auth_enable=1. The reproducer did not require application credentials, a shared SCTP AUTH key, or net.sctp.addip_noauth_enable=1. On commit f967455fb2a5 ("seg6: reset IP6CB after IPv6 decapsulation"), one zero-length ASCONF caused repeated watchdog soft-lockup reports in a two-vCPU KVM guest. All 3 pre-trigger health probes succeeded, while 36 of 37 post-trigger probes failed. With this change, all 37 post-trigger probes succeeded and no equivalent soft-lockup signature appeared. Reject chunks shorter than the generic SCTP header at the shared inqueue parser boundary. Mark the packet for discard before either caller can continue processing it, while preserving the four-byte generic minimum. Declared-length 1 through 4 controls and kernel-generated ASCONF traffic remained healthy. The patched sctp_hello selftest passed for IPv4 and IPv6. The complete private reproducer and validation evidence are available directly to maintainers on request. | ||||
| CVE-2026-99133 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-28 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix the recvmsg window update iucv_sock_recvmsg() sends the HiperSockets-only AF_IUCV_FLAG_WIN without testing the transport, so on a classic z/VM socket iucv_send_ctrl() sizes the skb through a NULL iucv->hs_dev. SO_MSGLIMIT accepts 1, so msglimit / 2 is zero and one recvmsg() on its own socket is enough for an unprivileged process to take a spurious disconnect. It also calls iucv_send_ctrl() under spin_lock_bh(&message_q.lock), which allocates GFP_KERNEL inside a section the code treats as atomic. Sending outside that lock lets two recvmsg() reach afiucv_hs_send() at once, where msg_recv is sampled for the advertised window and subtracted after dev_queue_xmit() -- and sendmsg reaches that counter under lock_sock() while recvmsg holds no socket lock, so both can subtract the same value, the counter goes negative and the credit reaches the peer twice. Test the transport, claim the credit with atomic_xchg() after the last error exit and hand it back if the transmit fails, and send once the lock is dropped. | ||||
| CVE-2026-99150 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-28 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: don't drop the runtime PM reference twice in amdgpu_gpr amdgpu_debugfs_gpr_read() drops its runtime PM reference right after reading the wave registers. When copying them to userspace fails, it jumps to the err label, which drops the reference a second time. A read into a bad buffer on Navi31 either steals a reference somebody else holds (power/runtime_usage goes from 1 to 0) or underflows the count: amdgpu 0000:03:00.0: Runtime PM usage count underflow! The registers are already in the kernel buffer at that point, so finish the hardware access first and copy the buffer with a single copy_to_user() instead of the put_user() loop with its own error path. (cherry picked from commit 31035bbd74f7c3e10c163db875b8e67f8b50ee6a) | ||||
| CVE-2026-99130 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-28 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: io_uring/cancel: don't spin on local work the task can't run io_uring_cancel_generic() refuses to sleep while any ring on the exiting task's tctx has local work pending. It assumes the task is that ring's submitter and that the next io_uring_try_cancel_requests() pass will run the work. This does not hold for a ring that was still IORING_SETUP_R_DISABLED when the task got its tctx node from io_uring_create() or io_ringfd_register(). The submitter is set later by IORING_REGISTER_ENABLE_RINGS, possibly from another task, and only the submitter may run local work on an IORING_SETUP_DEFER_TASKRUN ring. To the exiting task the work stays pending forever, the loop never reaches schedule(), and the task trips the WARN_ON_ONCE() once and then spins in do_exit(). An unprivileged user can set this up at will by creating a disabled ring, having a child enable it and stop, posting to the ring with IORING_OP_MSG_RING and exiting with a request in flight that only the child can complete. The exiting thread burns a CPU until the child runs or dies, and with panic_on_warn set the WARN panics the kernel. Fix by skipping the sleep only when io_allowed_defer_tw_run() allows the task to run the work. This is reasonable since work it cannot run cannot complete any of its requests either, so nothing is lost by sleeping. Drop the WARN_ON_ONCE() since handing a disabled ring to another thread is a supported scenario, not a bug state. | ||||
| CVE-2026-118009 | 1 Mozilla | 1 Firefox | 2026-10-28 | N/A |
| Integer overflow, use-after-free in the Graphics: Text component. This vulnerability was fixed in Firefox 159 and Thunderbird 159. | ||||
| CVE-2026-117984 | 1 Mozilla | 1 Firefox | 2026-10-27 | N/A |
| Incorrect boundary conditions in the Layout: Scrolling and Overflow component. This vulnerability was fixed in Firefox 159, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. | ||||
| CVE-2026-106438 | 1 Mongodb | 1 C Driver | 2026-10-27 | 4 Medium |
| An incorrect calculation in Decimal128 string parsing in the MongoDB C Driver can accept certain over-precision inputs containing leading zeros instead of rejecting them. This produces a value different from the supplied text. An actor who can provide a decimal string to an embedding application, including through Extended JSON parsing, can cause the application to store or use an incorrect numeric value. | ||||
| CVE-2026-75145 | 1 Ffmpeg | 1 Ffmpeg | 2026-10-27 | 5.8 Medium |
| FFmpeg before commit b4c199c contains an incorrect integer narrowing conversion in the AV1 RTP packetizer (libavformat/rtpenc_av1.c). The OBU size is cast to long before comparison against the remaining frame size. On targets where long is 32 bits, including 64-bit Windows, sufficiently large OBU size values are sign-flipped by the narrowing cast, producing a negative value that passes the payload size check. This allows an oversized OBU to bypass the safety bound on affected platforms, leading to out-of-bounds memory access when the oversized value is subsequently used as a copy length. | ||||
| CVE-2026-112642 | 1 Apple | 4 Ios And Ipados, Macos, Tvos and 1 more | 2026-10-27 | N/A |
| An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2, tvOS 27.2, visionOS 27.2. Processing a maliciously crafted font may result in the disclosure of process memory. | ||||
| CVE-2026-112468 | 1 Apple | 4 Ios And Ipados, Macos, Tvos and 1 more | 2026-10-27 | N/A |
| An out-of-bounds write issue was addressed with improved bounds checking. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2, tvOS 27.2, visionOS 27.2. An app may be able to cause unexpected system termination or corrupt kernel memory. | ||||
| CVE-2026-112519 | 1 Apple | 1 Macos | 2026-10-27 | N/A |
| An integer overflow was addressed with improved input validation. This issue is fixed in macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. Connecting to a malicious VNC server may cause a denial-of-service. | ||||
| CVE-2026-112596 | 1 Apple | 5 Ios And Ipados, Macos, Tvos and 2 more | 2026-10-27 | N/A |
| An integer overflow was addressed with improved bounds checking. This issue is fixed in iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, tvOS 27.2, visionOS 27.2, watchOS 27.2. Processing a maliciously crafted video file may lead to unexpected system termination. | ||||
| CVE-2026-112601 | 1 Apple | 1 Macos | 2026-10-27 | N/A |
| An integer overflow was addressed with improved input validation. This issue is fixed in macOS Sequoia 15.8.2. An app may be able to cause a denial-of-service. | ||||
| CVE-2026-112449 | 1 Apple | 3 Ios And Ipados, Macos, Visionos | 2026-10-26 | N/A |
| An integer overflow was addressed with improved input validation. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2, visionOS 27.2. Processing a maliciously crafted 3D model may lead to memory corruption. | ||||
| CVE-2026-116541 | 1 Netty | 2 Netty-tcnative, Netty-tcnative-boringssl-static | 2026-10-26 | 5.9 Medium |
| Netty netty-tcnative before 2.0.84.Final contains a denial of service vulnerability in the tcn_write_to_bytebuffer BIO write callback that overreports bytes consumed. Remote TLS 1.3 peers can provoke queued post-handshake records like NewSessionTicket or KeyUpdate to truncate flights, fail connections, or abort the JVM process. | ||||