Export limit exceeded: 10030 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (10030 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-23310 | 1 Linux | 1 Linux Kernel | 2026-11-05 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf/bonding: reject vlan+srcmac xmit_hash_policy change when XDP is loaded bond_option_mode_set() already rejects mode changes that would make a loaded XDP program incompatible via bond_xdp_check(). However, bond_option_xmit_hash_policy_set() has no such guard. For 802.3ad and balance-xor modes, bond_xdp_check() returns false when xmit_hash_policy is vlan+srcmac, because the 802.1q payload is usually absent due to hardware offload. This means a user can: 1. Attach a native XDP program to a bond in 802.3ad/balance-xor mode with a compatible xmit_hash_policy (e.g. layer2+3). 2. Change xmit_hash_policy to vlan+srcmac while XDP remains loaded. This leaves bond->xdp_prog set but bond_xdp_check() now returning false for the same device. When the bond is later destroyed, dev_xdp_uninstall() calls bond_xdp_set(dev, NULL, NULL) to remove the program, which hits the bond_xdp_check() guard and returns -EOPNOTSUPP, triggering: WARN_ON(dev_xdp_install(dev, mode, bpf_op, NULL, 0, NULL)) Fix this by rejecting xmit_hash_policy changes to vlan+srcmac when an XDP program is loaded on a bond in 802.3ad or balance-xor mode. commit 39a0876d595b ("net, bonding: Disallow vlan+srcmac with XDP") introduced bond_xdp_check() which returns false for 802.3ad/balance-xor modes when xmit_hash_policy is vlan+srcmac. The check was wired into bond_xdp_set() to reject XDP attachment with an incompatible policy, but the symmetric path -- preventing xmit_hash_policy from being changed to an incompatible value after XDP is already loaded -- was left unguarded in bond_option_xmit_hash_policy_set(). Note: commit 094ee6017ea0 ("bonding: check xdp prog when set bond mode") later added a similar guard to bond_option_mode_set(), but bond_option_xmit_hash_policy_set() remained unprotected. | ||||
| CVE-2026-23244 | 1 Linux | 1 Linux Kernel | 2026-11-05 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: nvme: fix memory allocation in nvme_pr_read_keys() nvme_pr_read_keys() takes num_keys from userspace and uses it to calculate the allocation size for rse via struct_size(). The upper limit is PR_KEYS_MAX (64K). A malicious or buggy userspace can pass a large num_keys value that results in a 4MB allocation attempt at most, causing a warning in the page allocator when the order exceeds MAX_PAGE_ORDER. To fix this, use kvzalloc() instead of kzalloc(). This bug has the same reasoning and fix with the patch below: https://lore.kernel.org/linux-block/20251212013510.3576091-1-kartikey406@gmail.com/ Warning log: WARNING: mm/page_alloc.c:5216 at __alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216, CPU#1: syz-executor117/272 Modules linked in: CPU: 1 UID: 0 PID: 272 Comm: syz-executor117 Not tainted 6.19.0 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:__alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216 Code: ff 83 bd a8 fe ff ff 0a 0f 86 69 fb ff ff 0f b6 1d f9 f9 c4 04 80 fb 01 0f 87 3b 76 30 ff 83 e3 01 75 09 c6 05 e4 f9 c4 04 01 <0f> 0b 48 c7 85 70 fe ff ff 00 00 00 00 e9 8f fd ff ff 31 c0 e9 0d RSP: 0018:ffffc90000fcf450 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1ffff920001f9ea0 RDX: 0000000000000000 RSI: 000000000000000b RDI: 0000000000040dc0 RBP: ffffc90000fcf648 R08: ffff88800b6c3380 R09: 0000000000000001 R10: ffffc90000fcf840 R11: ffff88807ffad280 R12: 0000000000000000 R13: 0000000000040dc0 R14: 0000000000000001 R15: ffffc90000fcf620 FS: 0000555565db33c0(0000) GS:ffff8880be26c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000000c CR3: 0000000003b72000 CR4: 00000000000006f0 Call Trace: <TASK> alloc_pages_mpol+0x236/0x4d0 mm/mempolicy.c:2486 alloc_frozen_pages_noprof+0x149/0x180 mm/mempolicy.c:2557 ___kmalloc_large_node+0x10c/0x140 mm/slub.c:5598 __kmalloc_large_node_noprof+0x25/0xc0 mm/slub.c:5629 __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x483/0x6f0 mm/slub.c:5669 kmalloc_noprof include/linux/slab.h:961 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] nvme_pr_read_keys+0x8f/0x4c0 drivers/nvme/host/pr.c:245 blkdev_pr_read_keys block/ioctl.c:456 [inline] blkdev_common_ioctl+0x1b71/0x29b0 block/ioctl.c:730 blkdev_ioctl+0x299/0x700 block/ioctl.c:786 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x1bf/0x220 fs/ioctl.c:583 x64_sys_call+0x1280/0x21b0 mnt/fuzznvme_1/fuzznvme/linux-build/v6.19/./arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x71/0x330 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fb893d3108d Code: 28 c3 e8 46 1e 00 00 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffff61f2f38 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffff61f3138 RCX: 00007fb893d3108d RDX: 0000000020000040 RSI: 00000000c01070ce RDI: 0000000000000003 RBP: 0000000000000001 R08: 0000000000000000 R09: 00007ffff61f3138 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007ffff61f3128 R14: 00007fb893dae530 R15: 0000000000000001 </TASK> | ||||
| CVE-2026-23187 | 1 Linux | 1 Linux Kernel | 2026-11-05 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx8m-blk-ctrl: fix out-of-range access of bc->domains Fix out-of-range access of bc->domains in imx8m_blk_ctrl_remove(). | ||||
| CVE-2026-23102 | 1 Linux | 1 Linux Kernel | 2026-11-05 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: signal: Fix restoration of SVE context When SME is supported, Restoring SVE signal context can go wrong in a few ways, including placing the task into an invalid state where the kernel may read from out-of-bounds memory (and may potentially take a fatal fault) and/or may kill the task with a SIGKILL. (1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into an invalid state where SVCR.SM is set (and sve_state is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL. This can only occur in unusual (but legitimate) cases where the SVE signal context has either been modified by userspace or was saved in the context of another task (e.g. as with CRIU), as otherwise the presence of an SVE signal context with SVE_SIG_FLAG_SM implies that TIF_SME is already set. While in this state, task_fpsimd_load() will NOT configure SMCR_ELx (leaving some arbitrary value configured in hardware) before restoring SVCR and attempting to restore the streaming mode SVE registers from memory via sve_load_state(). As the value of SMCR_ELx.LEN may be larger than the task's streaming SVE vector length, this may read memory outside of the task's allocated sve_state, reading unrelated data and/or triggering a fault. While this can result in secrets being loaded into streaming SVE registers, these values are never exposed. As TIF_SME is clear, fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0 accesses to streaming mode SVE registers, so these cannot be accessed directly at EL0. As fpsimd_save_user_state() verifies the live vector length before saving (S)SVE state to memory, no secret values can be saved back to memory (and hence cannot be observed via ptrace, signals, etc). When the live vector length doesn't match the expected vector length for the task, fpsimd_save_user_state() will send a fatal SIGKILL signal to the task. Hence the task may be killed after executing userspace for some period of time. (2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV. This can only occur in unusual (but legitimate) cases where ptrace has been used to set SVCR.SM after entry to the sigreturn syscall, as syscall entry clears SVCR.SM. In these cases, the the provided SVE register data will be loaded into the task's sve_state using the non-streaming SVE vector length and the FPSIMD registers will be merged into this using the streaming SVE vector length. Fix (1) by setting TIF_SME when setting SVCR.SM. This also requires ensuring that the task's sme_state has been allocated, but as this could contain live ZA state, it should not be zeroed. Fix (2) by clearing SVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear. For consistency, I've pulled the manipulation of SVCR, TIF_SVE, TIF_SME, and fp_type earlier, immediately after the allocation of sve_state/sme_state, before the restore of the actual register state. This makes it easier to ensure that these are always modified consistently, even if a fault is taken while reading the register data from the signal context. I do not expect any software to depend on the exact state restored when a fault is taken while reading the context. | ||||
| CVE-2026-115795 | 1 Rt-labs | 1 P-net | 2026-11-05 | N/A |
| P-Net before 1.0.3 does not check that a complete block header is present in the received data before reading the next block in DCP Set and Identify requests. If the last block ends at the end of the receive buffer, the block length of the following block is read past the end of the buffer. In addition, a DCP Set block with a length smaller than the two-byte block qualifier makes the length underflow, so the block is processed with a length of 65534 bytes. This can cause a crash (denial of service) or disclose a small amount of memory content. Requires ADJACENT network access. | ||||
| CVE-2026-111735 | 1 Rt-labs | 1 P-net | 2026-11-05 | N/A |
| P-Net before 1.0.3 contains an integer underflow in pf_cpm_c_data_ind(). When handling a received cyclic data frame while the consumer is in the FRUN or RUN state, the offset of the APDU status was computed as the frame length minus 4 using 16-bit arithmetic, without checking that the frame is long enough. A crafted short frame makes the offset wrap around, so the function reads outside the receive buffer. This can cause a crash (denial of service) or disclose memory content. | ||||
| CVE-2026-111734 | 1 Rt-labs | 1 P-net | 2026-11-05 | N/A |
| P-Net before 1.0.3 does not validate the length of a received Ethernet frame in pf_eth_recv() before reading the EtherType, any VLAN tags and the PROFINET FrameID. The VLAN tag loop had no upper bound, so a truncated frame, or a frame consisting only of VLAN tags, makes the function read past the end of the receive buffer. This can cause a crash (denial of service) or disclose memory content. | ||||
| CVE-2025-71231 | 1 Linux | 1 Linux Kernel | 2026-11-05 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix out-of-bounds index in find_empty_iaa_compression_mode The local variable 'i' is initialized with -EINVAL, but the for loop immediately overwrites it and -EINVAL is never returned. If no empty compression mode can be found, the function would return the out-of-bounds index IAA_COMP_MODES_MAX, which would cause an invalid array access in add_iaa_compression_mode(). Fix both issues by returning either a valid index or -EINVAL. | ||||
| CVE-2025-39853 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-11-05 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: i40e: Fix potential invalid access when MAC list is empty list_first_entry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced. Fix this by using list_first_entry_or_null instead of list_first_entry. | ||||
| CVE-2025-39823 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-11-05 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: KVM: x86: use array_index_nospec with indices that come from guest min and dest_id are guest-controlled indices. Using array_index_nospec() after the bounds checks clamps these values to mitigate speculative execution side-channels. | ||||
| CVE-2025-38680 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-11-05 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format() The buffer length check before calling uvc_parse_format() only ensured that the buffer has at least 3 bytes (buflen > 2), buf the function accesses buffer[3], requiring at least 4 bytes. This can lead to an out-of-bounds read if the buffer has exactly 3 bytes. Fix it by checking that the buffer has at least 4 bytes in uvc_parse_format(). | ||||
| CVE-2025-38636 | 1 Linux | 1 Linux Kernel | 2026-11-05 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: rv: Use strings in da monitors tracepoints Using DA monitors tracepoints with KASAN enabled triggers the following warning: BUG: KASAN: global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 Read of size 32 at addr ffffffffaada8980 by task ... Call Trace: <TASK> [...] do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10 ? trace_event_sncid+0x83/0x200 trace_event_sncid+0x163/0x200 [...] The buggy address belongs to the variable: automaton_snep+0x4e0/0x5e0 This is caused by the tracepoints reading 32 bytes __array instead of __string from the automata definition. Such strings are literals and reading 32 bytes ends up in out of bound memory accesses (e.g. the next automaton's data in this case). The error is harmless as, while printing the string, we stop at the null terminator, but it should still be fixed. Use the __string facilities while defining the tracepoints to avoid reading out of bound memory. | ||||
| CVE-2026-66759 | 2 Gimp, Redhat | 3 Gimp, Enterprise Linux, Rhel Els | 2026-11-05 | 7.1 High |
| A flaw was found in the file-icns plugin in GIMP. When applying a decompressed mask during ICNS image processing, the plugin reads from the mask data buffer without verifying if the cursor exceeds the allocated resource size. If a crafted file contains a truncated mask resource, the icns_decompress function continues reading past the bounds of the buffer. This out-of-bounds read vulnerability results in information disclosure of heap contents, where memory contents are leaked as alpha channel pixel values, or a crash leading to a denial of service if unmapped memory is accessed. | ||||
| CVE-2026-66337 | 3 Gnome, Libsoup, Redhat | 4 Libsoup, Libsoup, Enterprise Linux and 1 more | 2026-11-05 | 6.5 Medium |
| A flaw was found in libsoup. An unsigned integer underflow in the soup_filter_input_stream_read_until() function causes a heap buffer over-read when parsing multipart HTTP responses. A malicious HTTP server can exploit this by sending a crafted multipart response, potentially causing the client application to crash or disclose sensitive heap memory. | ||||
| CVE-2026-6694 | 2 Gimp, Redhat | 3 Gimp, Enterprise Linux, Rhel Els | 2026-11-05 | 5.5 Medium |
| A flaw was found in GIMP's file-png plugin. A remote attacker can exploit this by crafting a malicious Animated Portable Network Graphics (APNG) image containing an oversized tRNS chunk. This can lead to a stack-based buffer overflow (CWE-121), causing the file-png plugin to crash and resulting in a Denial of Service (DoS) for the user. | ||||
| CVE-2026-123205 | 1 Accel-ppp | 1 Accel-ppp | 2026-11-05 | 6.5 Medium |
| accel-ppp before 1.15.0 contains a heap buffer overflow vulnerability in the tcp, syslog and pgsql log targets that allows unauthenticated remote peers to overflow fixed heap buffers by producing log lines exceeding LOG_MAX_SIZE. Attackers within client-ip-range can send an L2TP Start-Control-Connection-Request with many string AVPs when verbose logging is enabled to corrupt heap memory and crash the daemon. | ||||
| CVE-2026-6420 | 1 Redhat | 1 Enterprise Linux | 2026-11-05 | 6.3 Medium |
| A flaw was found in Keylime. An attacker with root access on an enrolled monitored machine, where the Keylime agent runs, can exploit a vulnerability in the Keylime verifier. The verifier uses a hardcoded challenge nonce for Trusted Platform Module (TPM) quote attestation instead of a cryptographically random value. This allows the attacker to stockpile valid TPM quotes and replay them to evade detection after compromising the system. This issue affects only the push model deployment. | ||||
| CVE-2026-112532 | 1 Apple | 1 Macos | 2026-11-05 | 7.8 High |
| The issue was addressed with improved memory handling. This issue is fixed in macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. An app may be able to cause unexpected system termination or corrupt kernel memory. | ||||
| CVE-2026-53704 | 2 Gstreamer Project, Redhat | 5 Gstreamer Plugin, Enterprise Linux, Enterprise Linux Eus and 2 more | 2026-11-05 | 7.1 High |
| A flaw was found in GStreamer's RealMedia demuxer in the gst-plugins-ugly package. When processing a RealMedia file containing a specially crafted FILEINFO metadata section, the demuxer parses variable-name and variable-value pairs using re_skip_pascal_string() without validating that offsets remain within the mapped buffer. Additionally, the element count controlling the parsing loop is read from attacker-controlled data without validation, which can cause an infinite loop. A crafted RealMedia file can cause the application to crash, hang, or potentially read limited adjacent memory contents. | ||||
| CVE-2026-53703 | 2 Gstreamer, Redhat | 5 Gstreamer, Enterprise Linux, Enterprise Linux Eus and 2 more | 2026-11-05 | 7.1 High |
| A vulnerability was found in the GStreamer RealMedia demuxer (gst-plugins-ugly). When processing a RealMedia (.rm) file, the demuxer parses MDPR (media properties) chunks to configure audio streams. For audio stream header versions 4 and 5, the parser reads fields such as codec type, packet size, sample rate, channel count, and extra codec data length from fixed offsets within the chunk without first checking that the chunk contains enough data. If a malicious file provides an MDPR chunk that is too small to contain a complete audio stream header, the parser reads beyond the end of the buffer. This can cause the application to crash. In some cases, bytes read past the buffer boundary may be incorporated into stream metadata, which could result in limited information disclosure. | ||||