Export limit exceeded: 335164 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 335164 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (335164 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-39967 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: fbcon: fix integer overflow in fbcon_do_set_font Fix integer overflow vulnerabilities in fbcon_do_set_font() where font size calculations could overflow when handling user-controlled font parameters. The vulnerabilities occur when: 1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow. 2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow 3. This results in smaller allocations than expected, leading to buffer overflows during font data copying. Add explicit overflow checking using check_mul_overflow() and check_add_overflow() kernel helpers to safety validate all size calculations before allocation. | ||||
| CVE-2025-39964 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 3.3 Low |
| In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion. Furthermore, concurrent writes may create inconsistencies in the internal socket state. Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing. | ||||
| CVE-2025-39965 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: xfrm: xfrm_alloc_spi shouldn't use 0 as SPI x->id.spi == 0 means "no SPI assigned", but since commit 94f39804d891 ("xfrm: Duplicate SPI Handling"), we now create states and add them to the byspi list with this value. __xfrm_state_delete doesn't remove those states from the byspi list, since they shouldn't be there, and this shows up as a UAF the next time we go through the byspi list. | ||||
| CVE-2025-39962 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix untrusted unsigned subtract Fix the following Smatch static checker warning: net/rxrpc/rxgk_app.c:65 rxgk_yfs_decode_ticket() warn: untrusted unsigned subtract. 'ticket_len - 10 * 4' by prechecking the length of what we're trying to extract in two places in the token and decoding for a response packet. Also use sizeof() on the struct we're extracting rather specifying the size numerically to be consistent with the other related statements. | ||||
| CVE-2025-39963 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: io_uring: fix incorrect io_kiocb reference in io_link_skb In io_link_skb function, there is a bug where prev_notif is incorrectly assigned using 'nd' instead of 'prev_nd'. This causes the context validation check to compare the current notification with itself instead of comparing it with the previous notification. Fix by using the correct prev_nd parameter when obtaining prev_notif. | ||||
| CVE-2025-39961 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: iommu/amd/pgtbl: Fix possible race while increase page table level The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in alloc_pte()/fetch_pte() operations. The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level. But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increase_address_space() is updating pgtable->[root/mode], fetch_pte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommu_unmap ops to fail and upper layer may retry/log WARN_ON. CPU 0 CPU 1 ------ ------ map pages unmap pages alloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1) Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path. | ||||
| CVE-2025-39959 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp: Fix incorrect retrival of acp_chip_info Use dev_get_drvdata(dev->parent) instead of dev_get_platdata(dev) to correctly obtain acp_chip_info members in the acp I2S driver. Previously, some members were not updated properly due to incorrect data access, which could potentially lead to null pointer dereferences. This issue was missed in the earlier commit ("ASoC: amd: acp: Fix NULL pointer deref in acp_i2s_set_tdm_slot"), which only addressed set_tdm_slot(). This change ensures that all relevant functions correctly retrieve acp_chip_info, preventing further null pointer dereference issues. | ||||
| CVE-2025-39960 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: gpiolib: acpi: initialize acpi_gpio_info struct Since commit 7c010d463372 ("gpiolib: acpi: Make sure we fill struct acpi_gpio_info"), uninitialized acpi_gpio_info struct are passed to __acpi_find_gpio() and later in the call stack info->quirks is used in acpi_populate_gpio_lookup. This breaks the i2c_hid_cpi driver: [ 58.122916] i2c_hid_acpi i2c-UNIW0001:00: HID over i2c has not been provided an Int IRQ [ 58.123097] i2c_hid_acpi i2c-UNIW0001:00: probe with driver i2c_hid_acpi failed with error -22 Fix this by initializing the acpi_gpio_info pass to __acpi_find_gpio() | ||||
| CVE-2025-39958 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: iommu/s390: Make attach succeed when the device was surprise removed When a PCI device is removed with surprise hotplug, there may still be attempts to attach the device to the default domain as part of tear down via (__iommu_release_dma_ownership()), or because the removal happens during probe (__iommu_probe_device()). In both cases zpci_register_ioat() fails with a cc value indicating that the device handle is invalid. This is because the device is no longer part of the instance as far as the hypervisor is concerned. Currently this leads to an error return and s390_iommu_attach_device() fails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail() because attaching to the default domain must never fail. With the device fenced by the hypervisor no DMAs to or from memory are possible and the IOMMU translations have no effect. Proceed as if the registration was successful and let the hotplug event handling clean up the device. This is similar to how devices in the error state are handled since commit 59bbf596791b ("iommu/s390: Make attach succeed even if the device is in error state") except that for removal the domain will not be registered later. This approach was also previously discussed at the link. Handle both cases, error state and removal, in a helper which checks if the error needs to be propagated or ignored. Avoid magic number condition codes by using the pre-existing, but never used, defines for PCI load/store condition codes and rename them to reflect that they apply to all PCI instructions. | ||||
| CVE-2025-39956 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: igc: don't fail igc_probe() on LED setup error When igc_led_setup() fails, igc_probe() fails and triggers kernel panic in free_netdev() since unregister_netdev() is not called. [1] This behavior can be tested using fault-injection framework, especially the failslab feature. [2] Since LED support is not mandatory, treat LED setup failures as non-fatal and continue probe with a warning message, consequently avoiding the kernel panic. [1] kernel BUG at net/core/dev.c:12047! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 937 Comm: repro-igc-led-e Not tainted 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:free_netdev+0x278/0x2b0 [...] Call Trace: <TASK> igc_probe+0x370/0x910 local_pci_probe+0x3a/0x80 pci_device_probe+0xd1/0x200 [...] [2] #!/bin/bash -ex FAILSLAB_PATH=/sys/kernel/debug/failslab/ DEVICE=0000:00:05.0 START_ADDR=$(grep " igc_led_setup" /proc/kallsyms \ | awk '{printf("0x%s", $1)}') END_ADDR=$(printf "0x%x" $((START_ADDR + 0x100))) echo $START_ADDR > $FAILSLAB_PATH/require-start echo $END_ADDR > $FAILSLAB_PATH/require-end echo 1 > $FAILSLAB_PATH/times echo 100 > $FAILSLAB_PATH/probability echo N > $FAILSLAB_PATH/ignore-gfp-wait echo $DEVICE > /sys/bus/pci/drivers/igc/bind | ||||
| CVE-2025-39957 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: increase scan_ies_len for S1G Currently the S1G capability element is not taken into account for the scan_ies_len, which leads to a buffer length validation failure in ieee80211_prep_hw_scan() and subsequent WARN in __ieee80211_start_scan(). This prevents hw scanning from functioning. To fix ensure we accommodate for the S1G capability length. | ||||
| CVE-2026-26333 | 1 Calero | 1 Verasmart | 2026-02-26 | 9.8 Critical |
| Calero VeraSMART versions prior to 2022 R1 expose an unauthenticated .NET Remoting HTTP service on TCP port 8001. The service publishes default ObjectURIs (including EndeavorServer.rem and RemoteFileReceiver.rem) and permits the use of SOAP and binary formatters with TypeFilterLevel set to Full. An unauthenticated remote attacker can invoke the exposed remoting endpoints to perform arbitrary file read and write operations via the WebClient class. This allows retrieval of sensitive files such as WebRoot\\web.config, which may disclose IIS machineKey validation and decryption keys. An attacker can use these keys to generate a malicious ASP.NET ViewState payload and achieve remote code execution within the IIS application context. Additionally, supplying a UNC path can trigger outbound SMB authentication from the service account, potentially exposing NTLMv2 hashes for relay or offline cracking. | ||||
| CVE-2026-26334 | 1 Calero | 1 Verasmart | 2026-02-26 | 7.8 High |
| Calero VeraSMART versions prior to 2026 R1 contain hardcoded static AES encryption keys within Veramark.Framework.dll (Veramark.Core.Config class). These keys are used to encrypt the password of the service account stored in C:\\VeraSMART Data\\app.settings. An attacker with local access to the system can extract the hardcoded keys from the Veramark.Framework.dll module and decrypt the stored credentials. The recovered credentials can then be used to authenticate to the Windows host, potentially resulting in local privilege escalation depending on the privileges of the configured service account. | ||||
| CVE-2026-26335 | 1 Calero | 1 Verasmart | 2026-02-26 | 9.8 Critical |
| Calero VeraSMART versions prior to 2022 R1 use static ASP.NET/IIS machineKey values configured for the VeraSMART web application and stored in C:\\Program Files (x86)\\Veramark\\VeraSMART\\WebRoot\\web.config. An attacker who obtains these keys can craft a valid ASP.NET ViewState payload that passes integrity validation and is accepted by the application, resulting in server-side deserialization and remote code execution in the context of the IIS application. | ||||
| CVE-2026-26366 | 2 Jung, Jung-group | 2 Enet Smart Home Server, Enet Smart Home | 2026-02-26 | 9.8 Critical |
| eNet SMART HOME server 2.2.1 and 2.3.1 ships with default credentials (user:user, admin:admin) that remain active after installation and commissioning without enforcing a mandatory password change. Unauthenticated attackers can use these default credentials to gain administrative access to sensitive smart home configuration and control functions. | ||||
| CVE-2026-26367 | 2 Jung, Jung-group | 2 Enet Smart Home Server, Enet Smart Home | 2026-02-26 | 6.5 Medium |
| eNet SMART HOME server 2.2.1 and 2.3.1 contains a missing authorization vulnerability in the deleteUserAccount JSON-RPC method that permits any authenticated low-privileged user (UG_USER) to delete arbitrary user accounts, except for the built-in admin account. The application does not enforce role-based access control on this function, allowing a standard user to submit a crafted POST request to /jsonrpc/management specifying another username to have that account removed without elevated permissions or additional confirmation. | ||||
| CVE-2025-33239 | 1 Nvidia | 1 Megatron-bridge | 2026-02-26 | 7.8 High |
| NVIDIA Megatron Bridge contains a vulnerability in a data merging tutorial, where malicious input could cause a code injection. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, information disclosure, and data tampering. | ||||
| CVE-2025-33240 | 1 Nvidia | 1 Megatron-bridge | 2026-02-26 | 7.8 High |
| NVIDIA Megatron Bridge contains a vulnerability in a data shuffling tutorial, where malicious input could cause a code injection. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, information disclosure, and data tampering. | ||||
| CVE-2025-70063 | 1 Phpgurukul | 1 Hospital Management System | 2026-02-26 | 6.5 Medium |
| The 'Medical History' module in PHPGurukul Hospital Management System v4.0 contains an Insecure Direct Object Reference (IDOR) vulnerability. The application fails to verify that the requested 'viewid' parameter belongs to the currently authenticated patient. This allows a user to access the confidential medical records of other patients by iterating the 'viewid' integer. | ||||
| CVE-2025-10256 | 1 Ffmpeg | 1 Ffmpeg | 2026-02-26 | 5.3 Medium |
| A NULL pointer dereference vulnerability exists in FFmpeg’s Firequalizer filter (libavfilter/af_firequalizer.c) due to a missing check on the return value of av_malloc_array() in the config_input() function. An attacker could exploit this by tricking a victim into processing a crafted media file with the Firequalizer filter enabled, causing the application to dereference a NULL pointer and crash, leading to denial of service. | ||||