Export limit exceeded: 339475 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 14263 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 42196 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (42196 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-25723 | 1 Gpac | 1 Gpac | 2025-09-25 | 8.4 High |
| Buffer Overflow vulnerability in GPAC version 2.5 allows a local attacker to execute arbitrary code. | ||||
| CVE-2025-23274 | 1 Nvidia | 2 Cuda Toolkit, Nvjpeg | 2025-09-25 | 4.5 Medium |
| NVIDIA nvJPEG contains a vulnerability in jpeg encoding where a user may cause an out-of-bounds read by providing a maliciously crafted input image with dimensions that cause integer overflows in array index calculations. A successful exploit of this vulnerability may lead to denial of service. | ||||
| CVE-2025-23272 | 1 Nvidia | 2 Cuda Toolkit, Nvjpeg | 2025-09-25 | 5.7 Medium |
| NVIDIA nvJPEG library contains a vulnerability where an attacker can cause an out-of-bounds read by means of a specially crafted JPEG file. A successful exploit of this vulnerability might lead to information disclosure or denial of service. | ||||
| CVE-2014-0779 | 1 Aveva | 1 Clearscada | 2025-09-24 | N/A |
| The PLC driver in ServerMain.exe in the Kepware KepServerEX 4 component in Schneider Electric StruxureWare SCADA Expert ClearSCADA 2010 R2 build 71.4165, 2010 R2.1 build 71.4325, 2010 R3 build 72.4560, 2010 R3.1 build 72.4644, 2013 R1 build 73.4729, 2013 R1.1 build 73.4832, 2013 R1.1a build 73.4903, 2013 R1.2 build 73.4955, and 2013 R2 build 74.5094 allows remote attackers to cause a denial of service (application crash) via a crafted OPF file (aka project file). | ||||
| CVE-2014-0777 | 1 Ioserver | 2 Ioserver Opc Server, Opc Drivers | 2025-09-24 | N/A |
| The Modbus slave/outstation driver in the OPC Drivers 1.0.20 and earlier in IOServer OPC Server allows remote attackers to cause a denial of service (out-of-bounds read and daemon crash) via a crafted packet. | ||||
| CVE-2014-0774 | 1 Schneider-electric | 6 Ofs Test Client Tlxcdlfofs33, Ofs Test Client Tlxcdltofs33, Ofs Test Client Tlxcdluofs33 and 3 more | 2025-09-24 | N/A |
| Stack-based buffer overflow in the C++ sample client in Schneider Electric OPC Factory Server (OFS) TLXCDSUOFS33 - 3.35, TLXCDSTOFS33 - 3.35, TLXCDLUOFS33 - 3.35, TLXCDLTOFS33 - 3.35, and TLXCDLFOFS33 - 3.35 allows local users to gain privileges via vectors involving a malformed configuration file. | ||||
| CVE-2024-35832 | 1 Linux | 1 Linux Kernel | 2025-09-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bcachefs: kvfree bch_fs::snapshots in bch2_fs_snapshots_exit bch_fs::snapshots is allocated by kvzalloc in __snapshot_t_mut. It should be freed by kvfree not kfree. Or umount will triger: [ 406.829178 ] BUG: unable to handle page fault for address: ffffe7b487148008 [ 406.830676 ] #PF: supervisor read access in kernel mode [ 406.831643 ] #PF: error_code(0x0000) - not-present page [ 406.832487 ] PGD 0 P4D 0 [ 406.832898 ] Oops: 0000 [#1] PREEMPT SMP PTI [ 406.833512 ] CPU: 2 PID: 1754 Comm: umount Kdump: loaded Tainted: G OE 6.7.0-rc7-custom+ #90 [ 406.834746 ] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [ 406.835796 ] RIP: 0010:kfree+0x62/0x140 [ 406.836197 ] Code: 80 48 01 d8 0f 82 e9 00 00 00 48 c7 c2 00 00 00 80 48 2b 15 78 9f 1f 01 48 01 d0 48 c1 e8 0c 48 c1 e0 06 48 03 05 56 9f 1f 01 <48> 8b 50 08 48 89 c7 f6 c2 01 0f 85 b0 00 00 00 66 90 48 8b 07 f6 [ 406.837810 ] RSP: 0018:ffffb9d641607e48 EFLAGS: 00010286 [ 406.838213 ] RAX: ffffe7b487148000 RBX: ffffb9d645200000 RCX: ffffb9d641607dc4 [ 406.838738 ] RDX: 000065bb00000000 RSI: ffffffffc0d88b84 RDI: ffffb9d645200000 [ 406.839217 ] RBP: ffff9a4625d00068 R08: 0000000000000001 R09: 0000000000000001 [ 406.839650 ] R10: 0000000000000001 R11: 000000000000001f R12: ffff9a4625d4da80 [ 406.840055 ] R13: ffff9a4625d00000 R14: ffffffffc0e2eb20 R15: 0000000000000000 [ 406.840451 ] FS: 00007f0a264ffb80(0000) GS:ffff9a4e2d500000(0000) knlGS:0000000000000000 [ 406.840851 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 406.841125 ] CR2: ffffe7b487148008 CR3: 000000018c4d2000 CR4: 00000000000006f0 [ 406.841464 ] Call Trace: [ 406.841583 ] <TASK> [ 406.841682 ] ? __die+0x1f/0x70 [ 406.841828 ] ? page_fault_oops+0x159/0x470 [ 406.842014 ] ? fixup_exception+0x22/0x310 [ 406.842198 ] ? exc_page_fault+0x1ed/0x200 [ 406.842382 ] ? asm_exc_page_fault+0x22/0x30 [ 406.842574 ] ? bch2_fs_release+0x54/0x280 [bcachefs] [ 406.842842 ] ? kfree+0x62/0x140 [ 406.842988 ] ? kfree+0x104/0x140 [ 406.843138 ] bch2_fs_release+0x54/0x280 [bcachefs] [ 406.843390 ] kobject_put+0xb7/0x170 [ 406.843552 ] deactivate_locked_super+0x2f/0xa0 [ 406.843756 ] cleanup_mnt+0xba/0x150 [ 406.843917 ] task_work_run+0x59/0xa0 [ 406.844083 ] exit_to_user_mode_prepare+0x197/0x1a0 [ 406.844302 ] syscall_exit_to_user_mode+0x16/0x40 [ 406.844510 ] do_syscall_64+0x4e/0xf0 [ 406.844675 ] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 406.844907 ] RIP: 0033:0x7f0a2664e4fb | ||||
| CVE-2021-3794 | 1 Vuelidate Project | 1 Vuelidate | 2025-09-24 | 7.5 High |
| vuelidate is vulnerable to Inefficient Regular Expression Complexity | ||||
| CVE-2024-50390 | 1 Qnap | 1 Qurouter | 2025-09-24 | 9.8 Critical |
| A command injection vulnerability has been reported to affect QHora. If exploited, the vulnerability could allow remote attackers to execute arbitrary commands. We have already fixed the vulnerability in the following version: QuRouter 2.4.5.032 and later | ||||
| CVE-2025-10803 | 1 Tenda | 2 Ac23, Ac23 Firmware | 2025-09-24 | 8.8 High |
| A vulnerability has been found in Tenda AC23 up to 16.03.07.52. Affected by this vulnerability is the function sscanf of the file /goform/SetPptpServerCfg of the component HTTP POST Request Handler. Such manipulation of the argument startIp leads to buffer overflow. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. | ||||
| CVE-2023-34488 | 1 Emqx | 1 Nanomq | 2025-09-24 | 8 High |
| NanoMQ 0.17.5 has a one-byte heap-based buffer over-read in the conn_handler function of mqtt_parser.c when it processes malformed messages. | ||||
| CVE-2022-36934 | 1 Whatsapp | 2 Whatsapp, Whatsapp Business | 2025-09-24 | 9.8 Critical |
| An integer overflow in WhatsApp could result in remote code execution in an established video call. | ||||
| CVE-2024-53041 | 1 Siemens | 2 Teamcenter Visualization, Tecnomatix Plant Simulation | 2025-09-24 | 7.8 High |
| A vulnerability has been identified in Teamcenter Visualization V14.2 (All versions < V14.2.0.14), Teamcenter Visualization V14.3 (All versions < V14.3.0.12), Teamcenter Visualization V2312 (All versions < V2312.0008), Tecnomatix Plant Simulation V2302 (All versions < V2302.0016), Tecnomatix Plant Simulation V2404 (All versions < V2404.0005). The affected applications contain a stack based overflow vulnerability while parsing specially crafted WRL files. This could allow an attacker to execute code in the context of the current process. (ZDI-CAN-25000) | ||||
| CVE-2024-53242 | 1 Siemens | 2 Teamcenter Visualization, Tecnomatix Plant Simulation | 2025-09-24 | 7.8 High |
| A vulnerability has been identified in Teamcenter Visualization V14.2 (All versions < V14.2.0.14), Teamcenter Visualization V14.3 (All versions < V14.3.0.12), Teamcenter Visualization V2312 (All versions < V2312.0008), Tecnomatix Plant Simulation V2302 (All versions < V2302.0016), Tecnomatix Plant Simulation V2404 (All versions < V2404.0005). The affected applications contain an out of bounds read past the end of an allocated structure while parsing specially crafted WRL files. This could allow an attacker to execute code in the context of the current process. (ZDI-CAN-25206) | ||||
| CVE-2021-47497 | 2 Linux, Redhat | 3 Linux Kernel, Enterprise Linux, Rhel Eus | 2025-09-24 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic *p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0); will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we subtract one from that making a large number that is then shifted more than the number of bits that fit into an unsigned long. UBSAN reports this problem: UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8 shift exponent 64 is too large for 64-bit type 'unsigned long' CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 nvmem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 component_bind_all+0xf0/0x264 msm_drm_bind+0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c component_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 really_probe+0x110/0x304 __driver_probe_device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv+0x90/0xdc __device_attach+0xc8/0x174 device_initial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 deferred_probe_work_func+0x7c/0xb8 process_one_work+0x128/0x21c process_scheduled_works+0x40/0x54 worker_thread+0x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20 Fix it by making sure there are any bits to mask out. | ||||
| CVE-2021-47496 | 1 Linux | 1 Linux Kernel | 2025-09-24 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net/tls: Fix flipped sign in tls_err_abort() calls sk->sk_err appears to expect a positive value, a convention that ktls doesn't always follow and that leads to memory corruption in other code. For instance, [kworker] tls_encrypt_done(..., err=<negative error from crypto request>) tls_err_abort(.., err) sk->sk_err = err; [task] splice_from_pipe_feed ... tls_sw_do_sendpage if (sk->sk_err) { ret = -sk->sk_err; // ret is positive splice_from_pipe_feed (continued) ret = actor(...) // ret is still positive and interpreted as bytes // written, resulting in underflow of buf->len and // sd->len, leading to huge buf->offset and bogus // addresses computed in later calls to actor() Fix all tls_err_abort() callers to pass a negative error code consistently and centralize the error-prone sign flip there, throwing in a warning to catch future misuse and uninlining the function so it really does only warn once. | ||||
| CVE-2024-48984 | 2 Arm, Mbed | 2 Mbed Os, Mbed | 2025-09-24 | 9.8 Critical |
| An issue was discovered in MBed OS 6.16.0. When parsing hci reports, the hci parsing software dynamically determines the length of a list of reports by reading a byte from an input stream. It then fetches the length of the first report, uses it to calculate the beginning of the second report, etc. In doing this, it tracks the largest report so it can later allocate a buffer that fits every individual report (but only one at a time). It does not, however, validate that these addresses are all contained within the buffer passed to hciEvtProcessLeExtAdvReport. It is then possible, though unlikely, that the buffer designated to hold the reports is allocated in such a way that one of these out-of-bounds length fields is contained within the new buffer. When the (n-1)th report is copied, it overwrites the length field of the nth report. This now corrupted length field is then used for a memcpy into the new buffer, which may lead to a buffer overflow. | ||||
| CVE-2021-47474 | 1 Linux | 1 Linux Kernel | 2025-09-24 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: comedi: vmk80xx: fix bulk-buffer overflow The driver is using endpoint-sized buffers but must not assume that the tx and rx buffers are of equal size or a malicious device could overflow the slab-allocated receive buffer when doing bulk transfers. | ||||
| CVE-2021-47465 | 1 Linux | 1 Linux Kernel | 2025-09-24 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest() In commit 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C") kvm_start_guest() became idle_kvm_start_guest(). The old code allocated a stack frame on the emergency stack, but didn't use the frame to store anything, and also didn't store anything in its caller's frame. idle_kvm_start_guest() on the other hand is written more like a normal C function, it creates a frame on entry, and also stores CR/LR into its callers frame (per the ABI). The problem is that there is no caller frame on the emergency stack. The emergency stack for a given CPU is allocated with: paca_ptrs[i]->emergency_sp = alloc_stack(limit, i) + THREAD_SIZE; So emergency_sp actually points to the first address above the emergency stack allocation for a given CPU, we must not store above it without first decrementing it to create a frame. This is different to the regular kernel stack, paca->kstack, which is initialised to point at an initial frame that is ready to use. idle_kvm_start_guest() stores the backchain, CR and LR all of which write outside the allocation for the emergency stack. It then creates a stack frame and saves the non-volatile registers. Unfortunately the frame it creates is not large enough to fit the non-volatiles, and so the saving of the non-volatile registers also writes outside the emergency stack allocation. The end result is that we corrupt whatever is at 0-24 bytes, and 112-248 bytes above the emergency stack allocation. In practice this has gone unnoticed because the memory immediately above the emergency stack happens to be used for other stack allocations, either another CPUs mc_emergency_sp or an IRQ stack. See the order of calls to irqstack_early_init() and emergency_stack_init(). The low addresses of another stack are the top of that stack, and so are only used if that stack is under extreme pressue, which essentially never happens in practice - and if it did there's a high likelyhood we'd crash due to that stack overflowing. Still, we shouldn't be corrupting someone else's stack, and it is purely luck that we aren't corrupting something else. To fix it we save CR/LR into the caller's frame using the existing r1 on entry, we then create a SWITCH_FRAME_SIZE frame (which has space for pt_regs) on the emergency stack with the backchain pointing to the existing stack, and then finally we switch to the new frame on the emergency stack. | ||||
| CVE-2025-10824 | 1 Axboe | 1 Fio | 2025-09-24 | 5.3 Medium |
| A vulnerability was determined in axboe fio up to 3.41. This impacts the function __parse_jobs_ini of the file init.c. Executing manipulation can lead to use after free. The attack needs to be launched locally. The exploit has been publicly disclosed and may be utilized. | ||||