Export limit exceeded: 423983 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 36454 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 30000 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (30000 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2022-49854 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mctp: Fix an error handling path in mctp_init() If mctp_neigh_init() return error, the routes resources should be released in the error handling path. Otherwise some resources leak. | ||||
| CVE-2022-49896 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: cxl/pmem: Fix cxl_pmem_region and cxl_memdev leak When a cxl_nvdimm object goes through a ->remove() event (device physically removed, nvdimm-bridge disabled, or nvdimm device disabled), then any associated regions must also be disabled. As highlighted by the cxl-create-region.sh test [1], a single device may host multiple regions, but the driver was only tracking one region at a time. This leads to a situation where only the last enabled region per nvdimm device is cleaned up properly. Other regions are leaked, and this also causes cxl_memdev reference leaks. Fix the tracking by allowing cxl_nvdimm objects to track multiple region associations. | ||||
| CVE-2022-49861 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove() A clk_prepare_enable() call in the probe is not balanced by a corresponding clk_disable_unprepare() in the remove function. Add the missing call. | ||||
| CVE-2025-1556 | 1 Westboy | 1 Cicadascms | 2025-10-01 | 4.7 Medium |
| A vulnerability, which was classified as problematic, has been found in westboy CicadasCMS 1.0. This issue affects some unknown processing of the file /system of the component Template Management. The manipulation leads to deserialization. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. | ||||
| CVE-2024-36949 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: amd/amdkfd: sync all devices to wait all processes being evicted If there are more than one device doing reset in parallel, the first device will call kfd_suspend_all_processes() to evict all processes on all devices, this call takes time to finish. other device will start reset and recover without waiting. if the process has not been evicted before doing recover, it will be restored, then caused page fault. | ||||
| CVE-2024-22341 | 1 Ibm | 2 Watson Query With Cloud Pak For Data, Watson Query With Cloud Pak For Data As A Service | 2025-09-30 | 5.3 Medium |
| IBM Watson Query on Cloud Pak for Data 4.0.0 through 4.0.9, 4.5.0 through 4.5.3, 4.6.0 through 4.6.6, 4.7.0 through 4.7.4, and 4.8.0 through 4.8.7 could allow unauthorized data access from a remote data source object due to improper privilege management. | ||||
| CVE-2024-45075 | 2 Ibm, Softwareag | 2 Webmethods Integration, Webmethods | 2025-09-29 | 8.8 High |
| IBM webMethods Integration 10.15 could allow an authenticated user to create scheduler tasks that would allow them to escalate their privileges to administrator due to missing authentication. | ||||
| CVE-2021-47530 | 1 Linux | 1 Linux Kernel | 2025-09-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix wait_fence submitqueue leak We weren't dropping the submitqueue reference in all paths. In particular, when the fence has already been signalled. Split out a helper to simplify handling this in the various different return paths. | ||||
| CVE-2024-0103 | 3 Linux, Microsoft, Nvidia | 3 Linux Kernel, Windows, Triton Inference Server | 2025-09-26 | 5.4 Medium |
| NVIDIA Triton Inference Server for Linux contains a vulnerability where a user may cause an incorrect Initialization of resource by network issue. A successful exploit of this vulnerability may lead to information disclosure. | ||||
| CVE-2024-56439 | 1 Huawei | 1 Harmonyos | 2025-09-26 | 7.5 High |
| Access control vulnerability in the identity authentication module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2024-46767 | 1 Linux | 1 Linux Kernel | 2025-09-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: phy: Fix missing of_node_put() for leds The call of of_get_child_by_name() will cause refcount incremented for leds, if it succeeds, it should call of_node_put() to decrease it, fix it. | ||||
| CVE-2024-35826 | 1 Linux | 1 Linux Kernel | 2025-09-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: block: Fix page refcounts for unaligned buffers in __bio_release_pages() Fix an incorrect number of pages being released for buffers that do not start at the beginning of a page. | ||||
| CVE-2023-31100 | 1 Phoenixtech | 1 Securecore Technology | 2025-09-25 | 8.4 High |
| Improper Access Control in SMI handler vulnerability in Phoenix SecureCore™ Technology™ 4 allows SPI flash modification. This issue affects SecureCore™ Technology™ 4: * from 4.3.0.0 before 4.3.0.203 * from 4.3.1.0 before 4.3.1.163 * from 4.4.0.0 before 4.4.0.217 * from 4.5.0.0 before 4.5.0.138 | ||||
| CVE-2022-48831 | 1 Linux | 1 Linux Kernel | 2025-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ima: fix reference leak in asymmetric_verify() Don't leak a reference to the key if its algorithm is unknown. | ||||
| CVE-2022-48823 | 1 Linux | 1 Linux Kernel | 2025-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Fix refcount issue when LOGO is received during TMF Hung task call trace was seen during LOGO processing. [ 974.309060] [0000:00:00.0]:[qedf_eh_device_reset:868]: 1:0:2:0: LUN RESET Issued... [ 974.309065] [0000:00:00.0]:[qedf_initiate_tmf:2422]: tm_flags 0x10 sc_cmd 00000000c16b930f op = 0x2a target_id = 0x2 lun=0 [ 974.309178] [0000:00:00.0]:[qedf_initiate_tmf:2431]: portid=016900 tm_flags =LUN RESET [ 974.309222] [0000:00:00.0]:[qedf_initiate_tmf:2438]: orig io_req = 00000000ec78df8f xid = 0x180 ref_cnt = 1. [ 974.309625] host1: rport 016900: Received LOGO request while in state Ready [ 974.309627] host1: rport 016900: Delete port [ 974.309642] host1: rport 016900: work event 3 [ 974.309644] host1: rport 016900: lld callback ev 3 [ 974.313243] [0000:61:00.2]:[qedf_execute_tmf:2383]:1: fcport is uploading, not executing flush. [ 974.313295] [0000:61:00.2]:[qedf_execute_tmf:2400]:1: task mgmt command success... [ 984.031088] INFO: task jbd2/dm-15-8:7645 blocked for more than 120 seconds. [ 984.031136] Not tainted 4.18.0-305.el8.x86_64 #1 [ 984.031166] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 984.031209] jbd2/dm-15-8 D 0 7645 2 0x80004080 [ 984.031212] Call Trace: [ 984.031222] __schedule+0x2c4/0x700 [ 984.031230] ? unfreeze_partials.isra.83+0x16e/0x1a0 [ 984.031233] ? bit_wait_timeout+0x90/0x90 [ 984.031235] schedule+0x38/0xa0 [ 984.031238] io_schedule+0x12/0x40 [ 984.031240] bit_wait_io+0xd/0x50 [ 984.031243] __wait_on_bit+0x6c/0x80 [ 984.031248] ? free_buffer_head+0x21/0x50 [ 984.031251] out_of_line_wait_on_bit+0x91/0xb0 [ 984.031257] ? init_wait_var_entry+0x50/0x50 [ 984.031268] jbd2_journal_commit_transaction+0x112e/0x19f0 [jbd2] [ 984.031280] kjournald2+0xbd/0x270 [jbd2] [ 984.031284] ? finish_wait+0x80/0x80 [ 984.031291] ? commit_timeout+0x10/0x10 [jbd2] [ 984.031294] kthread+0x116/0x130 [ 984.031300] ? kthread_flush_work_fn+0x10/0x10 [ 984.031305] ret_from_fork+0x1f/0x40 There was a ref count issue when LOGO is received during TMF. This leads to one of the I/Os hanging with the driver. Fix the ref count. | ||||
| CVE-2023-52697 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-09-25 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: sof_sdw_rt_sdca_jack_common: ctx->headset_codec_dev = NULL sof_sdw_rt_sdca_jack_exit() are used by different codecs, and some of them use the same dai name. For example, rt712 and rt713 both use "rt712-sdca-aif1" and sof_sdw_rt_sdca_jack_exit(). As a result, sof_sdw_rt_sdca_jack_exit() will be called twice by mc_dailink_exit_loop(). Set ctx->headset_codec_dev = NULL; after put_device(ctx->headset_codec_dev); to avoid ctx->headset_codec_dev being put twice. | ||||
| CVE-2021-3794 | 1 Vuelidate Project | 1 Vuelidate | 2025-09-24 | 7.5 High |
| vuelidate is vulnerable to Inefficient Regular Expression Complexity | ||||
| CVE-2022-48774 | 1 Linux | 1 Linux Kernel | 2025-09-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: dmaengine: ptdma: Fix the error handling path in pt_core_init() In order to free resources correctly in the error handling path of pt_core_init(), 2 goto's have to be switched. Otherwise, some resources will leak and we will try to release things that have not been allocated yet. Also move a dev_err() to a place where it is more meaningful. | ||||
| CVE-2024-50563 | 1 Fortinet | 4 Fortianalyzer, Fortianalyzer Cloud, Fortimanager and 1 more | 2025-09-24 | 6.7 Medium |
| A weak authentication in Fortinet FortiManager Cloud, FortiAnalyzer versions 7.6.0 through 7.6.1, 7.4.1 through 7.4.3, FortiAnalyzer Cloud versions 7.4.1 through 7.4.3, FortiManager versions 7.6.0 through 7.6.1, 7.4.1 through 7.4.3, FortiManager Cloud versions 7.4.1 through 7.4.3 allows attacker to execute unauthorized code or commands via a brute-force attack. | ||||
| CVE-2021-47460 | 1 Linux | 1 Linux Kernel | 2025-09-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix data corruption after conversion from inline format Commit 6dbf7bb55598 ("fs: Don't invalidate page buffers in block_write_full_page()") uncovered a latent bug in ocfs2 conversion from inline inode format to a normal inode format. The code in ocfs2_convert_inline_data_to_extents() attempts to zero out the whole cluster allocated for file data by grabbing, zeroing, and dirtying all pages covering this cluster. However these pages are beyond i_size, thus writeback code generally ignores these dirty pages and no blocks were ever actually zeroed on the disk. This oversight was fixed by commit 693c241a5f6a ("ocfs2: No need to zero pages past i_size.") for standard ocfs2 write path, inline conversion path was apparently forgotten; the commit log also has a reasoning why the zeroing actually is not needed. After commit 6dbf7bb55598, things became worse as writeback code stopped invalidating buffers on pages beyond i_size and thus these pages end up with clean PageDirty bit but with buffers attached to these pages being still dirty. So when a file is converted from inline format, then writeback triggers, and then the file is grown so that these pages become valid, the invalid dirtiness state is preserved, mark_buffer_dirty() does nothing on these pages (buffers are already dirty) but page is never written back because it is clean. So data written to these pages is lost once pages are reclaimed. Simple reproducer for the problem is: xfs_io -f -c "pwrite 0 2000" -c "pwrite 2000 2000" -c "fsync" \ -c "pwrite 4000 2000" ocfs2_file After unmounting and mounting the fs again, you can observe that end of 'ocfs2_file' has lost its contents. Fix the problem by not doing the pointless zeroing during conversion from inline format similarly as in the standard write path. [akpm@linux-foundation.org: fix whitespace, per Joseph] | ||||