Total
8655 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-39683 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-01-08 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: tracing: Limit access to parser->buffer when trace_get_user failed When the length of the string written to set_ftrace_filter exceeds FTRACE_BUFF_MAX, the following KASAN alarm will be triggered: BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165 CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0 The reason is that trace_get_user will fail when processing a string longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftrace_regex_release-> ftrace_process_regex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when trace_get_user failed. | ||||
| CVE-2025-39685 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-01-08 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: comedi: pcl726: Prevent invalid irq number The reproducer passed in an irq number(0x80008000) that was too large, which triggered the oob. Added an interrupt number check to prevent users from passing in an irq number that was too large. If `it->options[1]` is 31, then `1 << it->options[1]` is still invalid because it shifts a 1-bit into the sign bit (which is UB in C). Possible solutions include reducing the upper bound on the `it->options[1]` value to 30 or lower, or using `1U << it->options[1]`. The old code would just not attempt to request the IRQ if the `options[1]` value were invalid. And it would still configure the device without interrupts even if the call to `request_irq` returned an error. So it would be better to combine this test with the test below. | ||||
| CVE-2022-23130 | 2 Iconics, Mitsubishielectric | 3 Genesis64, Hyper Historian, Mc Works64 | 2026-01-08 | 5.9 Medium |
| Buffer Over-read vulnerability in Mitsubishi Electric MC Works64 versions 4.00A to 4.04E, Mitsubishi Electric GENESIS64 versions 10.97 and prior, Mitsubishi Electric Iconics Digital Solutions GENESIS64 versions 10.97 and prior, Mitsubishi Electric ICONICS Suite versions 10.97 and prior, Mitsubishi Electric Iconics Digital Solutions ICONICS Suite versions 10.97 and prior, Mitsubishi Electric GENESIS32 versions 9.7 and prior, and Mitsubishi Electric Iconics Digital Solutions GENESIS32 versions 9.7 and prior allows an attacker to cause a DoS condition in the database server by getting a legitimate user to import a configuration file containing specially crafted stored procedures into GENESIS64, ICONICS Suite, MC Works64, or GENESIS32 and execute commands against the database from GENESIS64, ICONICS Suite, MC Works64, or GENESIS32. | ||||
| CVE-2025-5918 | 2 Libarchive, Redhat | 4 Libarchive, Enterprise Linux, Openshift and 1 more | 2026-01-08 | 3.9 Low |
| A vulnerability has been identified in the libarchive library. This flaw can be triggered when file streams are piped into bsdtar, potentially allowing for reading past the end of the file. This out-of-bounds read can lead to unintended consequences, including unpredictable program behavior, memory corruption, or a denial-of-service condition. | ||||
| CVE-2025-62468 | 1 Microsoft | 9 Windows 11 23h2, Windows 11 23h2, Windows 11 24h2 and 6 more | 2026-01-07 | 5.5 Medium |
| Out-of-bounds read in Windows Defender Firewall Service allows an authorized attacker to disclose information locally. | ||||
| CVE-2025-55233 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-01-07 | 7.8 High |
| Out-of-bounds read in Windows Projected File System allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-62572 | 1 Microsoft | 5 Windows 11 24h2, Windows 11 24h2, Windows 11 25h2 and 2 more | 2026-01-07 | 7.8 High |
| Out-of-bounds read in Application Information Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-62564 | 1 Microsoft | 11 365 Apps, Excel, Excel 2016 and 8 more | 2026-01-07 | 7.8 High |
| Out-of-bounds read in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2025-62457 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-01-07 | 7.8 High |
| Out-of-bounds read in Windows Cloud Files Mini Filter Driver allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-48429 | 2 Grassroots Dicom Project, Malaterre | 2 Grassroots Dicom, Grassroots Dicom | 2026-01-07 | 7.4 High |
| An out-of-bounds read vulnerability exists in the RLECodec::DecodeByStreams functionality of Grassroot DICOM 3.024. A specially crafted DICOM file can lead to leaking heap data. An attacker can provide a malicious file to trigger this vulnerability. | ||||
| CVE-2022-32912 | 2 Apple, Redhat | 4 Ipados, Iphone Os, Safari and 1 more | 2026-01-07 | 8.8 High |
| An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in Safari 16, iOS 16, iOS 15.7 and iPadOS 15.7. Processing maliciously crafted web content may lead to arbitrary code execution. | ||||
| CVE-2025-65568 | 2 Omec-project, Opennetworking | 2 Upf, Upf | 2026-01-07 | 7.5 High |
| A denial-of-service vulnerability exists in the omec-project UPF (pfcpiface component) in version upf-epc-pfcpiface:2.1.3-dev. After PFCP association, a PFCP Session Establishment Request that includes a CreateFAR with an empty or truncated IPv4 address field is not properly validated. During parsing, parseFAR() calls ip2int(), which performs an out-of-bounds read on the IPv4 address buffer and triggers an index-out-of-range panic. An attacker who can send PFCP Session Establishment Request messages to the UPF's N4/PFCP endpoint can exploit this issue to repeatedly crash the UPF and disrupt user-plane services. | ||||
| CVE-2025-65567 | 2 Omec-project, Opennetworking | 2 Upf, Upf | 2026-01-07 | 7.5 High |
| A denial-of-service vulnerability exists in the omec-project UPF (pfcpiface component) in version upf-epc-pfcpiface:2.1.3-dev. After PFCP association, a specially crafted PFCP Session Establishment Request with a CreatePDR that contains a malformed Flow-Description is not robustly validated. The Flow-Description parser (parseFlowDesc) can read beyond the bounds of the provided buffer, causing a panic and terminating the UPF process. An attacker who can send PFCP Session Establishment Request messages to the UPF's N4/PFCP endpoint can exploit this issue to repeatedly crash the UPF. | ||||
| CVE-2025-39719 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-01-07 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: iio: imu: bno055: fix OOB access of hw_xlate array Fix a potential out-of-bounds array access of the hw_xlate array in bno055.c. In bno055_get_regmask(), hw_xlate was iterated over the length of the vals array instead of the length of the hw_xlate array. In the case of bno055_gyr_scale, the vals array is larger than the hw_xlate array, so this could result in an out-of-bounds access. In practice, this shouldn't happen though because a match should always be found which breaks out of the for loop before it iterates beyond the end of the hw_xlate array. By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be sure we are iterating over the correct length. | ||||
| CVE-2025-38529 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-01-07 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: comedi: aio_iiro_16: Fix bit shift out of bounds When checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & 0xdcfc) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. Valid `it->options[1]` values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts. | ||||
| CVE-2025-38530 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-01-07 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: comedi: pcl812: Fix bit shift out of bounds When checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & board->irq_bits) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. Valid `it->options[1]` values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts. | ||||
| CVE-2025-38652 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-01-07 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid out-of-boundary access in devs.path - touch /mnt/f2fs/012345678901234567890123456789012345678901234567890123 - truncate -s $((1024*1024*1024)) \ /mnt/f2fs/012345678901234567890123456789012345678901234567890123 - touch /mnt/f2fs/file - truncate -s $((1024*1024*1024)) /mnt/f2fs/file - mkfs.f2fs /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \ -c /mnt/f2fs/file - mount /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \ /mnt/f2fs/loop [16937.192225] F2FS-fs (loop0): Mount Device [ 0]: /mnt/f2fs/012345678901234567890123456789012345678901234567890123\xff\x01, 511, 0 - 3ffff [16937.192268] F2FS-fs (loop0): Failed to find devices If device path length equals to MAX_PATH_LEN, sbi->devs.path[] may not end up w/ null character due to path array is fully filled, So accidently, fields locate after path[] may be treated as part of device path, result in parsing wrong device path. struct f2fs_dev_info { ... char path[MAX_PATH_LEN]; ... }; Let's add one byte space for sbi->devs.path[] to store null character of device path string. | ||||
| CVE-2023-51791 | 2 Fedoraproject, Ffmpeg | 2 Fedora, Ffmpeg | 2026-01-07 | 7.8 High |
| Buffer Overflow vulenrability in Ffmpeg v.N113007-g8d24a28d06 allows a local attacker to execute arbitrary code via the libavcodec/jpegxl_parser.c in gen_alias_map. | ||||
| CVE-2025-41739 | 2 Codesys, Linux | 17 Control For Beaglebone Sl, Control For Empc-a/imx6 Sl, Control For Iot2000 Sl and 14 more | 2026-01-07 | 5.9 Medium |
| An unauthenticated remote attacker, who beats a race condition, can exploit a flaw in the communication servers of the CODESYS Control runtime system on Linux and QNX to trigger an out-of-bounds read via crafted socket communication, potentially causing a denial of service. | ||||
| CVE-2025-38502 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-01-07 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix oob access in cgroup local storage Lonial reported that an out-of-bounds access in cgroup local storage can be crafted via tail calls. Given two programs each utilizing a cgroup local storage with a different value size, and one program doing a tail call into the other. The verifier will validate each of the indivial programs just fine. However, in the runtime context the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the BPF program as well as any cgroup local storage flavor the program uses. Helpers such as bpf_get_local_storage() pick this up from the runtime context: ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype]; if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf); For the second program which was called from the originally attached one, this means bpf_get_local_storage() will pick up the former program's map, not its own. With mismatching sizes, this can result in an unintended out-of-bounds access. To fix this issue, we need to extend bpf_map_owner with an array of storage_cookie[] to match on i) the exact maps from the original program if the second program was using bpf_get_local_storage(), or ii) allow the tail call combination if the second program was not using any of the cgroup local storage maps. | ||||