Export limit exceeded: 15139 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (15139 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-45022 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0 The __vmap_pages_range_noflush() assumes its argument pages** contains pages with the same page shift. However, since commit e9c3cda4d86e ("mm, vmalloc: fix high order __GFP_NOFAIL allocations"), if gfp_flags includes __GFP_NOFAIL with high order in vm_area_alloc_pages() and page allocation failed for high order, the pages** may contain two different page shifts (high order and order-0). This could lead __vmap_pages_range_noflush() to perform incorrect mappings, potentially resulting in memory corruption. Users might encounter this as follows (vmap_allow_huge = true, 2M is for PMD_SIZE): kvmalloc(2M, __GFP_NOFAIL|GFP_X) __vmalloc_node_range_noprof(vm_flags=VM_ALLOW_HUGE_VMAP) vm_area_alloc_pages(order=9) ---> order-9 allocation failed and fallback to order-0 vmap_pages_range() vmap_pages_range_noflush() __vmap_pages_range_noflush(page_shift = 21) ----> wrong mapping happens We can remove the fallback code because if a high-order allocation fails, __vmalloc_node_range_noprof() will retry with order-0. Therefore, it is unnecessary to fallback to order-0 here. Therefore, fix this by removing the fallback code. | ||||
| CVE-2024-44970 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: SHAMPO, Fix invalid WQ linked list unlink When all the strides in a WQE have been consumed, the WQE is unlinked from the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible to receive CQEs with 0 consumed strides for the same WQE even after the WQE is fully consumed and unlinked. This triggers an additional unlink for the same wqe which corrupts the linked list. Fix this scenario by accepting 0 sized consumed strides without unlinking the WQE again. | ||||
| CVE-2024-44966 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: binfmt_flat: Fix corruption when not offsetting data start Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start") introduced a RISC-V specific variant of the FLAT format which does not allocate any space for the (obsolete) array of shared library pointers. However, it did not disable the code which initializes the array, resulting in the corruption of sizeof(long) bytes before the DATA segment, generally the end of the TEXT segment. Introduce MAX_SHARED_LIBS_UPDATE which depends on the state of CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard the initialization of the shared library pointer region so that it will only be initialized if space is reserved for it. | ||||
| CVE-2024-44965 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: x86/mm: Fix pti_clone_pgtable() alignment assumption Guenter reported dodgy crashes on an i386-nosmp build using GCC-11 that had the form of endless traps until entry stack exhaust and then #DF from the stack guard. It turned out that pti_clone_pgtable() had alignment assumptions on the start address, notably it hard assumes start is PMD aligned. This is true on x86_64, but very much not true on i386. These assumptions can cause the end condition to malfunction, leading to a 'short' clone. Guess what happens when the user mapping has a short copy of the entry text? Use the correct increment form for addr to avoid alignment assumptions. | ||||
| CVE-2025-30437 | 1 Apple | 1 Macos | 2025-11-03 | 7.4 High |
| The issue was addressed with improved bounds checks. This issue is fixed in macOS Sequoia 15.4. An app may be able to corrupt coprocessor memory. | ||||
| CVE-2025-27111 | 1 Rack | 1 Rack | 2025-11-03 | 7.5 High |
| Rack is a modular Ruby web server interface. The Rack::Sendfile middleware logs unsanitised header values from the X-Sendfile-Type header. An attacker can exploit this by injecting escape sequences (such as newline characters) into the header, resulting in log injection. This vulnerability is fixed in 2.2.12, 3.0.13, and 3.1.11. | ||||
| CVE-2025-26409 | 2025-11-03 | 6.8 Medium | ||
| A serial interface can be accessed with physical access to the PCB of Wattsense Bridge devices. After connecting to the interface, access to the bootloader is possible, as well as a Linux login prompt. The bootloader access can be used to gain a root shell on the device. This issue is fixed in recent firmware versions BSP >= 6.4.1. | ||||
| CVE-2025-26408 | 2025-11-03 | 6.1 Medium | ||
| The JTAG interface of Wattsense Bridge devices can be accessed with physical access to the PCB. After connecting to the interface, full access to the device is possible. This enables an attacker to extract information, modify and debug the device's firmware. All known versions are affected. | ||||
| CVE-2025-25184 | 2 Rack, Redhat | 3 Rack, Enterprise Linux, Logging | 2025-11-03 | 6.5 Medium |
| Rack provides an interface for developing web applications in Ruby. Prior to versions 2.2.11, 3.0.12, and 3.1.10, Rack::CommonLogger can be exploited by crafting input that includes newline characters to manipulate log entries. The supplied proof-of-concept demonstrates injecting malicious content into logs. When a user provides the authorization credentials via Rack::Auth::Basic, if success, the username will be put in env['REMOTE_USER'] and later be used by Rack::CommonLogger for logging purposes. The issue occurs when a server intentionally or unintentionally allows a user creation with the username contain CRLF and white space characters, or the server just want to log every login attempts. If an attacker enters a username with CRLF character, the logger will log the malicious username with CRLF characters into the logfile. Attackers can break log formats or insert fraudulent entries, potentially obscuring real activity or injecting malicious data into log files. Versions 2.2.11, 3.0.12, and 3.1.10 contain a fix. | ||||
| CVE-2025-24264 | 2 Apple, Redhat | 11 Ipados, Iphone Os, Macos and 8 more | 2025-11-03 | 9.8 Critical |
| The issue was addressed with improved memory handling. This issue is fixed in visionOS 2.4, tvOS 18.4, iPadOS 17.7.6, iOS 18.4 and iPadOS 18.4, macOS Sequoia 15.4, Safari 18.4. Processing maliciously crafted web content may lead to an unexpected Safari crash. | ||||
| CVE-2024-42332 | 1 Zabbix | 1 Zabbix | 2025-11-03 | 3.7 Low |
| The researcher is showing that due to the way the SNMP trap log is parsed, an attacker can craft an SNMP trap with additional lines of information and have forged data show in the Zabbix UI. This attack requires SNMP auth to be off and/or the attacker to know the community/auth details. The attack requires an SNMP item to be configured as text on the target host. | ||||
| CVE-2024-42259 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix Virtual Memory mapping boundaries calculation Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access. Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses. Additionally, the calculations have been rewritten in a clearer and more understandable form. [Joonas: Add Requires: tag] Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417) | ||||
| CVE-2024-41011 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: don't allow mapping the MMIO HDP page with large pages We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGE_SIZE of MMIO space. | ||||
| CVE-2024-39499 | 2 Linux, Redhat | 3 Linux Kernel, Enterprise Linux, Rhel Eus | 2025-11-03 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: vmci: prevent speculation leaks by sanitizing event in event_deliver() Coverity spotted that event_msg is controlled by user-space, event_msg->event_data.event is passed to event_deliver() and used as an index without sanitization. This change ensures that the event index is sanitized to mitigate any possibility of speculative information leaks. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Only compile tested, no access to HW. | ||||
| CVE-2024-39472 | 2 Linux, Redhat | 3 Linux Kernel, Enterprise Linux, Rhel Eus | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: xfs: fix log recovery buffer allocation for the legacy h_size fixup Commit a70f9fe52daa ("xfs: detect and handle invalid iclog size set by mkfs") added a fixup for incorrect h_size values used for the initial umount record in old xfsprogs versions. Later commit 0c771b99d6c9 ("xfs: clean up calculation of LR header blocks") cleaned up the log reover buffer calculation, but stoped using the fixed up h_size value to size the log recovery buffer, which can lead to an out of bounds access when the incorrect h_size does not come from the old mkfs tool, but a fuzzer. Fix this by open coding xlog_logrec_hblks and taking the fixed h_size into account for this calculation. | ||||
| CVE-2023-2977 | 2 Opensc Project, Redhat | 2 Opensc, Enterprise Linux | 2025-11-03 | 7.1 High |
| A vulnerbility was found in OpenSC. This security flaw cause a buffer overrun vulnerability in pkcs15 cardos_have_verifyrc_package. The attacker can supply a smart card package with malformed ASN1 context. The cardos_have_verifyrc_package function scans the ASN1 buffer for 2 tags, where remaining length is wrongly caculated due to moved starting pointer. This leads to possible heap-based buffer oob read. In cases where ASAN is enabled while compiling this causes a crash. Further info leak or more damage is possible. | ||||
| CVE-2022-4900 | 2 Php, Redhat | 4 Php, Enterprise Linux, Rhel Software Collections and 1 more | 2025-11-03 | 6.2 Medium |
| A vulnerability was found in PHP where setting the environment variable PHP_CLI_SERVER_WORKERS to a large value leads to a heap buffer overflow. | ||||
| CVE-2022-3715 | 2 Gnu, Redhat | 2 Bash, Enterprise Linux | 2025-11-03 | 7.8 High |
| A flaw was found in the bash package, where a heap-buffer overflow can occur in valid parameter_transform. This issue may lead to memory problems. | ||||
| CVE-2022-3559 | 2 Exim, Fedoraproject | 2 Exim, Fedora | 2025-11-03 | 4.6 Medium |
| A vulnerability was found in Exim and classified as problematic. This issue affects some unknown processing of the component Regex Handler. The manipulation leads to use after free. The name of the patch is 4e9ed49f8f12eb331b29bd5b6dc3693c520fddc2. It is recommended to apply a patch to fix this issue. The identifier VDB-211073 was assigned to this vulnerability. | ||||
| CVE-2021-42782 | 2 Fedoraproject, Opensc Project | 2 Fedora, Opensc | 2025-11-03 | 5.3 Medium |
| Stack buffer overflow issues were found in Opensc before version 0.22.0 in various places that could potentially crash programs using the library. | ||||