Export limit exceeded: 35281 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (35281 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| 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-1707 | 1 Pgadmin | 1 Pgadmin 4 | 2026-02-26 | 7.4 High |
| pgAdmin versions 9.11 are affected by a Restore restriction bypass via key disclosure vulnerability that occurs when running in server mode and performing restores from PLAIN-format dump files. An attacker with access to the pgAdmin web interface can observe an active restore operation, extract the `\restrict` key in real time, and race the restore process by overwriting the restore script with a payload that re-enables meta-commands using `\unrestrict <key>`. This results in reliable command execution on the pgAdmin host during the restore operation. | ||||
| CVE-2025-67856 | 1 Moodle | 1 Moodle | 2026-02-26 | 5.4 Medium |
| A flaw was found in Moodle. An authorization logic flaw, specifically due to incomplete role checks during the badge awarding process, allowed badges to be granted without proper verification. This could enable unauthorized users to obtain badges they are not entitled to, potentially leading to privilege escalation or unauthorized access to certain features. | ||||
| CVE-2024-32902 | 1 Google | 1 Android | 2026-02-26 | 7.5 High |
| Remote prevention of access to cellular service with no user interaction (for example, crashing the cellular radio service with a malformed packet) | ||||
| CVE-2025-71148 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 3.3 Low |
| In the Linux kernel, the following vulnerability has been resolved: net/handshake: restore destructor on submit failure handshake_req_submit() replaces sk->sk_destruct but never restores it when submission fails before the request is hashed. handshake_sk_destruct() then returns early and the original destructor never runs, leaking the socket. Restore sk_destruct on the error path. | ||||
| CVE-2025-71156 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: gve: defer interrupt enabling until NAPI registration Currently, interrupts are automatically enabled immediately upon request. This allows interrupt to fire before the associated NAPI context is fully initialized and cause failures like below: [ 0.946369] Call Trace: [ 0.946369] <IRQ> [ 0.946369] __napi_poll+0x2a/0x1e0 [ 0.946369] net_rx_action+0x2f9/0x3f0 [ 0.946369] handle_softirqs+0xd6/0x2c0 [ 0.946369] ? handle_edge_irq+0xc1/0x1b0 [ 0.946369] __irq_exit_rcu+0xc3/0xe0 [ 0.946369] common_interrupt+0x81/0xa0 [ 0.946369] </IRQ> [ 0.946369] <TASK> [ 0.946369] asm_common_interrupt+0x22/0x40 [ 0.946369] RIP: 0010:pv_native_safe_halt+0xb/0x10 Use the `IRQF_NO_AUTOEN` flag when requesting interrupts to prevent auto enablement and explicitly enable the interrupt in NAPI initialization path (and disable it during NAPI teardown). This ensures that interrupt lifecycle is strictly coupled with readiness of NAPI context. | ||||
| CVE-2025-71157 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/core: always drop device refcount in ib_del_sub_device_and_put() Since nldev_deldev() (introduced by commit 060c642b2ab8 ("RDMA/nldev: Add support to add/delete a sub IB device through netlink") grabs a reference using ib_device_get_by_index() before calling ib_del_sub_device_and_put(), we need to drop that reference before returning -EOPNOTSUPP error. | ||||
| CVE-2025-71158 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: gpio: mpsse: ensure worker is torn down When an IRQ worker is running, unplugging the device would cause a crash. The sealevel hardware this driver was written for was not hotpluggable, so I never realized it. This change uses a spinlock to protect a list of workers, which it tears down on disconnect. | ||||
| CVE-2025-71160 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: avoid chain re-validation if possible Hamza Mahfooz reports cpu soft lock-ups in nft_chain_validate(): watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547] [..] RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables] [..] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_table_validate+0x6b/0xb0 [nf_tables] nf_tables_validate+0x8b/0xa0 [nf_tables] nf_tables_commit+0x1df/0x1eb0 [nf_tables] [..] Currently nf_tables will traverse the entire table (chain graph), starting from the entry points (base chains), exploring all possible paths (chain jumps). But there are cases where we could avoid revalidation. Consider: 1 input -> j2 -> j3 2 input -> j2 -> j3 3 input -> j1 -> j2 -> j3 Then the second rule does not need to revalidate j2, and, by extension j3, because this was already checked during validation of the first rule. We need to validate it only for rule 3. This is needed because chain loop detection also ensures we do not exceed the jump stack: Just because we know that j2 is cycle free, its last jump might now exceed the allowed stack size. We also need to update all reachable chains with the new largest observed call depth. Care has to be taken to revalidate even if the chain depth won't be an issue: chain validation also ensures that expressions are not called from invalid base chains. For example, the masquerade expression can only be called from NAT postrouting base chains. Therefore we also need to keep record of the base chain context (type, hooknum) and revalidate if the chain becomes reachable from a different hook location. | ||||
| CVE-2025-20903 | 1 Samsung | 1 Android | 2026-02-26 | 7.3 High |
| Improper access control in SecSettingsIntelligence prior to SMR Mar-2025 Release 1 allows local attackers to launch privileged activities. User interaction is required for triggering this vulnerability. | ||||
| CVE-2025-26633 | 1 Microsoft | 24 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 21 more | 2026-02-26 | 7 High |
| Improper neutralization in Microsoft Management Console allows an unauthorized attacker to bypass a security feature locally. | ||||
| CVE-2025-21171 | 4 Apple, Linux, Microsoft and 1 more | 7 Macos, Linux Kernel, .net and 4 more | 2026-02-26 | 7.5 High |
| .NET Remote Code Execution Vulnerability | ||||
| CVE-2025-21234 | 1 Microsoft | 14 Windows 10 21h2, Windows 10 21h2, Windows 10 22h2 and 11 more | 2026-02-26 | 7.8 High |
| Windows PrintWorkflowUserSvc Elevation of Privilege Vulnerability | ||||
| CVE-2025-21235 | 1 Microsoft | 14 Windows 10 21h2, Windows 10 21h2, Windows 10 22h2 and 11 more | 2026-02-26 | 7.8 High |
| Windows PrintWorkflowUserSvc Elevation of Privilege Vulnerability | ||||
| CVE-2025-21271 | 1 Microsoft | 7 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 4 more | 2026-02-26 | 7.8 High |
| Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability | ||||
| CVE-2025-21281 | 1 Microsoft | 21 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 18 more | 2026-02-26 | 7.8 High |
| Microsoft COM for Windows Elevation of Privilege Vulnerability | ||||
| CVE-2025-21291 | 1 Microsoft | 13 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 10 more | 2026-02-26 | 8.8 High |
| Windows Direct Show Remote Code Execution Vulnerability | ||||
| CVE-2025-21293 | 1 Microsoft | 21 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 18 more | 2026-02-26 | 8.8 High |
| Active Directory Domain Services Elevation of Privilege Vulnerability | ||||
| CVE-2025-21297 | 1 Microsoft | 10 Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 and 7 more | 2026-02-26 | 8.1 High |
| Windows Remote Desktop Services Remote Code Execution Vulnerability | ||||