Export limit exceeded: 29948 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (29948 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| 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] | ||||
| CVE-2021-47431 | 1 Linux | 1 Linux Kernel | 2025-09-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gart.bo pin_count leak gmc_v{9,10}_0_gart_disable() isn't called matched with correspoding gart_enbale function in SRIOV case. This will lead to gart.bo pin_count leak on driver unload. | ||||
| CVE-2022-49109 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-09-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ceph: fix inode reference leakage in ceph_get_snapdir() The ceph_get_inode() will search for or insert a new inode into the hash for the given vino, and return a reference to it. If new is non-NULL, its reference is consumed. We should release the reference when in error handing cases. | ||||
| CVE-2022-49088 | 1 Linux | 1 Linux Kernel | 2025-09-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: dpaa2-ptp: Fix refcount leak in dpaa2_ptp_probe This node pointer is returned by of_find_compatible_node() with refcount incremented. Calling of_node_put() to aovid the refcount leak. | ||||
| CVE-2022-49161 | 1 Linux | 1 Linux Kernel | 2025-09-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Fix error handling in mt8183_da7219_max98357_dev_probe The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This function only calls of_node_put() in the regular path. And it will cause refcount leak in error paths. Fix this by calling of_node_put() in error handling too. | ||||
| CVE-2022-49246 | 1 Linux | 1 Linux Kernel | 2025-09-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: atmel: Fix error handling in snd_proto_probe The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This function only calls of_node_put() in the regular path. And it will cause refcount leak in error paths. Fix this by calling of_node_put() in error handling too. | ||||
| CVE-2022-49245 | 1 Linux | 1 Linux Kernel | 2025-09-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: rockchip: Fix PM usage reference of rockchip_i2s_tdm_resume pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. We fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. | ||||
| CVE-2022-49244 | 1 Linux | 1 Linux Kernel | 2025-09-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192-mt6359: Fix error handling in mt8192_mt6359_dev_probe The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This function only calls of_node_put() in the regular path. And it will cause refcount leak in error paths. Fix this by calling of_node_put() in error handling too. | ||||
| CVE-2022-49421 | 1 Linux | 1 Linux Kernel | 2025-09-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: video: fbdev: clcdfb: Fix refcount leak in clcdfb_of_vram_setup of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. | ||||