Total
32 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-53126 | 1 Linux | 1 Linux Kernel | 2026-08-04 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf(). | ||||
| CVE-2024-50222 | 1 Linux | 1 Linux Kernel | 2026-08-04 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed? | ||||
| CVE-2026-16441 | 1 Eclipse | 1 Openj9 | 2026-07-22 | N/A |
| In Eclipse OpenJ9 versions up to 0.60, when executing class files where a previously concrete superclass method has been recompiled as abstract, execution is incorrectly delegated to an interface default method. | ||||
| CVE-2026-50185 | 1 Rustcrypto | 1 Utils | 2026-07-20 | N/A |
| RustCrypto CMOV provides conditional move CPU intrinsics which are guaranteed on major platforms to execute in constant-time and not be rewritten as branches by the compiler. From 0.1.1 until 0.5.4, the aarch64 implementations of Cmov and CmovEq in cmov/src/backends/aarch64.rs assume high bits are zero-extended when loading values smaller than a register, so set high bits such as [8..] in a Cmov selector or [16..] of self or other in the u16 and i16 CmovEq implementations can cause left.cmovz(&right, condition) to produce incorrect output. This issue is fixed in version 0.5.4. | ||||
| CVE-2026-53231 | 1 Linux | 1 Linux Kernel | 2026-06-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: phy: don't try to setup PHY-driven SFP cages when using genphy We don't have support for PHY-driver SFP cages with the genphy code. On top of that, it was found by sashiko that running sfp_bus_add_upstream() for genphy deadlocks, as for genphy the PHY probing runs under RTNL, which isn't the case for non-genphy drivers. This problem was reproduced, and does lead to a deadlock on RTNL. Before the blamed commit, the phy_sfp_probe() call was made by individual PHY drivers, so there was no way to get to the SFP probing path when using genphy. Let's therefore only run phy_sfp_probe when not using genphy. | ||||
| CVE-2026-53029 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: prevent uninitialized lcn caused by zero len syzbot reported a uninit-value in ntfs_iomap_begin [1]. Since runs was not touched yet, run_lookup_entry() immediately fails and returns false, which makes the value of "*len" 0. Simultaneously, the new value and err value are also 0, causing the logic in attr_data_get_block_locked() to jump directly to ok, ultimately resulting in *lcn being triggered before it is set [1]. In ntfs_iomap_begin(), the check for a 0 value in clen is moved forward to before updating lcn to avoid this [1]. [1] BUG: KMSAN: uninit-value in ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825 ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825 iomap_iter+0x9b7/0x1540 fs/iomap/iter.c:110 Local variable lcn created at: ntfs_iomap_begin+0x15d/0x1460 fs/ntfs3/inode.c:786 | ||||
| CVE-2024-58350 | 1 Nsa | 1 Ghidra | 2026-06-10 | 2.9 Low |
| Ghidra before 11.2 contains a use after free vulnerability in the Sleigh backend caused by undefined static initialization order of the SleighArchitecture::translators and XmlArchitectureCapability singletons. Attackers can trigger an infinite loop or denial of service during shutdown by exploiting the unsafe destruction order that causes iteration over deallocated memory. | ||||
| CVE-2026-46315 | 1 Linux | 1 Linux Kernel | 2026-06-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: io_uring/waitid: clear waitid info before copying it to userspace IORING_OP_WAITID stores its result fields in struct io_waitid::info and later copies them to userspace siginfo. The prep path initializes the request arguments, but it does not initialize info itself. If the wait operation completes without reporting a child event, the common wait code can return without writing wo_info. In that case io_waitid_finish() still copies iw->info to userspace, exposing stale bytes from the reused io_kiocb command storage. Clear the result storage during prep so the io_uring path matches the regular waitid syscall, which uses a zero-initialized struct waitid_info. | ||||
| CVE-2026-40279 | 1 Bacnetstack | 1 Bacnet Stack | 2026-04-27 | 3.7 Low |
| BACnet Stack is a BACnet open source protocol stack C library for embedded systems. Prior to 1.4.3, decode_signed32() in src/bacnet/bacint.c reconstructs a 32-bit signed integer from four APDU bytes using signed left shifts. When any of the four bytes has bit 7 set (value ≥ 0x80), the left-shift operation overflows a signed int32_t, which is undefined behavior per the C standard. This is flagged thousands of times per minute by UndefinedBehaviorSanitizer on any BACnet input containing signed-integer property values with high-bit-set bytes. This vulnerability is fixed in 1.4.3. | ||||
| CVE-2026-34549 | 2 Color, Internationalcolorconsortium | 2 Iccdev, Iccdev | 2026-04-20 | 6.2 Medium |
| iccDEV provides a set of libraries and tools for working with ICC color management profiles. Prior to version 2.3.1.6, there is an Undefined Behavior (UB) condition in IccUtil.cpp triggered by a crafted input profile. Under UndefinedBehaviorSanitizer, the issue is reported as invalid left shift operations on icUInt32Number (unsigned 32-bit) where the shifted value “cannot be represented” in that type. This issue has been patched in version 2.3.1.6. | ||||
| CVE-2026-34547 | 2 Color, Internationalcolorconsortium | 2 Iccdev, Iccdev | 2026-04-20 | 6.2 Medium |
| iccDEV provides a set of libraries and tools for working with ICC color management profiles. Prior to version 2.3.1.6, an Undefined Behavior (UB) condition in IccUtil.cpp can be triggered by a crafted ICC profile when running iccDumpProfile. This issue has been patched in version 2.3.1.6. | ||||
| CVE-2026-34537 | 2 Color, Internationalcolorconsortium | 2 Iccdev, Iccdev | 2026-04-20 | 6.2 Medium |
| iccDEV provides a set of libraries and tools for working with ICC color management profiles. Prior to version 2.3.1.6, a crafted ICC profile can trigger Undefined Behavior (UB) in CIccOpDefEnvVar::Exec() due to invalid enum values being loaded for icSigCmmEnvVar. The issue is observable under UBSan as a “load of value … not a valid value for type icSigCmmEnvVar”, indicating an invalid enum/type value being consumed during ICC profile processing. This issue has been patched in version 2.3.1.6. | ||||
| CVE-2026-34533 | 2 Color, Internationalcolorconsortium | 2 Iccdev, Iccdev | 2026-04-20 | 6.2 Medium |
| iccDEV provides a set of libraries and tools for working with ICC color management profiles. Prior to version 2.3.1.6, a crafted ICC profile can trigger Undefined Behavior (UB) in CIccCalculatorFunc::ApplySequence() due to invalid enum values being loaded for icChannelFuncSignature. The issue is observable under UBSan as a “load of value … not a valid value for type icChannelFuncSignature”, indicating a type/enum value confusion scenario during ICC profile processing. This issue has been patched in version 2.3.1.6. | ||||
| CVE-2026-21685 | 2 Color, Internationalcolorconsortium | 2 Iccdev, Iccdev | 2026-04-18 | 7.1 High |
| iccDEV provides a set of libraries and tools that allow for the interaction, manipulation, and application of International Color Consortium (ICC) color management profiles. Versions prior to 2.3.1.2 have Undefined Behavior in `CIccTagLut16::Read()`. This vulnerability affects users of the iccDEV library who process ICC color profiles. Version 2.3.1.2 contains a patch. No known workarounds are available. | ||||
| CVE-2026-24407 | 2 Color, Internationalcolorconsortium | 2 Iccdev, Iccdev | 2026-04-18 | 7.1 High |
| iccDEV provides libraries and tools for interacting with, manipulating, and applying ICC color management profiles. Versions 2.3.1.1 and below have Undefined Behavior in icSigCalcOp(). This occurs when user-controllable input is unsafely incorporated into ICC profile data or other structured binary blobs. Successful exploitation may allow an attacker to perform DoS, manipulate data, bypass application logic and Code Execution. This issue has been fixed in version 2.3.1.2. | ||||
| CVE-2026-24409 | 2 Color, Internationalcolorconsortium | 2 Iccdev, Iccdev | 2026-04-18 | 7.1 High |
| iccDEV provides libraries and tools for interacting with, manipulating, and applying ICC color management profiles. Versions 2.3.1.1 and below have Undefined Behavior and Null Pointer Deference in CIccTagXmlFloatNum<>::ParseXml(). This occurs when user-controllable input is unsafely incorporated into ICC profile data or other structured binary blobs. Successful exploitation may allow an attacker to perform DoS, manipulate data, bypass application logic and Code Execution. This issue has been fixed in version 2.3.1.2. | ||||
| CVE-2026-21677 | 2 Color, Internationalcolorconsortium | 2 Iccdev, Iccdev | 2026-04-18 | 8.8 High |
| iccDEV provides a set of libraries and tools for working with ICC color management profiles. Versions 2.3.1 and below have Undefined Behavior in its CIccCLUT::Init function which initializes and sets the size of a CLUT. This issue is fixed in version 2.3.1.1. | ||||
| CVE-2026-21684 | 2 Color, Internationalcolorconsortium | 2 Iccdev, Iccdev | 2026-04-18 | 7.1 High |
| iccDEV provides a set of libraries and tools that allow for the interaction, manipulation, and application of International Color Consortium (ICC) color management profiles. Versions prior to 2.3.1.2 have Undefined Behavior in `CIccTagSpectralViewingConditions()`. This vulnerability affects users of the iccDEV library who process ICC color profiles. Version 2.3.1.2 contains a patch. No known workarounds are available. | ||||
| CVE-2026-21686 | 2 Color, Internationalcolorconsortium | 2 Iccdev, Iccdev | 2026-04-18 | 7.1 High |
| iccDEV provides a set of libraries and tools that allow for the interaction, manipulation, and application of International Color Consortium (ICC) color management profiles. Versions prior to 2.3.1.2 have Undefined Behavior in `CIccTagLutAtoB::Validate()`. This vulnerability affects users of the iccDEV library who process ICC color profiles. Version 2.3.1.2 contains a patch. No known workarounds are available. | ||||
| CVE-2026-21687 | 2 Color, Internationalcolorconsortium | 2 Iccdev, Iccdev | 2026-04-18 | 7.1 High |
| iccDEV provides a set of libraries and tools that allow for the interaction, manipulation, and application of International Color Consortium (ICC) color management profiles. Versions prior to 2.3.1.2 have Undefined Behavior in `CIccTagCurve::CIccTagCurve()`. This vulnerability affects users of the iccDEV library who process ICC color profiles. Version 2.3.1.2 contains a patch. No known workarounds are available. | ||||