Export limit exceeded: 365581 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (365581 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2018-0167 | 2 Cisco, Rockwellautomation | 18 Asr 9001, Asr 9006, Asr 9010 and 15 more | 2026-01-14 | 8.8 High |
| Multiple Buffer Overflow vulnerabilities in the Link Layer Discovery Protocol (LLDP) subsystem of Cisco IOS Software, Cisco IOS XE Software, and Cisco IOS XR Software could allow an unauthenticated, adjacent attacker to cause a denial of service (DoS) condition or execute arbitrary code with elevated privileges on an affected device. Cisco Bug IDs: CSCuo17183, CSCvd73487. | ||||
| CVE-2018-0161 | 1 Cisco | 15 Catalyst 2960l-16ps-ll, Catalyst 2960l-16ts-ll, Catalyst 2960l-24pq-ll and 12 more | 2026-01-14 | 6.3 Medium |
| A vulnerability in the Simple Network Management Protocol (SNMP) subsystem of Cisco IOS Software running on certain models of Cisco Catalyst Switches could allow an authenticated, remote attacker to cause a denial of service (DoS) condition, aka a GET MIB Object ID Denial of Service Vulnerability. The vulnerability is due to a condition that could occur when the affected software processes an SNMP read request that contains a request for the ciscoFlashMIB object ID (OID). An attacker could trigger this vulnerability by issuing an SNMP GET request for the ciscoFlashMIB OID on an affected device. A successful exploit could cause the affected device to restart due to a SYS-3-CPUHOG. This vulnerability affects the following Cisco devices if they are running a vulnerable release of Cisco IOS Software and are configured to use SNMP Version 2 (SNMPv2) or SNMP Version 3 (SNMPv3): Cisco Catalyst 2960-L Series Switches, Cisco Catalyst Digital Building Series Switches 8P, Cisco Catalyst Digital Building Series Switches 8U. Cisco Bug IDs: CSCvd89541. | ||||
| CVE-2018-0159 | 1 Cisco | 14 Asr 901-12c-f-d, Asr 901-12c-ft-d, Asr 901-4c-f-d and 11 more | 2026-01-14 | 7.5 High |
| A vulnerability in the implementation of Internet Key Exchange Version 1 (IKEv1) functionality in Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause an affected device to reload, resulting in a denial of service (DoS) condition. The vulnerability is due to improper validation of specific IKEv1 packets. An attacker could exploit this vulnerability by sending crafted IKEv1 packets to an affected device during an IKE negotiation. A successful exploit could allow the attacker to cause an affected device to reload, resulting in a DoS condition. Cisco Bug IDs: CSCuj73916. | ||||
| CVE-2018-0158 | 2 Cisco, Rockwellautomation | 12 Asr 1001-hx, Asr 1001-x, Asr 1002-hx and 9 more | 2026-01-14 | 8.6 High |
| A vulnerability in the Internet Key Exchange Version 2 (IKEv2) module of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause a memory leak or a reload of an affected device that leads to a denial of service (DoS) condition. The vulnerability is due to incorrect processing of certain IKEv2 packets. An attacker could exploit this vulnerability by sending crafted IKEv2 packets to an affected device to be processed. A successful exploit could cause an affected device to continuously consume memory and eventually reload, resulting in a DoS condition. Cisco Bug IDs: CSCvf22394. | ||||
| CVE-2021-25372 | 1 Samsung | 4 Android, Exynos 2100, Exynos 980 and 1 more | 2026-01-14 | 6.1 Medium |
| An improper boundary check in DSP driver prior to SMR Mar-2021 Release 1 allows out of bounds memory access. | ||||
| CVE-2021-25370 | 1 Samsung | 1 Android | 2026-01-14 | 6.1 Medium |
| An incorrect implementation handling file descriptor in dpu driver prior to SMR Mar-2021 Release 1 results in memory corruption leading to kernel panic. | ||||
| CVE-2023-29153 | 2 Intel, Netapp | 4 Server Platform Services, Hci Bootstrap Os, Hci Compute Node and 1 more | 2026-01-14 | 4.9 Medium |
| Uncontrolled resource consumption for some Intel(R) SPS firmware before version SPS_E5_06.01.04.002.0 may allow a privileged user to potentially enable denial of service via network access. | ||||
| CVE-2023-28745 | 1 Intel | 1 Qsfp\+ Configuration Utility | 2026-01-14 | 6.7 Medium |
| Uncontrolled search path in Intel(R) QSFP+ Configuration Utility software, all versions, may allow an authenticated user to potentially enable escalation of privilege via local access. | ||||
| CVE-2023-28396 | 1 Intel | 2 Jhl8440, Jhl8440 Firmware | 2026-01-14 | 6.1 Medium |
| Improper access control in firmware for some Intel(R) Thunderbol(TM) Controllers versions before 41 may allow a privileged user to enable denial of service via local access. | ||||
| CVE-2023-31189 | 1 Intel | 54 Openbmc, Xeon Bronze 3408u, Xeon Gold 5403n and 51 more | 2026-01-14 | 5.2 Medium |
| Improper authentication in some Intel(R) Server Product OpenBMC firmware before version egs-1.09 may allow an authenticated user to enable escalation of privilege via local access. | ||||
| CVE-2023-30767 | 1 Intel | 1 Optimization For Tensorflow | 2026-01-14 | 5.5 Medium |
| Improper buffer restrictions in Intel(R) Optimization for TensorFlow before version 2.13.0 may allow an authenticated user to potentially enable escalation of privilege via local access. | ||||
| CVE-2023-29162 | 1 Intel | 18 Advisor, Cluster Checker, Cplusplus Compiler Classic and 15 more | 2026-01-14 | 6 Medium |
| Improper buffer restrictions the Intel(R) C++ Compiler Classic before version 2021.8 for Intel(R) oneAPI Toolkits before version 2022.3.1 may allow a privileged user to potentially enable escalation of privilege via local access. | ||||
| CVE-2023-32280 | 1 Intel | 54 Openbmc, Xeon Bronze 3408u, Xeon Gold 5403n and 51 more | 2026-01-14 | 5.3 Medium |
| Insufficiently protected credentials in some Intel(R) Server Product OpenBMC firmware before versions egs-1.05 may allow an unauthenticated user to enable information disclosure via network access. | ||||
| CVE-2025-6235 | 1 Extremenetworks | 1 Extremecontrol | 2026-01-14 | 6.1 Medium |
| In ExtremeControl before 25.5.12, a cross-site scripting (XSS) vulnerability was discovered in a login interface of the affected application. The issue stems from improper handling of user-supplied input within HTML attributes, allowing an attacker to inject script code that may execute in a user's browser under specific interaction conditions. Successful exploitation could lead to exposure of user data or unauthorized actions within the browser context. | ||||
| CVE-2025-39926 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: genetlink: fix genl_bind() invoking bind() after -EPERM Per family bind/unbind callbacks were introduced to allow families to track multicast group consumer presence, e.g. to start or stop producing events depending on listeners. However, in genl_bind() the bind() callback was invoked even if capability checks failed and ret was set to -EPERM. This means that callbacks could run on behalf of unauthorized callers while the syscall still returned failure to user space. Fix this by only invoking bind() after "if (ret) break;" check i.e. after permission checks have succeeded. | ||||
| CVE-2025-39925 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: can: j1939: implement NETDEV_UNREGISTER notification handler syzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem, for j1939 protocol did not have NETDEV_UNREGISTER notification handler for undoing changes made by j1939_sk_bind(). Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct callback") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But we need to call j1939_priv_put() against an extra ref held by j1939_sk_bind() call (as a part of undoing changes made by j1939_sk_bind()) as soon as NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct() is called via j1939_sk_release()). Otherwise, the extra ref on "struct j1939_priv" held by j1939_sk_bind() call prevents "struct net_device" from dropping the usage count to 1; making it impossible for unregister_netdevice() to continue. [mkl: remove space in front of label] | ||||
| CVE-2025-39922 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: ixgbe: fix incorrect map used in eee linkmode incorrectly used ixgbe_lp_map in loops intended to populate the supported and advertised EEE linkmode bitmaps based on ixgbe_ls_map. This results in incorrect bit setting and potential out-of-bounds access, since ixgbe_lp_map and ixgbe_ls_map have different sizes and purposes. ixgbe_lp_map[i] -> ixgbe_ls_map[i] Use ixgbe_ls_map for supported and advertised linkmodes, and keep ixgbe_lp_map usage only for link partner (lp_advertised) mapping. | ||||
| CVE-2025-39921 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: spi: microchip-core-qspi: stop checking viability of op->max_freq in supports_op callback In commit 13529647743d9 ("spi: microchip-core-qspi: Support per spi-mem operation frequency switches") the logic for checking the viability of op->max_freq in mchp_coreqspi_setup_clock() was copied into mchp_coreqspi_supports_op(). Unfortunately, op->max_freq is not valid when this function is called during probe but is instead zero. Accordingly, baud_rate_val is calculated to be INT_MAX due to division by zero, causing probe of the attached memory device to fail. Seemingly spi-microchip-core-qspi was the only driver that had such a modification made to its supports_op callback when the per_op_freq capability was added, so just remove it to restore prior functionality. | ||||
| CVE-2025-39917 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds dynptr write in bpf_crypto_crypt Stanislav reported that in bpf_crypto_crypt() the destination dynptr's size is not validated to be at least as large as the source dynptr's size before calling into the crypto backend with 'len = src_len'. This can result in an OOB write when the destination is smaller than the source. Concretely, in mentioned function, psrc and pdst are both linear buffers fetched from each dynptr: psrc = __bpf_dynptr_data(src, src_len); [...] pdst = __bpf_dynptr_data_rw(dst, dst_len); [...] err = decrypt ? ctx->type->decrypt(ctx->tfm, psrc, pdst, src_len, piv) : ctx->type->encrypt(ctx->tfm, psrc, pdst, src_len, piv); The crypto backend expects pdst to be large enough with a src_len length that can be written. Add an additional src_len > dst_len check and bail out if it's the case. Note that these kfuncs are accessible under root privileges only. | ||||
| CVE-2025-39915 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: phy: transfer phy_config_inband() locking responsibility to phylink Problem description =================== Lockdep reports a possible circular locking dependency (AB/BA) between &pl->state_mutex and &phy->lock, as follows. phylink_resolve() // acquires &pl->state_mutex -> phylink_major_config() -> phy_config_inband() // acquires &pl->phydev->lock whereas all the other call sites where &pl->state_mutex and &pl->phydev->lock have the locking scheme reversed. Everywhere else, &pl->phydev->lock is acquired at the top level, and &pl->state_mutex at the lower level. A clear example is phylink_bringup_phy(). The outlier is the newly introduced phy_config_inband() and the existing lock order is the correct one. To understand why it cannot be the other way around, it is sufficient to consider phylink_phy_change(), phylink's callback from the PHY device's phy->phy_link_change() virtual method, invoked by the PHY state machine. phy_link_up() and phy_link_down(), the (indirect) callers of phylink_phy_change(), are called with &phydev->lock acquired. Then phylink_phy_change() acquires its own &pl->state_mutex, to serialize changes made to its pl->phy_state and pl->link_config. So all other instances of &pl->state_mutex and &phydev->lock must be consistent with this order. Problem impact ============== I think the kernel runs a serious deadlock risk if an existing phylink_resolve() thread, which results in a phy_config_inband() call, is concurrent with a phy_link_up() or phy_link_down() call, which will deadlock on &pl->state_mutex in phylink_phy_change(). Practically speaking, the impact may be limited by the slow speed of the medium auto-negotiation protocol, which makes it unlikely for the current state to still be unresolved when a new one is detected, but I think the problem is there. Nonetheless, the problem was discovered using lockdep. Proposed solution ================= Practically speaking, the phy_config_inband() requirement of having phydev->lock acquired must transfer to the caller (phylink is the only caller). There, it must bubble up until immediately before &pl->state_mutex is acquired, for the cases where that takes place. Solution details, considerations, notes ======================================= This is the phy_config_inband() call graph: sfp_upstream_ops :: connect_phy() | v phylink_sfp_connect_phy() | v phylink_sfp_config_phy() | | sfp_upstream_ops :: module_insert() | | | v | phylink_sfp_module_insert() | | | | sfp_upstream_ops :: module_start() | | | | | v | | phylink_sfp_module_start() | | | | v v | phylink_sfp_config_optical() phylink_start() | | | phylink_resume() v v | | phylink_sfp_set_config() | | | v v v phylink_mac_initial_config() | phylink_resolve() | | phylink_ethtool_ksettings_set() v v v phylink_major_config() | v phy_config_inband() phylink_major_config() caller #1, phylink_mac_initial_config(), does not acquire &pl->state_mutex nor do its callers. It must acquire &pl->phydev->lock prior to calling phylink_major_config(). phylink_major_config() caller #2, phylink_resolve() acquires &pl->state_mutex, thus also needs to acquire &pl->phydev->lock. phylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is completely uninteresting, because it only call ---truncated--- | ||||