Export limit exceeded: 29908 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (29908 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-6080 | 2 Lakeside Software, Lakesidesoftware | 2 Systrack Lsiagent Installer, Systrack Lsiagent | 2026-04-01 | 7.8 High |
| Lakeside Software’s SysTrack LsiAgent Installer version 10.7.8 for Windows contains a local privilege escalation vulnerability which allows attackers SYSTEM level access. | ||||
| CVE-2005-0012 | 1 Dillo | 1 Dillo | 2026-03-27 | N/A |
| Format string vulnerability in the a_Interface_msg function in Dillo before 0.8.3-r4 allows remote attackers to execute arbitrary code via format string specifiers in a web page. | ||||
| CVE-2024-0208 | 1 Wireshark | 1 Wireshark | 2026-03-27 | 7.8 High |
| GVCP dissector crash in Wireshark 4.2.0, 4.0.0 to 4.0.11, and 3.6.0 to 3.6.19 allows denial of service via packet injection or crafted capture file | ||||
| CVE-2025-71084 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/cm: Fix leaking the multicast GID table reference If the CM ID is destroyed while the CM event for multicast creating is still queued the cancel_work_sync() will prevent the work from running which also prevents destroying the ah_attr. This leaks a refcount and triggers a WARN: GID entry ref leak for dev syz1 index 2 ref=573 WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886 Destroy the ah_attr after canceling the work, it is safe to call this twice. | ||||
| CVE-2025-71090 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache. | ||||
| CVE-2025-71097 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix reference count leak when using error routes with nexthop objects When a nexthop object is deleted, it is marked as dead and then fib_table_flush() is called to flush all the routes that are using the dead nexthop. The current logic in fib_table_flush() is to only flush error routes (e.g., blackhole) when it is called as part of network namespace dismantle (i.e., with flush_all=true). Therefore, error routes are not flushed when their nexthop object is deleted: # ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1 As such, they keep holding a reference on the nexthop object which in turn holds a reference on the nexthop device, resulting in a reference count leak: # ip link del dev dummy1 [ 70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2 Fix by flushing error routes when their nexthop is marked as dead. IPv6 does not suffer from this problem. | ||||
| CVE-2023-53533 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Input: raspberrypi-ts - fix refcount leak in rpi_ts_probe rpi_firmware_get() take reference, we need to release it in error paths as well. Use devm_rpi_firmware_get() helper to handling the resources. Also remove the existing rpi_firmware_put(). | ||||
| CVE-2022-50505 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix pci device refcount leak in ppr_notifier() As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So call it before returning from ppr_notifier() to avoid refcount leak. | ||||
| CVE-2023-53606 | 1 Linux | 1 Linux Kernel | 2026-03-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: nfsd: clean up potential nfsd_file refcount leaks in COPY codepath There are two different flavors of the nfsd4_copy struct. One is embedded in the compound and is used directly in synchronous copies. The other is dynamically allocated, refcounted and tracked in the client struture. For the embedded one, the cleanup just involves releasing any nfsd_files held on its behalf. For the async one, the cleanup is a bit more involved, and we need to dequeue it from lists, unhash it, etc. There is at least one potential refcount leak in this code now. If the kthread_create call fails, then both the src and dst nfsd_files in the original nfsd4_copy object are leaked. The cleanup in this codepath is also sort of weird. In the async copy case, we'll have up to four nfsd_file references (src and dst for both flavors of copy structure). They are both put at the end of nfsd4_do_async_copy, even though the ones held on behalf of the embedded one outlive that structure. Change it so that we always clean up the nfsd_file refs held by the embedded copy structure before nfsd4_copy returns. Rework cleanup_async_copy to handle both inter and intra copies. Eliminate nfsd4_cleanup_intra_ssc since it now becomes a no-op. | ||||
| CVE-2007-2976 | 1 Opentext | 2 Firstclass, Server And Internet Services | 2026-03-23 | N/A |
| Centrinity FirstClass 8.3 and earlier, and Server and Internet Services 8.0 and earlier, do not properly handle a URL with a null ("%00") character, which allows remote attackers to conduct cross-site scripting (XSS) attacks. NOTE: the provenance of this information is unknown; the details are obtained solely from third party information. | ||||
| CVE-2026-20988 | 2 Samsung, Samsung Mobile | 2 Android, Samsung Mobile Devices | 2026-03-23 | 5.0 Medium |
| Improper verification of intent by broadcast receiver in Settings prior to SMR Mar-2026 Release 1 allows local attacker to launch arbitrary activity with Settings privilege. User interaction is required for triggering this vulnerability. | ||||
| CVE-2026-20990 | 2 Samsung, Samsung Mobile | 2 Android, Samsung Mobile Devices | 2026-03-23 | 8.1 High |
| Improper export of android application components in Secure Folder prior to SMR Mar-2026 Release 1 allows local attackers to launch arbitrary activity with Secure Folder privilege. | ||||
| CVE-2026-22204 | 2 Gvectors, Wordpress | 2 Wpdiscuz, Wordpress | 2026-03-23 | 3.7 Low |
| wpDiscuz before 7.6.47 contains an email header injection vulnerability that allows attackers to manipulate mail recipients by injecting malicious data into the comment_author_email cookie. Attackers can craft a malicious cookie value that, when processed through urldecode() and passed to wp_mail() functions, enables header injection to alter email recipients or inject additional headers. | ||||
| CVE-2023-53592 | 1 Linux | 1 Linux Kernel | 2026-03-21 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: gpio: sifive: Fix refcount leak in sifive_gpio_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak. | ||||
| CVE-2024-7557 | 1 Redhat | 2 Openshift Ai, Openshift Data Science | 2026-03-19 | 8.8 High |
| A vulnerability was found in OpenShift AI that allows for authentication bypass and privilege escalation across models within the same namespace. When deploying AI models, the UI provides the option to protect models with authentication. However, credentials from one model can be used to access other models and APIs within the same namespace. The exposed ServiceAccount tokens, visible in the UI, can be utilized with oc --token={token} to exploit the elevated view privileges associated with the ServiceAccount, leading to unauthorized access to additional resources. | ||||
| CVE-2025-71204 | 1 Linux | 1 Linux Kernel | 2026-03-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: smb/server: fix refcount leak in parse_durable_handle_context() When the command is a replay operation and -ENOEXEC is returned, the refcount of ksmbd_file must be released. | ||||
| CVE-2025-71223 | 1 Linux | 1 Linux Kernel | 2026-03-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: smb/server: fix refcount leak in smb2_open() When ksmbd_vfs_getattr() fails, the reference count of ksmbd_file must be released. | ||||
| CVE-2023-53610 | 1 Linux | 1 Linux Kernel | 2026-03-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: irqchip: Fix refcount leak in platform_irqchip_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak. | ||||
| CVE-2022-50390 | 1 Linux | 1 Linux Kernel | 2026-03-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/ttm: fix undefined behavior in bit shift for TTM_TT_FLAG_PRIV_POPULATED Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in ./include/drm/ttm/ttm_tt.h:122:26 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: <TASK> dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c ttm_bo_move_memcpy+0x3b4/0x460 [ttm] bo_driver_move+0x32/0x40 [drm_vram_helper] ttm_bo_handle_move_mem+0x118/0x200 [ttm] ttm_bo_validate+0xfa/0x220 [ttm] drm_gem_vram_pin_locked+0x70/0x1b0 [drm_vram_helper] drm_gem_vram_pin+0x48/0xb0 [drm_vram_helper] drm_gem_vram_plane_helper_prepare_fb+0x53/0xe0 [drm_vram_helper] drm_gem_vram_simple_display_pipe_prepare_fb+0x26/0x30 [drm_vram_helper] drm_simple_kms_plane_prepare_fb+0x4d/0xe0 [drm_kms_helper] drm_atomic_helper_prepare_planes+0xda/0x210 [drm_kms_helper] drm_atomic_helper_commit+0xc3/0x1e0 [drm_kms_helper] drm_atomic_commit+0x9c/0x160 [drm] drm_client_modeset_commit_atomic+0x33a/0x380 [drm] drm_client_modeset_commit_locked+0x77/0x220 [drm] drm_client_modeset_commit+0x31/0x60 [drm] __drm_fb_helper_restore_fbdev_mode_unlocked+0xa7/0x170 [drm_kms_helper] drm_fb_helper_set_par+0x51/0x90 [drm_kms_helper] fbcon_init+0x316/0x790 visual_init+0x113/0x1d0 do_bind_con_driver+0x2a3/0x5c0 do_take_over_console+0xa9/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> | ||||
| CVE-2025-39682 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-03-17 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: tls: fix handling of zero-length records on the rx_list Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rx_list. Next recvmsg() will pick it up from there. Queuing the skb to rx_list after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length). Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rx_list, and it's zero length. | ||||