Filtered by vendor Linux
Subscriptions
Total
12933 CVE
CVE | Vendors | Products | Updated | CVSS v3.1 |
---|---|---|---|---|
CVE-2024-38229 | 4 Apple, Linux, Microsoft and 1 more | 6 Macos, Linux Kernel, .net and 3 more | 2025-07-08 | 8.1 High |
.NET and Visual Studio Remote Code Execution Vulnerability | ||||
CVE-2024-43480 | 2 Linux, Microsoft | 2 Linux Kernel, Azure Service Fabric | 2025-07-08 | 6.6 Medium |
Azure Service Fabric for Linux Remote Code Execution Vulnerability | ||||
CVE-2022-23278 | 4 Apple, Google, Linux and 1 more | 11 Macos, Android, Linux Kernel and 8 more | 2025-07-08 | 5.9 Medium |
Microsoft Defender for Endpoint Spoofing Vulnerability | ||||
CVE-2024-56467 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-07 | 3.3 Low |
IBM EntireX 11.1 could allow a local user to obtain sensitive information when a detailed technical error message is returned. This information could be used in further attacks against the system. | ||||
CVE-2024-56493 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-07 | 3.3 Low |
IBM EntireX 11.1 could allow a local user to obtain sensitive information when a detailed technical error message is returned. This information could be used in further attacks against the system. | ||||
CVE-2024-56494 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-07 | 3.3 Low |
IBM EntireX 11.1 could allow a local user to obtain sensitive information when a detailed technical error message is returned. This information could be used in further attacks against the system. | ||||
CVE-2024-56495 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-07 | 3.3 Low |
IBM EntireX 11.1 could allow a local user to obtain sensitive information when a detailed technical error message is returned. This information could be used in further attacks against the system. | ||||
CVE-2024-56496 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-07 | 3.3 Low |
IBM EntireX 11.1 could allow a local user to obtain sensitive information when a detailed technical error message is returned. This information could be used in further attacks against the system. | ||||
CVE-2024-56810 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-07 | 3.3 Low |
IBM EntireX 11.1 could allow a local user to obtain sensitive information when a detailed technical error message is returned. This information could be used in further attacks against the system. | ||||
CVE-2024-56811 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-07 | 3.3 Low |
IBM EntireX 11.1 could allow a local user to obtain sensitive information when a detailed technical error message is returned. This information could be used in further attacks against the system. | ||||
CVE-2024-56812 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-07 | 3.3 Low |
IBM EntireX 11.1 could allow a local user to obtain sensitive information when a detailed technical error message is returned. This information could be used in further attacks against the system. | ||||
CVE-2024-54169 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-07 | 6.5 Medium |
IBM EntireX 11.1 could allow an authenticated attacker to traverse directories on the system. An attacker could send a specially crafted URL request containing "dot dot" sequences (/../) to view arbitrary files on the system. | ||||
CVE-2024-54170 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-07 | 5.5 Medium |
IBM EntireX 11.1 could allow a local user to cause a denial of service due to use of a regular expression with an inefficient complexity that consumes excessive CPU cycles. | ||||
CVE-2024-54171 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-07 | 7.1 High |
IBM EntireX 11.1 is vulnerable to an XML external entity injection (XXE) attack when processing XML data. An authenticated attacker could exploit this vulnerability to expose sensitive information or consume memory resources. | ||||
CVE-2025-37951 | 1 Linux | 1 Linux Kernel | 2025-07-07 | 7.0 High |
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Add job to pending list if the reset was skipped When a CL/CSD job times out, we check if the GPU has made any progress since the last timeout. If so, instead of resetting the hardware, we skip the reset and let the timer get rearmed. This gives long-running jobs a chance to complete. However, when `timedout_job()` is called, the job in question is removed from the pending list, which means it won't be automatically freed through `free_job()`. Consequently, when we skip the reset and keep the job running, the job won't be freed when it finally completes. This situation leads to a memory leak, as exposed in [1] and [2]. Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active"), this patch ensures the job is put back on the pending list when extending the timeout. | ||||
CVE-2024-57950 | 1 Linux | 1 Linux Kernel | 2025-07-07 | 5.5 Medium |
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominator defaults to 1 [WHAT & HOW] Variables, used as denominators and maybe not assigned to other values, should be initialized to non-zero to avoid DIVIDE_BY_ZERO, as reported by Coverity. (cherry picked from commit e2c4c6c10542ccfe4a0830bb6c9fd5b177b7bbb7) | ||||
CVE-2024-46702 | 1 Linux | 1 Linux Kernel | 2025-07-07 | 5.5 Medium |
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Mark XDomain as unplugged when router is removed I noticed that when we do discrete host router NVM upgrade and it gets hot-removed from the PCIe side as a result of NVM firmware authentication, if there is another host connected with enabled paths we hang in tearing them down. This is due to fact that the Thunderbolt networking driver also tries to cleanup the paths and ends up blocking in tb_disconnect_xdomain_paths() waiting for the domain lock. However, at this point we already cleaned the paths in tb_stop() so there is really no need for tb_disconnect_xdomain_paths() to do that anymore. Furthermore it already checks if the XDomain is unplugged and bails out early so take advantage of that and mark the XDomain as unplugged when we remove the parent router. | ||||
CVE-2024-57883 | 1 Linux | 1 Linux Kernel | 2025-07-06 | 5.5 Medium |
In the Linux kernel, the following vulnerability has been resolved: mm: hugetlb: independent PMD page table shared count The folio refcount may be increased unexpectly through try_get_folio() by caller such as split_huge_pages. In huge_pmd_unshare(), we use refcount to check whether a pmd page table is shared. The check is incorrect if the refcount is increased by the above caller, and this can cause the page table leaked: BUG: Bad page state in process sh pfn:109324 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324 flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff) page_type: f2(table) raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000 raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000 page dumped because: nonzero mapcount ... CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7 Tainted: [B]=BAD_PAGE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 dump_stack+0x18/0x28 bad_page+0x8c/0x130 free_page_is_bad_report+0xa4/0xb0 free_unref_page+0x3cc/0x620 __folio_put+0xf4/0x158 split_huge_pages_all+0x1e0/0x3e8 split_huge_pages_write+0x25c/0x2d8 full_proxy_write+0x64/0xd8 vfs_write+0xcc/0x280 ksys_write+0x70/0x110 __arm64_sys_write+0x24/0x38 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x34/0x128 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x190/0x198 The issue may be triggered by damon, offline_page, page_idle, etc, which will increase the refcount of page table. 1. The page table itself will be discarded after reporting the "nonzero mapcount". 2. The HugeTLB page mapped by the page table miss freeing since we treat the page table as shared and a shared page table will not be unmapped. Fix it by introducing independent PMD page table shared count. As described by comment, pt_index/pt_mm/pt_frag_refcount are used for s390 gmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscv pmds, so we can reuse the field as pt_share_count. | ||||
CVE-2023-52980 | 1 Linux | 1 Linux Kernel | 2025-07-06 | 6.7 Medium |
In the Linux kernel, the following vulnerability has been resolved: block: ublk: extending queue_size to fix overflow When validating drafted SPDK ublk target, in a case that assigning large queue depth to multiqueue ublk device, ublk target would run into a weird incorrect state. During rounds of review and debug, An overflow bug was found in ublk driver. In ublk_cmd.h, UBLK_MAX_QUEUE_DEPTH is 4096 which means each ublk queue depth can be set as large as 4096. But when setting qd for a ublk device, sizeof(struct ublk_queue) + depth * sizeof(struct ublk_io) will be larger than 65535 if qd is larger than 2728. Then queue_size is overflowed, and ublk_get_queue() references a wrong pointer position. The wrong content of ublk_queue elements will lead to out-of-bounds memory access. Extend queue_size in ublk_device as "unsigned int". | ||||
CVE-2024-57990 | 1 Linux | 1 Linux Kernel | 2025-07-06 | 7.8 High |
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix off by one in mt7925_load_clc() This comparison should be >= instead of > to prevent an out of bounds read and write. |