Export limit exceeded: 413914 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (53669 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-12665 | 1 Ibm | 3 Mq Advanced Container Images, Mq Operator, Supplied Mq Advanced Container Images | 2026-10-23 | 8.1 High |
| IBM MQ could allow a remote attacker to execute arbitrary code due to a stack buffer overflow when processing TLS certificates with malformed distinguished names during channel connection establishment. | ||||
| CVE-2026-12669 | 1 Ibm | 3 Mq Advanced Container Images, Mq Operator, Supplied Mq Advanced Container Images | 2026-10-23 | 3.1 Low |
| IBM MQ could allow an authenticated attacker to trigger a minor out-of-bounds read when sending malformed compressed data, though the data is not disclosed and the request is rejected. | ||||
| CVE-2026-99085 | 1 Linux | 1 Linux Kernel | 2026-10-23 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix CPU hotplug hang when a dying CPU's tasks sit in the BPF scheduler A CPU going down has to empty its own rq. Its hotplug thread waits in sched_cpu_wait_empty() until nothing else is left, and the only thing that wakes it is balance_push(), which runs from __schedule() on the dying CPU and pushes off the migratable tasks the CPU picks. sched_ext breaks this. A task sitting on a user DSQ or held by the BPF scheduler is still counted on its rq, but an inactive CPU no longer calls ops.dispatch() and can't pull the task back. The dying CPU goes idle with the task still counted, and one of two things happens: - Another CPU consumes the task. The rq empties without a __schedule() on the dying CPU, so the hotplug thread is never woken and cpu_down() hangs holding cpu_hotplug_lock. - The task is affine only to the dying CPU. Nothing can move it, and the offline stalls until the watchdog ejects the BPF scheduler. When the rq goes offline, re-enqueue every task on it that isn't already on the local DSQ. An enqueue on an offline rq lands on the local DSQ, so the dying CPU itself picks the tasks and balance_push() pushes them off, the same as for the other sched classes. From then on no sched_ext path on another CPU can pull a task off the rq. ops.dispatch() currently stops as soon as the CPU goes inactive, and CPU hotplug then waits for an RCU grace period before taking the rq offline. A BPF-held task affine only to the dying CPU and preempted inside an RCU read-side critical section would block that grace period, and the rq would never go offline. Test SCX_RQ_ONLINE directly so that ops.dispatch() keeps running until the rq goes offline. Only the dying CPU's own hotplug thread clears the flag during teardown, and task_can_run_on_remote_rq() still keeps other rqs' tasks off the CPU. | ||||
| CVE-2026-85827 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-23 | 7 High |
| Heap-based buffer overflow in WebDAV allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-85830 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-23 | 5.5 Medium |
| Out-of-bounds read in Windows Installer allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-85871 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-23 | 7.8 High |
| Heap-based buffer overflow in Windows Kernel-Mode Drivers allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-12727 | 1 Ibm | 3 Mq Advanced Container Images, Mq Operator, Supplied Mq Advanced Container Images | 2026-10-23 | 4.3 Medium |
| IBM MQ could allow an authenticated attacker to cause potential process instability due to an off-by-one buffer overflow when processing specially crafted object names. | ||||
| CVE-2026-99002 | 1 Linux | 1 Linux Kernel | 2026-10-23 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate pitch coming from userspace Validate the pitch, alongside the box dimensions before trying to copy data from the underlying surface. Fixes possible out of bounds reads with cursor snooping. | ||||
| CVE-2026-85791 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-23 | 7 High |
| Heap-based buffer overflow in Windows Encrypting File System (EFS) allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-85796 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-23 | 7.8 High |
| Numeric truncation error in Windows Installer allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-85800 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-23 | 7.8 High |
| Heap-based buffer overflow in Windows Error Reporting allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-85814 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-23 | 9.8 Critical |
| Heap-based buffer overflow in Microsoft Windows Media Foundation allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-99063 | 1 Linux | 1 Linux Kernel | 2026-10-23 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: dm ioctl: don't let data_start run past the buffer struct dm_ioctl has seven bytes of trailing padding, so the smallest buffer userspace is allowed to ask for, offsetof(struct dm_ioctl, data), is seven bytes shorter than sizeof(struct dm_ioctl). get_result_buffer() sets data_start to sizeof(struct dm_ioctl) without looking at how big the buffer actually is. Ask for the minimum and data_start ends up seven bytes past the end. Callers add it to data_size, and ctl_ioctl() copies that much back to userspace: BUG: KASAN: slab-out-of-bounds in _copy_to_user+0xad/0xd0 Read of size 312 at addr ffff8880169e4c00 by task repro-dm/140 ctl_ioctl+0x5e3/0xcb0 dm_ctl_ioctl+0x25/0x40 allocated 305-byte region [ffff8880169e4c00, ffff8880169e4d31) A DM_LIST_DEVICES with data_size set to 305 is enough to hit it, and the seven bytes that leak are whatever sat next to the allocation. Clamp data_start to the buffer size. Note that this is not a security bug because the out-of-bounds read can only be triggered by root. | ||||
| CVE-2026-99081 | 1 Linux | 1 Linux Kernel | 2026-10-23 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: bnxt_en: fix DMA mapping length for padded small packets Stefan Fleischmann reported Intel IOMMU DMA Read faults on BCM57412 NetXtreme-E NICs when transmitting packets on VLAN/macvlan interfaces: DMAR: [DMA Read NO_PASID] Request device [18:00.0] fault addr 0xfc499000 [fault reason 0x06] PTE Read access is not set bnxt_en 0000:18:00.0 eno1np0: Abandoning msg {0xb4 0x41a} len: 0 due to firmware status: 0x2000001 ... NETDEV WATCHDOG: eno1np0 (bnxt_en): transmit queue 0 timed out The fault address (0xfc499000) is on an exact 4KB page boundary, pointing to a DMA read buffer overrun. In bnxt_start_xmit(), packets smaller than BNXT_MIN_PKT_SIZE (52 bytes), such as 42-byte untagged ARP frames, are padded: if (length < BNXT_MIN_PKT_SIZE) { pad = BNXT_MIN_PKT_SIZE - length; if (skb_pad(skb, pad)) goto tx_kick_pending; length = BNXT_MIN_PKT_SIZE; } mapping = dma_map_single(&pdev->dev, skb->data, len, DMA_TO_DEVICE); ... dma_unmap_len_set(tx_buf, len, len); However, 'len' was initialized earlier to skb_headlen(skb) (e.g. 42 bytes) and is left unadjusted after padding. Consequently, dma_map_single() and dma_unmap_len_set() map and track only 42 bytes. Later, the hardware TX buffer descriptor is programmed with the padded length: txbd->tx_bd_len_flags_type = cpu_to_le32(((len + pad) << TX_BD_LEN_SHIFT) | flags | TX_BD_FLAGS_PACKET_END); The NIC DMA engine is thus instructed to read 52 bytes from a region where only 42 bytes were DMA-mapped. If skb->data ends near the boundary of a 4KB page (within 'pad' bytes of the next page), the hardware DMA read overruns into the unmapped adjacent page, triggering an IOMMU fault. This issue was exposed after commit 447cbe95ebb9 ("vlan: fix skb_under_panic and races when toggling HW VLAN offload") because reserving extra VLAN headroom rounded LL_RESERVED_SPACE from 48 up to 64 bytes, shifting skb->data offsets and potentially causing small frames to land right against page boundaries. Fix this by using skb_put_padto(skb, BNXT_MIN_PKT_SIZE) in bnxt_start_xmit(), before skb_shinfo(skb)->nr_frags is sampled, because padding might linearize the skb. This ensures skb->len and skb_headlen(skb) reflect the padded size so that dma_map_single() maps the full buffer and the descriptor length is consistent. This also removes the temporary 'pad' variable and masking logic. The padding is done after the SW USO branch, otherwise bnxt_sw_udp_gso_xmit() would account the padding as UDP payload and send it in extra segments. Note that SW USO segments are still not padded: with IPv4, a segment carrying less than 10 bytes of UDP payload (small gso_size, or a short last segment) is sent as a frame shorter than BNXT_MIN_PKT_SIZE. This is a separate issue, left for a followup patch. | ||||
| CVE-2026-99083 | 1 Linux | 1 Linux Kernel | 2026-10-23 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix heap out-of-bounds write in krb5_authenticate() In krb5_authenticate(), out_len is calculated to determine available headroom in response_buf for the incoming Kerberos AP-REP token. However, when SMB2_SESSION_SETUP is processed as a non-first element of a compounded SMB2 request, the calculation omits work->next_smb2_rsp_hdr_off. This causes out_len to overstate remaining buffer headroom by the cumulative size of prior responses in the compound chain. Consequently, the length check in ksmbd_krb5_authenticate() (*out_len <= resp->spnego_blob_len) passes erroneously, allowing memcpy() to write the AP-REP blob past the end of response_buf into adjacent kernel heap memory. Fix this by subtracting work->next_smb2_rsp_hdr_off when computing out_len, ensuring it accurately reflects physical remaining buffer space. | ||||
| CVE-2026-83911 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-23 | 7 High |
| Heap-based buffer overflow in Windows Storage allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-84014 | 1 Microsoft | 27 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 24 more | 2026-10-23 | 7 High |
| Heap-based buffer overflow in Windows Device Association Service allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-85323 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows Server 2012 and 11 more | 2026-10-23 | 6.8 Medium |
| Weak authentication in Network Device Enrollment Service (NDES) allows an authorized attacker to perform spoofing over a network. | ||||
| CVE-2026-85353 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-23 | 7.5 High |
| Out-of-bounds read in Windows Print Spooler Components allows an unauthorized attacker to disclose information over a network. | ||||
| CVE-2026-83518 | 1 Microsoft | 8 Windows 11 23h2, Windows 11 23h2, Windows 11 24h2 and 5 more | 2026-10-23 | 7.8 High |
| Heap-based buffer overflow in RPC Runtime allows an authorized attacker to elevate privileges locally. | ||||