Export limit exceeded: 399421 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (5571 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-93652 | 1 D3tn | 1 Ud3tn | 2026-09-19 | 7.5 High |
| Integer overflow in µD3TN v0.15.0 TCPCLv3 handshake causes heap overflow, allowing remote attackers to reliably cause DoS | ||||
| CVE-2026-93127 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Drop scalar id on sign-extending narrowing stack fills When a spilled scalar is filled back with a sign-extending narrowing load (BPF_MEMSX), check_stack_read_fixed_off() copies the spilled register including its scalar id, but coerce_reg_to_size_sx() then sign-extends the filled register's value. If the same slot is also filled with a plain zero-extending load (BPF_MEM), both destination registers share the id yet hold different values. A later 'if <zext-reg> == const' then refines the sign-extended register through sync_linked_regs() to a value it does not have at runtime (e.g. the verifier believes 0x80000000 while the register is 0xffffffff80000000), which can be turned into an out-of-bounds access. Drop the shared scalar id at the sign-extension site in check_mem_access() when sign extension actually changes the value, mirroring the BPF_MOVSX handling in check_alu_op() (no_sext = reg_umax < 2^(size*8-1)). | ||||
| CVE-2026-90245 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: fbdev: kyro: Validate overlay viewport coordinates The overlay viewport end coordinates are computed from the viewport origin and dimensions using 32-bit unsigned arithmetic. Large input values can cause these calculations to wrap around before the resulting coordinates are passed to SetOverlayViewPort(). SetOverlayViewPort() packs the viewport coordinates into 16-bit register fields. The X coordinates are additionally adjusted by +2 and +1 before being written. Validate the coordinate calculations for 32-bit wraparound and ensure that the adjusted coordinates fit within their 16-bit register fields before calling SetOverlayViewPort(). Found by Linux Verification Center (linuxtesting.org) with SVACE. | ||||
| CVE-2026-90409 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Add vm_bind region with kbo range overlap check When a VM is created, caller has to specify the range of the address space carve-out set aside for mapping kernel BO's. That means vm_bind mappings of UM-exposed BO's should not intersect with that region, but at the moment we're not checking this. At first, I thought of giving these values to drm_gpuvm_init() through its reserve_{offset, range} arguments, but it turns out that is meant for VM address spans that are not managed through the usual drm_gpuvm split/merge circuit, so storing the end of the user VA range at VM creation time and doing a quick check in the vm_bind ioctl path was the simplest workaround. The new check also makes sure vm_bind range doesn't overflow the size of a 64-bit unsigned integer. That was already being done further down the call stack inside drm_gpuvm_sm_map -> drm_gpuvm_range_valid, but it's best to fail early in the driver before GPUVM functions are invoked so that we won't waste time allocating vm_bind context resources. | ||||
| CVE-2026-93065 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix counter type in iwl_fwrt_dump_error_logs The loop counter 'count' was declared as u8 while num_pc is u32. If firmware advertises more than 255 PC entries the counter wraps back to zero and the loop never terminates potentially causing an infinite loop or reading past the allocated pc_data array. Change the declaration to u32 to match num_pc. | ||||
| CVE-2026-93062 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: guard against division by zero in iwl_dbg_tlv_alloc_fragments Make sure we don't end-up with a num_frags = 0 situation. For that, check that the required size is not 0 and put a checker on num_frags as well. | ||||
| CVE-2026-90314 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() table->offset[i] is a u32 from firmware, but was stored into a signed int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression "table_sz - offset - sizeof(*hdr)", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected. Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic. | ||||
| CVE-2026-90331 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: HID: asus: refactor the two workqueues and init sequence Multiple issues have been found within the hid-asus driver: - unchecked size in asus_raw_event() - unclean teardown of asus_probe on failure - possible use-after-free in asus_probe - multiple workqueue used for jobs where one was enough - sleeping calls in atomic context - packets of incorrect size being sent to the keyboard controller Join the two workqueues into one reusing the stopping mechanism of the brightness workqueue, use the joined workqueue to also move the asus_wmi_send_event() sleeping call away from atomic context and add a size check in asus_raw_event(). | ||||
| CVE-2026-90259 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix a wrong length calculation in qgroup_free_reserved_data() In that function, we round down the start position and round up the ending position. But during the calculation of @len, we use "round_up(start + len, sectorsize)", which is the rounded up end position, not the rounded up length. Which results a much larger length, and later we are still using "start + len", which is completely incorrect. Fix it by declaring a local @aligned_start and @aligned_len and use them instead. | ||||
| CVE-2026-90246 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: apparmor: fix integer overflow in verify_tags() bounds check verify_tags() validates the tagset table unpacked from a policy blob. For each set it reads a count and checks that advancing the index by that count stays inside sets.table[]: u32 cnt = tags->sets.table[i]; if (i+cnt >= tags->sets.size) { i, cnt and sets.size are all u32, so i+cnt is evaluated modulo 2^32. sets.table[] is filled by unpack_tagsets() with aa_unpack_u32(), so every entry is a raw unbounded 32-bit word taken from the policy blob, and verify_tags() is the function that is supposed to validate it. A count close to U32_MAX makes the sum wrap to a small value, the guard passes, and the inner loop then walks sets.table[++i] past the end of the kcalloc(size, sizeof(u32)) allocation. Note that sets.size is bounded by 65535, because unpack_tagsets() reads it with aa_unpack_array() as a u16, so the wrap cannot be reached by growing the table; it is reached purely through the attacker-supplied count. With sets.size = 2 and sets.table = { 0, 0xffffffff }: i = 0: cnt = 0, guard 0 + 0 >= 2 is false, inner loop does not run i = 1: cnt = 0xffffffff, guard (1 + 0xffffffff) mod 2^32 == 0 >= 2 is false, so the guard is bypassed and the inner loop reads sets.table[2] -- one element past a two element allocation The walk continues until an out-of-bounds value happens to be >= hdrs.size or the access faults, so a crafted policy yields an out-of-bounds read on the policy load path (aa_replace_profiles -> aa_unpack -> unpack_policydb -> unpack_tags -> verify_tags). unpack_tags() runs before the perms and DFA tables are unpacked, so no other table needs to be well formed to reach it. Policy load is gated by aa_may_manage_policy(), which checks CAP_MAC_ADMIN relative to the subject's own user namespace rather than the init user namespace, so with the default unprivileged_userns_apparmor_policy=1 the path is reachable from an unprivileged task in a matched-level nested namespace, not only by a globally privileged one. Perform the addition in u64 so that it cannot wrap, restoring the intended i + cnt < sets.size guarantee. | ||||
| CVE-2026-44235 | 1 Alanxz | 1 Rabbitmq-c | 2026-09-19 | 6.5 Medium |
| rabbitmq-c is a C-language AMQP client library for RabbitMQ. Prior to 0.16.0, a malicious AMQP server can send an undersized HEADER or METHOD frame during client login and cause unsigned size_t underflow in amqp_handle_input() in librabbitmq/amqp_connection.c. The parser subtracts HEADER_SIZE, fixed per-frame fields, and FOOTER_SIZE from state->target_size without first checking the minimum frame length. The wrapped encoded.len value is passed through amqp_decode_properties() to amqp_decode_table_internal(), where it defeats bounds checks and causes an out-of-bounds read and process crash. An on-path attacker can also trigger the issue when AMQP traffic is not protected by TLS with certificate validation. The demonstrated impact is denial of service, with no reliable memory disclosure or code execution shown. This issue is fixed in version 0.16.0. | ||||
| CVE-2026-93019 | 1 Tonycoz | 1 Imager | 2026-09-19 | 9.1 Critical |
| Imager versions before 1.036 for Perl exit the process reading a TGA with a colour map length of 32768 or more in tga_palette_read. The reader unpacks the two-byte colour map length into a signed short, so a length of 32768 or more becomes negative. tga_palette_read() casts that value to size_t and asks mymalloc() for a size near SIZE_MAX. The allocation fails and Imager's allocator calls exit(3). Reading an attacker-supplied file through Imager->read() triggers an uncatchable exit. | ||||
| CVE-2026-90109 | 1 Linux | 1 Linux Kernel | 2026-09-18 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: sched: fix 32-bit backlog wrap in gred, bfifo and plug enqueue gred_enqueue(), bfifo_enqueue() and plug_enqueue() admit a packet when the current backlog plus the packet length fits within the queue limit: sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (gred default VQ) gred_backlog+qdisc_pkt_len(skb) <= q->limit (gred configured VQ) sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (bfifo) sch->qstats.backlog + skb->len <= q->limit (plug) sch->qstats.backlog and q->backlog are u32, and qdisc_pkt_len()/skb->len are unsigned int, so all sums are computed in 32 bits and wrap at 2^32. Once the true backlog exceeds 4 GiB the wrapped sum becomes small and admission keeps succeeding, so the queue grows without bound and the kernel can be driven to OOM. Promote the sums to u64 so admission stops once the true backlog exceeds the limit. The limit is u32, so the bounded queue stays below 2^32 and the stored u32 backlog never wraps. The bug can only be reproduced as root (albeit with ridiculous setup): attach a gred (or bfifo/plug) qdisc with a limit near 4 GiB, leaving the default VQ unconfigured (for gred), and drive >4 GiB of queued traffic (e.g. via a size table / stab to inflate qdisc_pkt_len, or sustained high-rate traffic). The u32 backlog+len sum wraps at 2^32, admission keeps succeeding, and the queue grows unboundedly to OOM. | ||||
| CVE-2026-90136 | 1 Linux | 1 Linux Kernel | 2026-09-18 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/hsmp: Reject negative power cap writes in hwmon hsmp_hwmon_write() takes the user-supplied hwmon value as a signed long and assigns "val / MICROWATT_PER_MILLIWATT" to msg.args[0], which is a __u32. MICROWATT_PER_MILLIWATT is an unsigned long, so a negative write to power1_cap (e.g. "echo -1 > power1_cap") is first converted to a huge unsigned value by the division and then stored into the u32 argument. As a result a nonsensical, multi-gigawatt socket power limit is sent to the SMU via HSMP_SET_SOCKET_POWER_LIMIT instead of the write being rejected. Reject negative values with -EINVAL before the conversion. Tested with HSMP enabled: CAP=$(dirname $(grep -l amd_hsmp_hwmon \ /sys/class/hwmon/hwmon*/name | head -1))/power1_cap # negative write echo -1000000 > $CAP ; echo "ret=$?" # valid positive write must still work echo 400000000 > $CAP ; echo "ret=$?" Before: # echo -1000000 > $CAP ; echo "ret=$?" ret=0 <- accepted; bogus limit sent to SMU # echo 400000000 > $CAP ; echo "ret=$?" ret=0 After: # echo -1000000 > $CAP ; echo "ret=$?" bash: echo: write error: Invalid argument ret=1 <- rejected with -EINVAL # echo 400000000 > $CAP ; echo "ret=$?" ret=0 <- valid write still works | ||||
| CVE-2026-20248 | 1 Cisco | 2 Adaptive Security Appliance Software, Secure Firewall Threat Defense | 2026-09-18 | 6.8 Medium |
| A vulnerability in the DNS over TCP implementation of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Cisco Secure Firewall Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause the TCP DNS response handler to unexpectedly restart, causing the device to reload. This vulnerability is due to a logic error when parsing a DNS query and tracking the size of the incoming buffers. An attacker could exploit this vulnerability by formatting a crafted reply to a DNS query sent from the targeted device. A successful exploit could allow the attacker to cause the device to reload, causing a denial of service (DoS) condition. Note: The attacker must be able to respond to DNS queries from the device, either by controlling the DNS service or through a machine-in-the-middle attack. | ||||
| CVE-2026-11725 | 1 Ibm | 1 Mq | 2026-09-18 | 8.8 High |
| IBM MQ could allow an authenticated attacker to cause a denial of service or potentially execute arbitrary code due to an integer overflow in MQINQ request processing. | ||||
| CVE-2026-56711 | 1 Videolan | 1 Vlc Media Player | 2026-09-18 | 7 High |
| VLC media player versions 3.0.0 through 3.0.23 contain a memory-safety vulnerability reachable when processing crafted media. Exploitation requires user interaction and may result in application termination or code execution with the privileges of the VLC process. | ||||
| CVE-2025-6021 | 2 Redhat, Xmlsoft | 30 Discovery, Enterprise Linux, Enterprise Linux Eus and 27 more | 2026-09-18 | 7.5 High |
| A flaw was found in libxml2's xmlBuildQName function, where integer overflows in buffer size calculations can lead to a stack-based buffer overflow. This issue can result in memory corruption or a denial of service when processing crafted input. | ||||
| CVE-2026-46655 | 1 Virtio-win | 1 Kvm-guest-drivers-windows | 2026-09-18 | 7.8 High |
| virtio-win provides Windows paravirtualized drivers for QEMU and KVM. From mm210 until mm320, the Viosock driver permits a low-privilege local process to submit an IOCTL_SELECT request with attacker-controlled VIRTIO_VSOCK_SELECT.Fdss[*].fd_count values that overflow the 32-bit sum used by VIOSockSelect for bounds checking. The wrapped sum can pass the FD_SETSIZE check even though an individual descriptor count is much larger than the expected limit. VIOSockSelectCopyFds then iterates using the unchecked count and writes beyond the allocated pPkt->Fds array in the NonPagedPool kernel heap. Successful exploitation can corrupt kernel memory and enable privilege escalation in a Windows guest running the driver. This issue is fixed in mm320. | ||||
| CVE-2023-4734 | 3 Apple, Neovim, Vim | 3 Macos, Neovim, Vim | 2026-09-18 | 7.8 High |
| Integer Overflow or Wraparound in GitHub repository vim/vim prior to 9.0.1846. | ||||