Export limit exceeded: 398641 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (51128 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-75665 | 1 Adobe | 2 Adobe Bridge, Bridge | 2026-09-25 | 7.8 High |
| Bridge is affected by a Heap-based Buffer Overflow vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2026-75676 | 1 Adobe | 2 Adobe Bridge, Bridge | 2026-09-25 | 7.8 High |
| Bridge is affected by a Stack-based Buffer Overflow vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2026-97934 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory corruption from a "STACKTRACE" histogram key "cpu", "CPU", "stacktrace" and "STACKTRACE" are generic fields, defined with an offset and a size of zero so that the filter code can match them by name. parse_field() maps them onto their common_* equivalents for backward compatibility, but unlike the common_* names it hands the placeholder back to the caller instead of NULL. create_hist_field() takes a non-NULL field as a promise that the record carries a stacktrace and picks HIST_FIELD_FN_STACK, so the __data_loc word is read from offset 0, that is from common_type, and its low 16 bits are followed as an offset into the record. What is found there becomes the length of an unbounded memcpy. Pick an event whose id is small enough that the offset stays inside its own record and the length is a kernel text address: # cd /sys/kernel/tracing # echo 'hist:keys=STACKTRACE' > events/ftrace/print/trigger # echo hello > trace_marker Oops: general protection fault, probably for non-canonical address RIP: 0010:rb_next+0x23/0x60 </IRQ> RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x2e7/0x12c0 Kernel panic - not syncing: Fatal exception in interrupt Leave the field NULL, which is what the comment above the branch says the code does and what common_stacktrace already does. FILTER_CPU and FILTER_COMM are left alone, their create_hist_field() branches never look at the field. | ||||
| CVE-2026-97936 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory corruption from the histogram stacktrace modifier parse_field() sets HIST_FIELD_FL_STACKTRACE from the ".stacktrace" modifier before it looks the field name up, and nothing afterwards checks that the name resolved to a field which holds a stacktrace. create_hist_field() picks HIST_FIELD_FN_STACK on the strength of the field pointer alone, which reads a __data_loc word from the record and follows its low 16 bits as an offset into the same record. event_hist_trigger() takes the first word there as an entry count and copies that many longs into a 31 entry array: n_entries = *stack; memcpy(entries, ++stack, n_entries * sizeof(unsigned long)); Neither end of that copy is bounded, and the count is whatever the event holds at the offset, so any field will do: # cd /sys/kernel/tracing/events/sched/sched_process_fork # echo 'hist:keys=parent_pid.stacktrace' > trigger # (true) BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:rb_insert_color+0x18/0x130 timerqueue_linked_add+0x7e/0xd0 enqueue_hrtimer+0x39/0xb0 __hrtimer_run_queues+0x10f/0x1f0 </IRQ> RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x165/0x690 The timer interrupt landed on the rbtree the copy had already run over. No debug options are needed for this; KASAN reports the same write as an out-of-bounds read of 13835058055416381440 bytes. Documentation/trace/histogram.rst already states the rule, "must be a long[] type", so enforce it once the name has been resolved. Names which resolve to no field at all, "hitcount.stacktrace" and the common_* pseudo-fields, are refused for the same reason: they hold no stacktrace to read. | ||||
| CVE-2026-97954 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net/rds: fix tcp stream corruption with large pages rds_message_map_pages() assigns PAGE_SIZE bytes to every scatterlist entry, even when total_len ends in a partial page. The RDS congestion map is defined as 8192 bytes, so on systems with PAGE_SIZE greater than 8192 the scatterlist maps bytes beyond the end of the congestion map. RDS-TCP transmits the SG contents according to those lengths, so the extra bytes become part of the TCP RDS stream and are interpreted as subsequent RDS message headers, corrupting the stream. Limit the final scatterlist mapping to the number of bytes remaining. This has no effect on systems with a 4K page size and allows RDS-TCP to be used on systems with 16K and larger page sizes. The RDS selftest, which previously hung on 16K pages, now passes. | ||||
| CVE-2026-96546 | 2 Gimp, Redhat | 2 Gimp, Enterprise Linux | 2026-09-25 | 2.5 Low |
| A one-byte out-of-bounds heap read flaw was found in GIMP's uncompressed DDS image loader. When a user opens an uncompressed DDS image, the file-dds plug-in performs an unconditional one-byte look-ahead after processing the final pixel. This may cause the plug-in to crash if the byte immediately following the pixel buffer is inaccessible; no information disclosure or code execution has been demonstrated. | ||||
| CVE-2026-88361 | 1 Sumatrapdfreader | 1 Sumatrapdf | 2026-09-25 | 7.5 High |
| SumatraPDF 3.6.1 contains an integer overflow vulnerability in EngineMupdf::BuildPageLabelRec() when parsing PDF PageLabels /Nums entries. | ||||
| CVE-2026-88761 | 1 Botslab | 1 G980h | 2026-09-25 | 5.3 Medium |
| The Botslab G980H dash camera firmware generates the default WiFi password using predictable device information, portions of which are advertised by the product. An unauthenticated attacker within WiFi range could potentially determine the remaining password characters through limited guessing and gain unauthorized access to the device network. | ||||
| CVE-2026-61714 | 1 Fluidsynth | 1 Fluidsynth | 2026-09-25 | 7.8 High |
| FluidSynth is a software synthesizer based on the SoundFont 2 specifications. From 2.2.4 until 2.5.6, configuring synth.midi-channels above 16 allows the MIDI player to index _fluid_player_t::channel_isplaying outside its fixed-size heap allocation while tracking active channels. The resulting out-of-bounds reads and writes invoke undefined behavior and may compromise confidentiality, integrity, or availability. No crafted MIDI file is required because the unsafe condition is created by the channel-count configuration itself. Keeping synth.midi-channels at its default value of 16 avoids the vulnerable path. This issue is fixed in version 2.5.6. | ||||
| CVE-2026-14441 | 1 Brocade | 1 Sannav | 2026-09-25 | N/A |
| A logic flaw in Java cache key handling object comparison handling could lead to improper identifier resolution when processing specific user account structures. The issue has been remediated by updating the internal comparison routines to ensure accurate object evaluation and prevent potential identity mismatch conditions. | ||||
| CVE-2026-97994 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: vhost/vdpa: reject VRING_NUM larger than device max vhost_vring_set_num() accepts any non-zero power-of-two queue size that fits in 16 bits. vhost-vdpa then passes that value to set_vq_num() without comparing it with get_vq_num_max(). A process with access to /dev/vhost-vdpa-* can therefore configure a queue larger than the device advertises. With vdpa_sim, the worker can walk descriptors beyond the mapped descriptor ring. KASAN reports a 16-byte out-of-bounds read, corresponding to one vring_desc, in the vringh IOTLB path: BUG: KASAN: out-of-bounds in _copy_from_iter Read of size 16 copy_from_iotlb copydesc_iotlb vringh_getdesc_iotlb vdpasim_net_work Cache get_vq_num_max() immediately after reset. Some backends derive it from writable queue-size state, so querying it after SET_NUM may return the current size instead of the device capability. Invalidate the cached value before reset so a failed reset leaves SET_NUM disabled. For VHOST_SET_VRING_NUM, copy the complete vring state once and use the same index and size for validation, vq->num, and set_vq_num(). This ensures that validation and use operate on the same copied values. | ||||
| CVE-2026-97995 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: virtio_console: do not free control-out buffers on remove __send_control_msg() publishes &portdev->cpkt as the control-out virtqueue cookie. remove_vqs() walks every virtqueue and passes leftover cookies to free_buf(), which treats them as struct port_buffer and reads sgpages. If a control message is still on c_ovq when the device is unbound, free_buf() reads past the ports_device object. KASAN reported slab-out-of-bounds in free_buf(): free_buf remove_vqs virtcons_remove unbind_store The object was the ports_device allocated in virtcons_probe(). Drain c_ovq without freeing. The packet lives in portdev and is released with it. | ||||
| CVE-2026-98085 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: bpf: backtrack_insn(): Handle ld_{abs,ind} subprog exit edge Nicholas Carlini reported a bug in precision backtracking mechanism for BPF_LD | BPF_{IND,ABS} instructions. These instructions are modelled as two branches: - fallthrough; - implicit exit from current subprogram. The implicit exit case was not handled by the backtrack_insn() function. When backtracking such a path backtrack_insn() did not call bt_subprog_enter(), which meant that backtracking continued manipulating precision marks in a caller frame, while looking at instructions in a callee frame. This lead to segmentation faults during verification (see the selftest), or unsound state pruning. | ||||
| CVE-2026-100078 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mei: pass correct argument to function The first argument to iwl_mei_write_cyclic_buf() should be the cldev but the q_head pointer is passed instead. Fix it. | ||||
| CVE-2026-81878 | 2 Radare, Radareorg | 2 Radare2, Radare2 | 2026-09-25 | 5.5 Medium |
| radare2 is a UNIX-like reverse engineering framework and command-line toolset. Prior to 6.2.0, radare2's CPython bytecode .pyc marshal parser was vulnerable because the CPython marshal readers accepted a 32-bit string length without rejecting values that overflow the size-plus-one allocation. The vulnerability is triggered by opening or inspecting a crafted .pyc file through r2 or rabin2. A length of 0xffffffff wrapped the allocation to zero before the common byte reader wrote attacker-controlled data and fill bytes beyond the heap allocation. This can cause heap memory corruption and denial of service; arbitrary code execution is possible but has not been demonstrated. This issue is fixed in version 6.2.0. | ||||
| CVE-2026-81879 | 2 Radare, Radareorg | 2 Radare2, Radare2 | 2026-09-25 | 5.5 Medium |
| radare2 is a UNIX-like reverse engineering framework and command-line toolset. Prior to 6.2.0, radare2's ELF PN_XNUM handling was vulnerable because the ELF parser allocated the program-header array using the resolved PN_XNUM count but several consumers still iterated with the original e_phnum value of 65535. The vulnerability is triggered by processing a crafted ELF file with e_phnum = 0xffff and a much smaller resolved count in shdr[0].sh_info. Consumers iterated beyond the allocated program-header array. This can cause a heap out-of-bounds read and process termination, resulting in denial of service; memory disclosure and code execution have not been demonstrated. This issue is fixed in version 6.2.0. | ||||
| CVE-2026-81881 | 2 Radare, Radareorg | 2 Radare2, Radare2 | 2026-09-25 | 3.3 Low |
| radare2 is a UNIX-like reverse engineering framework and command-line toolset. Prior to 6.2.0, radare2's Mach-O Swift field-metadata parser was vulnerable because a relative Swift field pointer could be lower than the field-metadata section base, making subtraction produce a negative logical index. The vulnerability is triggered by parsing Swift type and class metadata from a crafted Mach-O file. The derived index was used to read four bytes immediately before the allocated field-metadata buffer. This can cause incorrect metadata processing or process termination; no attacker-observable memory disclosure has been demonstrated. This issue is fixed in version 6.2.0. | ||||
| CVE-2026-81882 | 2 Radare, Radareorg | 2 Radare2, Radare2 | 2026-09-25 | 3.3 Low |
| radare2 is a UNIX-like reverse engineering framework and command-line toolset. Prior to 6.2.0, radare2's binary property-list Unicode parser was vulnerable because the binary-property-list Unicode parser underallocated an uninitialized UTF-8 destination and did not guarantee NUL termination. The vulnerability is triggered by running the explicit pFB or pFBj commands on untrusted binary property-list data. The json encoder treated the converted data as a nul-terminated c string and could continue reading beyond the allocation. This can cause disclosure of uninitialized or adjacent heap contents in JSON output and possible process termination. This issue is fixed in version 6.2.0. | ||||
| CVE-2026-20136 | 1 Cisco | 3 Identity Services Engine, Identity Services Engine Passive Identity Connector, Identity Services Engine Software | 2026-09-25 | 6 Medium |
| A vulnerability in the CLI of Cisco Identity Services Engine (ISE) and Cisco ISE Passive Identity Connector (ISE-PIC) could allow an authenticated, local attacker with administrative privileges to perform a command injection attack on the underlying operating system and elevate privileges to root. This vulnerability is due to insufficient validation of user supplied input. An attacker could exploit this vulnerability by providing crafted input to a specific CLI command. A successful exploit could allow the attacker to elevate their privileges to root on the underlying operating system. | ||||
| CVE-2026-98025 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent partial_data heap overflow The 0xffff length sentinel detects a router reboot and schedules re-enabling of ethernet mode, but then falls through to the rest of the loop body. The next check is } else if (len > CX82310_MTU) { which is the else of the just-matched if -- it never fires for len == 0xffff. The MTU bound that normally caps the incomplete-packet save path is silently bypassed. With 0xffff > skb->len always true (rx_urb_size is 4096), the incomplete-packet branch saves dev->partial_len = skb->len bytes into dev->partial_data. partial_data is kmalloc(hard_mtu) = kmalloc(CX82310_MTU + 2) = 1516 bytes, but skb->len after the 2-byte header pull can be up to 4094. A device that sends a 4096-byte URB starting with [0xff 0xff] therefore copies 4094 device-provided bytes into a buffer allocated for 1516 bytes, exceeding its requested size by 2578 bytes. The next URB then reads dev->partial_len (4094) back from the same 1516-byte buffer and dev->partial_rem (65535 - 4094 = 61441) from the new URB's ~4KB skb, both well past their allocations, and delivers the spliced result as a 64KB "frame" to the network stack. Bail out of rx_fixup after scheduling the re-enable work; the remainder of a reboot-marker URB is not meaningful packet data. This restores the invariant that partial_len < CX82310_MTU + 2 on the save path, since every other route there has already passed the MTU check. | ||||