Export limit exceeded: 352337 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 35344 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (35344 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-28826 | 1 Apple | 1 Macos | 2026-05-11 | 4 Medium |
| A logic issue was addressed with improved restrictions. This issue is fixed in macOS Sequoia 15.7.5, macOS Sonoma 14.8.5, macOS Tahoe 26.4. A malicious app may be able to break out of its sandbox. | ||||
| CVE-2025-38647 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: sar: drop lockdep assertion in rtw89_set_sar_from_acpi The following assertion is triggered on the rtw89 driver startup. It looks meaningless to hold wiphy lock on the early init stage so drop the assertion. WARNING: CPU: 7 PID: 629 at drivers/net/wireless/realtek/rtw89/sar.c:502 rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core] CPU: 7 UID: 0 PID: 629 Comm: (udev-worker) Not tainted 6.15.0+ #29 PREEMPT(lazy) Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN50WW 09/27/2024 RIP: 0010:rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core] Call Trace: <TASK> rtw89_sar_init+0x68/0x2c0 [rtw89_core] rtw89_core_init+0x188e/0x1e50 [rtw89_core] rtw89_pci_probe+0x530/0xb50 [rtw89_pci] local_pci_probe+0xd9/0x190 pci_call_probe+0x183/0x540 pci_device_probe+0x171/0x2c0 really_probe+0x1e1/0x890 __driver_probe_device+0x18c/0x390 driver_probe_device+0x4a/0x120 __driver_attach+0x1a0/0x530 bus_for_each_dev+0x10b/0x190 bus_add_driver+0x2eb/0x540 driver_register+0x1a3/0x3a0 do_one_initcall+0xd5/0x450 do_init_module+0x2cc/0x8f0 init_module_from_file+0xe1/0x150 idempotent_init_module+0x226/0x760 __x64_sys_finit_module+0xcd/0x150 do_syscall_64+0x94/0x380 entry_SYSCALL_64_after_hwframe+0x76/0x7e Found by Linux Verification Center (linuxtesting.org). | ||||
| CVE-2025-38638 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: add a retry logic in net6_rt_notify() inet6_rt_notify() can be called under RCU protection only. This means the route could be changed concurrently and rt6_fill_node() could return -EMSGSIZE. Re-size the skb when this happens and retry, removing one WARN_ON() that syzbot was able to trigger: WARNING: CPU: 3 PID: 6291 at net/ipv6/route.c:6342 inet6_rt_notify+0x475/0x4b0 net/ipv6/route.c:6342 Modules linked in: CPU: 3 UID: 0 PID: 6291 Comm: syz.0.77 Not tainted 6.16.0-rc7-syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:inet6_rt_notify+0x475/0x4b0 net/ipv6/route.c:6342 Code: fc ff ff e8 6d 52 ea f7 e9 47 fc ff ff 48 8b 7c 24 08 4c 89 04 24 e8 5a 52 ea f7 4c 8b 04 24 e9 94 fd ff ff e8 9c fe 84 f7 90 <0f> 0b 90 e9 bd fd ff ff e8 6e 52 ea f7 e9 bb fb ff ff 48 89 df e8 RSP: 0018:ffffc900035cf1d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffc900035cf540 RCX: ffffffff8a36e790 RDX: ffff88802f7e8000 RSI: ffffffff8a36e9d4 RDI: 0000000000000005 RBP: ffff88803c230f00 R08: 0000000000000005 R09: 00000000ffffffa6 R10: 00000000ffffffa6 R11: 0000000000000001 R12: 00000000ffffffa6 R13: 0000000000000900 R14: ffff888032ea4100 R15: 0000000000000000 FS: 00007fac7b89a6c0(0000) GS:ffff8880d6a20000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fac7b899f98 CR3: 0000000034b3f000 CR4: 0000000000352ef0 Call Trace: <TASK> ip6_route_mpath_notify+0xde/0x280 net/ipv6/route.c:5356 ip6_route_multipath_add+0x1181/0x1bd0 net/ipv6/route.c:5536 inet6_rtm_newroute+0xe4/0x1a0 net/ipv6/route.c:5647 rtnetlink_rcv_msg+0x95e/0xe90 net/core/rtnetlink.c:6944 netlink_rcv_skb+0x155/0x420 net/netlink/af_netlink.c:2552 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x58d/0x850 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 | ||||
| CVE-2025-38633 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: clk: spacemit: mark K1 pll1_d8 as critical The pll1_d8 clock is enabled by the boot loader, and is ultimately a parent for numerous clocks, including those used by APB and AXI buses. Guodong Xu discovered that this clock got disabled while responding to getting -EPROBE_DEFER when requesting a reset controller. The needed clock (CLK_DMA, along with its parents) had already been enabled. To respond to the probe deferral return, the CLK_DMA clock was disabled, and this led to parent clocks also reducing their enable count. When the enable count for pll1_d8 was decremented it became 0, which caused it to be disabled. This led to a system hang. Marking that clock critical resolves this by preventing it from being disabled. Define a new macro CCU_FACTOR_GATE_DEFINE() to allow clock flags to be supplied for a CCU_FACTOR_GATE clock. | ||||
| CVE-2025-71255 | 2 Google, Unisoc | 17 Android, Sc7731e, Sc9832e and 14 more | 2026-05-11 | 7.5 High |
| In Modem IMS, there is a possible improper input validation. This could lead to remote denial of service with no additional execution privileges needed. | ||||
| CVE-2025-21949 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: LoongArch: Set hugetlb mmap base address aligned with pmd size With ltp test case "testcases/bin/hugefork02", there is a dmesg error report message such as: kernel BUG at mm/hugetlb.c:5550! Oops - BUG[#1]: CPU: 0 UID: 0 PID: 1517 Comm: hugefork02 Not tainted 6.14.0-rc2+ #241 Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 pc 90000000004eaf1c ra 9000000000485538 tp 900000010edbc000 sp 900000010edbf940 a0 900000010edbfb00 a1 9000000108d20280 a2 00007fffe9474000 a3 00007ffff3474000 a4 0000000000000000 a5 0000000000000003 a6 00000000003cadd3 a7 0000000000000000 t0 0000000001ffffff t1 0000000001474000 t2 900000010ecd7900 t3 00007fffe9474000 t4 00007fffe9474000 t5 0000000000000040 t6 900000010edbfb00 t7 0000000000000001 t8 0000000000000005 u0 90000000004849d0 s9 900000010edbfa00 s0 9000000108d20280 s1 00007fffe9474000 s2 0000000002000000 s3 9000000108d20280 s4 9000000002b38b10 s5 900000010edbfb00 s6 00007ffff3474000 s7 0000000000000406 s8 900000010edbfa08 ra: 9000000000485538 unmap_vmas+0x130/0x218 ERA: 90000000004eaf1c __unmap_hugepage_range+0x6f4/0x7d0 PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) Process hugefork02 (pid: 1517, threadinfo=00000000a670eaf4, task=000000007a95fc64) Call Trace: [<90000000004eaf1c>] __unmap_hugepage_range+0x6f4/0x7d0 [<9000000000485534>] unmap_vmas+0x12c/0x218 [<9000000000494068>] exit_mmap+0xe0/0x308 [<900000000025fdc4>] mmput+0x74/0x180 [<900000000026a284>] do_exit+0x294/0x898 [<900000000026aa30>] do_group_exit+0x30/0x98 [<900000000027bed4>] get_signal+0x83c/0x868 [<90000000002457b4>] arch_do_signal_or_restart+0x54/0xfa0 [<90000000015795e8>] irqentry_exit_to_user_mode+0xb8/0x138 [<90000000002572d0>] tlb_do_page_fault_1+0x114/0x1b4 The problem is that base address allocated from hugetlbfs is not aligned with pmd size. Here add a checking for hugetlbfs and align base address with pmd size. After this patch the test case "testcases/bin/hugefork02" passes to run. This is similar to the commit 7f24cbc9c4d42db8a3c8484d1 ("mm/mmap: teach generic_get_unmapped_area{_topdown} to handle hugetlb mappings"). | ||||
| CVE-2026-43184 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: rnbd-srv: Zero the rsp buffer before using it Before using the data buffer to send back the response message, zero it completely. This prevents any stray bytes to be picked up by the client side when there the message is exchanged between different protocol versions. | ||||
| CVE-2026-43181 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: gpio: sysfs: fix chip removal with GPIOs exported over sysfs Currently if we export a GPIO over sysfs and unbind the parent GPIO controller, the exported attribute will remain under /sys/class/gpio because once we remove the parent device, we can no longer associate the descriptor with it in gpiod_unexport() and never drop the final reference. Rework the teardown code: provide an unlocked variant of gpiod_unexport() and remove all exported GPIOs with the sysfs_lock taken before unregistering the parent device itself. This is done to prevent any new exports happening before we unregister the device completely. | ||||
| CVE-2026-31781 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/ioc32: stop speculation on the drm_compat_ioctl path The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling array_index_nospec() on the index to the function pointer list. | ||||
| CVE-2026-43191 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust PHY FSM transition to TX_EN-to-PLL_ON for TMDS on DCN35 [Why] A backport of the change made for DCN401 that addresses an issue where we turn off the PHY PLL when disabling TMDS output, which causes the OTG to remain stuck. The OTG being stuck can lead to a hang in the DCHVM's ability to ACK invalidations when it thinks the HUBP is still on but it's not receiving global sync. The transition to PLL_ON needs to be atomic as there's no guarantee that the thread isn't pre-empted or is able to complete before the IOMMU watchdog times out. [How] Backport the implementation from dcn401 back to dcn35. There's a functional difference in when the eDP output is disabled in dcn401 code so we don't want to utilize it directly. | ||||
| CVE-2024-53078 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match. | ||||
| CVE-2025-71254 | 2 Google, Unisoc | 17 Android, Sc7731e, Sc9832e and 14 more | 2026-05-11 | 7.5 High |
| In Modem IMS, there is a possible improper input validation. This could lead to remote denial of service with no additional execution privileges needed. | ||||
| CVE-2026-31773 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: derive legacy responder STK authentication from MITM state The legacy responder path in smp_random() currently labels the stored STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved. For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result. This also keeps the legacy path aligned with the Secure Connections code, which already treats JUST_WORKS/JUST_CFM as unauthenticated. | ||||
| CVE-2026-43255 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix WARNING in usb_tx_block The function usb_tx_block() submits cardp->tx_urb without ensuring that any previous transmission on this URB has completed. If a second call occurs while the URB is still active (e.g. during rapid firmware loading), usb_submit_urb() detects the active state and triggers a warning: 'URB submitted while active'. Fix this by enforcing serialization: call usb_kill_urb() before submitting the new request. This ensures the URB is idle and safe to reuse. | ||||
| CVE-2026-6392 | 1 Tanium | 1 Threat Response | 2026-05-11 | 2.7 Low |
| Tanium addressed an information disclosure vulnerability in Threat Response. | ||||
| CVE-2024-41029 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: nvmem: core: limit cell sysfs permissions to main attribute ones The cell sysfs attribute should not provide more access to the nvmem data than the main attribute itself. For example if nvme_config::root_only was set, the cell attribute would still provide read access to everybody. Mask out permissions not available on the main attribute. | ||||
| CVE-2024-40990 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Add check for srq max_sge attribute max_sge attribute is passed by the user, and is inserted and used unchecked, so verify that the value doesn't exceed maximum allowed value before using it. | ||||
| CVE-2024-40983 | 2 Linux, Redhat | 3 Linux Kernel, Enterprise Linux, Rhel Eus | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: tipc: force a dst refcount before doing decryption As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before entering the xfrm type handlers"): "Crypto requests might return asynchronous. In this case we leave the rcu protected region, so force a refcount on the skb's destination entry before we enter the xfrm type input/output handlers." On TIPC decryption path it has the same problem, and skb_dst_force() should be called before doing decryption to avoid a possible crash. Shuang reported this issue when this warning is triggered: [] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug [] Workqueue: crypto cryptd_queue_worker [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Call Trace: [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc] [] tipc_rcv+0xcf5/0x1060 [tipc] [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc] [] cryptd_aead_crypt+0xdb/0x190 [] cryptd_queue_worker+0xed/0x190 [] process_one_work+0x93d/0x17e0 | ||||
| CVE-2024-40944 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Fix bug with call depth tracking The call to cc_platform_has() triggers a fault and system crash if call depth tracking is active because the GS segment has been reset by load_segments() and GS_BASE is now 0 but call depth tracking uses per-CPU variables to operate. Call cc_platform_has() earlier in the function when GS is still valid. [ bp: Massage. ] | ||||
| CVE-2026-43195 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate user queue size constraints Add validation to ensure user queue sizes meet hardware requirements: - Size must be a power of two for efficient ring buffer wrapping - Size must be at least AMDGPU_GPU_PAGE_SIZE to prevent undersized allocations This prevents invalid configurations that could lead to GPU faults or unexpected behavior. | ||||