Vulnerabilities (CVE)

Filtered by vendor Linux Subscribe
Total 10484 CVE
CVE Vendors Products Updated CVSS v2 CVSS v3
CVE-2025-0154 2 Ibm, Linux 3 Aix, Txseries For Multiplatforms, Linux Kernel 2025-07-15 N/A 5.3 MEDIUM
IBM TXSeries for Multiplatforms 9.1 and 11.1 could disclose sensitive information to a remote attacker due to improper neutralization of HTTP headers.
CVE-2024-56476 2 Ibm, Linux 3 Aix, Txseries For Multiplatforms, Linux Kernel 2025-07-15 N/A 5.3 MEDIUM
IBM TXSeries for Multiplatforms 9.1 and 11.1 could allow an attacker to enumerate usernames due to an observable login attempt response discrepancy.
CVE-2023-33861 2 Ibm, Linux 2 Security Qradar Edr, Linux Kernel 2025-07-15 N/A 6.5 MEDIUM
IBM Security ReaQta EDR 3.12 could allow an attacker to spoof a trusted entity by interfering with the communication path between the host and client.
CVE-2024-45641 2 Ibm, Linux 2 Security Qradar Edr, Linux Kernel 2025-07-15 N/A 6.5 MEDIUM
IBM Security ReaQta EDR 3.12 could allow an attacker to perform unauthorized actions due to improper SSL certificate validation.
CVE-2024-45644 2 Ibm, Linux 2 Security Qradar Edr, Linux Kernel 2025-07-15 N/A 4.7 MEDIUM
IBM Security ReaQta 3.12 allows a privileged user to upload or transfer files of dangerous types that can be automatically processed within the product's environment.
CVE-2024-25051 3 Ibm, Linux, Microsoft 3 Jazz Reporting Service, Linux Kernel, Windows 2025-07-14 N/A 6.6 MEDIUM
IBM Jazz Reporting Service 7.0.2 and 7.0.3 does not invalidate session after logout which could allow an authenticated privileged user to impersonate another user on the system.
CVE-2025-27367 3 Ibm, Linux, Microsoft 3 Openpages With Watson, Linux Kernel, Windows 2025-07-14 N/A 5.3 MEDIUM
IBM OpenPages with Watson 8.3 and 9.0 is vulnerable to improper input validation due to bypassing of client-side validation for the data types and requiredness of fields for GRC Objects when an authenticated user sends a specially crafted payload to the server allowing for data to be saved without storing the required fields.
CVE-2024-49784 3 Ibm, Linux, Microsoft 3 Openpages With Watson, Linux Kernel, Windows 2025-07-14 N/A 5.3 MEDIUM
IBM OpenPages with Watson 8.3 and 9.0 could provide weaker than expected security in storage of encrypted data with AES encryption and CBC mode. If an authenticated remote attacker with access to the database or a local attacker with access to server files could extract the encrypted data values they could exploit this weaker algorithm to use additional cryptographic methods to possibly extract the encrypted data.
CVE-2024-49783 3 Ibm, Linux, Microsoft 3 Openpages With Watson, Linux Kernel, Windows 2025-07-14 N/A 5.3 MEDIUM
IBM OpenPages with Watson 8.3 and 9.0 could provide weaker than expected security in storage of encrypted data. If an authenticated remote attacker with access to the database or a local attacker with access to server files could extract the encrypted data, they could exploit this vulnerability to use additional cryptographic methods to possibly extract the encrypted data.
CVE-2023-43039 3 Ibm, Linux, Microsoft 3 Openpages With Watson, Linux Kernel, Windows 2025-07-14 N/A 6.1 MEDIUM
IBM OpenPages with Watson 9.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session
CVE-2025-1112 3 Ibm, Linux, Microsoft 3 Openpages With Watson, Linux Kernel, Windows 2025-07-14 N/A 4.3 MEDIUM
IBM OpenPages with Watson 8.3 and 9.0 could allow an authenticated user to obtain sensitive information that should only be available to privileged users.
CVE-2025-27369 3 Ibm, Linux, Microsoft 3 Openpages With Watson, Linux Kernel, Windows 2025-07-14 N/A 4.3 MEDIUM
IBM OpenPages with Watson 8.3 and 9.0 is vulnerable to information disclosure of sensitive information due to a weaker than expected security for certain REST end points used for the administration of OpenPages. An authenticated user is able to obtain certain information about system configuration and internal state which is only intended for administrators of the system.
CVE-2025-2073 2 Google, Linux 2 Chrome Os, Linux Kernel 2025-07-11 N/A 8.8 HIGH
Out-of-Bounds Read in netfilter/ipset in Linux Kernel ChromeOS [6.1, 5.15, 5.10, 5.4, 4.19] allows a local attacker with low privileges to trigger an out-of-bounds read, potentially leading to information disclosure
CVE-2025-1290 2 Google, Linux 2 Chrome Os, Linux Kernel 2025-07-11 N/A 8.1 HIGH
A race condition Use-After-Free vulnerability exists in the virtio_transport_space_update function within the Kernel 5.4 on ChromeOS. Concurrent allocation and freeing of the virtio_vsock_sock structure during an AF_VSOCK connect syscall can occur before a worker thread accesses it resulting in a dangling pointer and potential kernel code execution.
CVE-2020-36775 1 Linux 1 Linux Kernel 2025-07-11 N/A 5.5 MEDIUM
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid potential deadlock Using f2fs_trylock_op() in f2fs_write_compressed_pages() to avoid potential deadlock like we did in f2fs_write_single_data_page().
CVE-2024-27070 1 Linux 1 Linux Kernel 2025-07-10 N/A 7.8 HIGH
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free issue in f2fs_filemap_fault syzbot reports a f2fs bug as below: BUG: KASAN: slab-use-after-free in f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49 Read of size 8 at addr ffff88807bb22680 by task syz-executor184/5058 CPU: 0 PID: 5058 Comm: syz-executor184 Not tainted 6.7.0-syzkaller-09928-g052d534373b7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x163/0x540 mm/kasan/report.c:488 kasan_report+0x142/0x170 mm/kasan/report.c:601 f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49 __do_fault+0x131/0x450 mm/memory.c:4376 do_shared_fault mm/memory.c:4798 [inline] do_fault mm/memory.c:4872 [inline] do_pte_missing mm/memory.c:3745 [inline] handle_pte_fault mm/memory.c:5144 [inline] __handle_mm_fault+0x23b7/0x72b0 mm/memory.c:5285 handle_mm_fault+0x27e/0x770 mm/memory.c:5450 do_user_addr_fault arch/x86/mm/fault.c:1364 [inline] handle_page_fault arch/x86/mm/fault.c:1507 [inline] exc_page_fault+0x456/0x870 arch/x86/mm/fault.c:1563 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570 The root cause is: in f2fs_filemap_fault(), vmf->vma may be not alive after filemap_fault(), so it may cause use-after-free issue when accessing vmf->vma->vm_flags in trace_f2fs_filemap_fault(). So it needs to keep vm_flags in separated temporary variable for tracepoint use.
CVE-2024-26726 1 Linux 1 Linux Kernel 2025-07-10 N/A 5.5 MEDIUM
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't drop extent_map for free space inode on write error While running the CI for an unrelated change I hit the following panic with generic/648 on btrfs_holes_spacecache. assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Call Trace: <TASK> extent_write_cache_pages+0x2ac/0x8f0 extent_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_cache+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813/0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 This happens because we fail to write out the free space cache in one instance, come back around and attempt to write it again. However on the second pass through we go to call btrfs_get_extent() on the inode to get the extent mapping. Because this is a new block group, and with the free space inode we always search the commit root to avoid deadlocking with the tree, we find nothing and return a EXTENT_MAP_HOLE for the requested range. This happens because the first time we try to write the space cache out we hit an error, and on an error we drop the extent mapping. This is normal for normal files, but the free space cache inode is special. We always expect the extent map to be correct. Thus the second time through we end up with a bogus extent map. Since we're deprecating this feature, the most straightforward way to fix this is to simply skip dropping the extent map range for this failed range. I shortened the test by using error injection to stress the area to make it easier to reproduce. With this patch in place we no longer panic with my error injection test.
CVE-2025-26646 3 Apple, Linux, Microsoft 6 Macos, Linux Kernel, .net and 3 more 2025-07-10 N/A 8.0 HIGH
External control of file name or path in .NET, Visual Studio, and Build Tools for Visual Studio allows an authorized attacker to perform spoofing over a network.
CVE-2025-21171 3 Apple, Linux, Microsoft 6 Macos, Linux Kernel, .net and 3 more 2025-07-10 N/A 7.5 HIGH
.NET Remote Code Execution Vulnerability
CVE-2025-30399 3 Apple, Linux, Microsoft 6 Macos, Linux Kernel, .net and 3 more 2025-07-10 N/A 7.5 HIGH
Untrusted search path in .NET and Visual Studio allows an unauthorized attacker to execute code over a network.