Export limit exceeded: 22604 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (22604 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-47618 | 2 Linux, Nvidia | 2 Linux Kernel, Dynamo | 2026-08-05 | 7.5 High |
| NVIDIA Dynamo for Linux contains a vulnerability in the Rust multimodal media fetcher where an attacker could cause server-side request forgery. A successful exploit of this vulnerability might lead to information disclosure. | ||||
| CVE-2026-47619 | 2 Linux, Nvidia | 2 Linux Kernel, Dynamo | 2026-08-05 | 6.6 Medium |
| NVIDIA Dynamo for Linux examples and recipes contain a vulnerability where an attacker could cause a system failure. A successful exploit of this vulnerability might lead to code execution, data tampering, denial of service, and information disclosure. | ||||
| CVE-2026-47620 | 2 Linux, Nvidia | 2 Linux Kernel, Dynamo | 2026-08-05 | 6.5 Medium |
| NVIDIA Dynamo for Linux contains a vulnerability where an attacker could cause a race condition in the LoRA manager singleton initialization. A successful exploit of this vulnerability might lead to data tampering and denial of service. | ||||
| CVE-2026-47621 | 2 Linux, Nvidia | 2 Linux Kernel, Dynamo | 2026-08-05 | 6.5 Medium |
| NVIDIA Dynamo for Linux contains a vulnerability where an attacker could cause a race condition in the LoRA manager singleton initialization. A successful exploit of this vulnerability might lead to denial of service and data tampering. | ||||
| CVE-2026-47622 | 2 Linux, Nvidia | 2 Linux Kernel, Dynamo | 2026-08-05 | 5.3 Medium |
| NVIDIA Dynamo for Linux contains a vulnerability where an attacker could cause the generation of error messages that contain sensitive information. A successful exploit of this vulnerability might lead to information disclosure. | ||||
| CVE-2026-47623 | 2 Linux, Nvidia | 2 Linux Kernel, Dynamo | 2026-08-05 | 8.2 High |
| NVIDIA Dynamo for Linux contains a vulnerability where an attacker could cause deserialization of untrusted data. A successful exploit of this vulnerability might lead to denial of service and data tampering. | ||||
| CVE-2026-50524 | 4 Apple, Linux, Microsoft and 1 more | 8 Macos, Linux Kernel, .net and 5 more | 2026-08-05 | 7.5 High |
| Improper validation of specified type of input in .NET Framework allows an unauthorized attacker to deny service over a network. | ||||
| CVE-2026-50526 | 4 Apple, Linux, Microsoft and 1 more | 8 Macos, Linux Kernel, .net and 5 more | 2026-08-05 | 7 High |
| Improper link resolution before file access ('link following') in .NET allows an authorized attacker to perform tampering locally. | ||||
| CVE-2026-50528 | 4 Apple, Linux, Microsoft and 1 more | 8 Macos, Linux Kernel, .net and 5 more | 2026-08-05 | 8.2 High |
| Incorrect authorization in .NET allows an unauthorized attacker to bypass a security feature over a network. | ||||
| CVE-2026-50651 | 3 Apple, Linux, Microsoft | 7 Macos, Linux Kernel, .net and 4 more | 2026-08-05 | 7.5 High |
| Allocation of resources without limits or throttling in .NET allows an unauthorized attacker to deny service over a network. | ||||
| CVE-2026-50659 | 4 Apple, Linux, Microsoft and 1 more | 22 Macos, Linux Kernel, .net and 19 more | 2026-08-05 | 6.5 Medium |
| Improper encoding or escaping of output in .NET allows an authorized attacker to perform spoofing over a network. | ||||
| CVE-2026-48326 | 3 Adobe, Linux, Microsoft | 4 Campaign, Campaign Classic, Linux Kernel and 1 more | 2026-08-05 | 9.9 Critical |
| Adobe Campaign Classic (ACC) is affected by an Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability that could result in arbitrary code execution in the context of the current user. A low-privileged attacker could exploit this vulnerability to execute arbitrary code. Exploitation of this issue does not require user interaction. Scope is changed. | ||||
| CVE-2026-48399 | 3 Adobe, Linux, Microsoft | 4 Campaign, Campaign Classic, Linux Kernel and 1 more | 2026-08-05 | 7.5 High |
| Adobe Campaign Classic (ACC) is affected by a Violation of Secure Design Principles vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized read access. Exploitation of this issue does not require user interaction. | ||||
| CVE-2026-48331 | 3 Adobe, Linux, Microsoft | 4 Campaign, Campaign Classic, Linux Kernel and 1 more | 2026-08-05 | 10 Critical |
| Adobe Campaign Classic (ACC) is affected by a Server-Side Request Forgery (SSRF) vulnerability that could result in privilege escalation. Exploitation of this issue does not require user interaction. Scope is changed. | ||||
| CVE-2026-48317 | 3 Adobe, Linux, Microsoft | 4 Campaign, Campaign Classic, Linux Kernel and 1 more | 2026-08-05 | 9.6 Critical |
| Adobe Campaign Classic (ACC) is affected by an Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') vulnerability that could result in arbitrary code execution in the context of the current user. A low-privileged attacker could exploit this vulnerability to execute arbitrary code. Exploitation of this issue does not require user interaction. Scope is changed. | ||||
| CVE-2026-48333 | 3 Adobe, Linux, Microsoft | 4 Campaign, Campaign Classic, Linux Kernel and 1 more | 2026-08-05 | 9.8 Critical |
| Adobe Campaign Classic (ACC) is affected by an Incorrect Authorization vulnerability that could result in privilege escalation. An attacker could exploit this vulnerability to gain elevated privileges. Exploitation of this issue does not require user interaction. | ||||
| CVE-2026-48323 | 3 Adobe, Linux, Microsoft | 4 Campaign, Campaign Classic, Linux Kernel and 1 more | 2026-08-05 | 10 Critical |
| Adobe Campaign Classic (ACC) is affected by an Improper Neutralization of Special Elements Used in a Template Engine vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could exploit this vulnerability to execute arbitrary code. Exploitation of this issue does not require user interaction. Scope is changed. | ||||
| CVE-2023-52852 | 1 Linux | 1 Linux Kernel | 2026-08-05 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to avoid use-after-free on dic Call trace: __memcpy+0x128/0x250 f2fs_read_multi_pages+0x940/0xf7c f2fs_mpage_readpages+0x5a8/0x624 f2fs_readahead+0x5c/0x110 page_cache_ra_unbounded+0x1b8/0x590 do_sync_mmap_readahead+0x1dc/0x2e4 filemap_fault+0x254/0xa8c f2fs_filemap_fault+0x2c/0x104 __do_fault+0x7c/0x238 do_handle_mm_fault+0x11bc/0x2d14 do_mem_abort+0x3a8/0x1004 el0_da+0x3c/0xa0 el0t_64_sync_handler+0xc4/0xec el0t_64_sync+0x1b4/0x1b8 In f2fs_read_multi_pages(), once f2fs_decompress_cluster() was called if we hit cached page in compress_inode's cache, dic may be released, it needs break the loop rather than continuing it, in order to avoid accessing invalid dic pointer. | ||||
| CVE-2022-49201 | 1 Linux | 1 Linux Kernel | 2026-08-05 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: ibmvnic: fix race between xmit and reset There is a race between reset and the transmit paths that can lead to ibmvnic_xmit() accessing an scrq after it has been freed in the reset path. It can result in a crash like: Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000016189f8 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic] LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 Call Trace: [c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable) [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c9cfcc] sch_direct_xmit+0xec/0x330 [c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0 [c000000000c00ad4] __dev_queue_xmit+0x394/0x730 [c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding] [c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding] [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c00ca4] __dev_queue_xmit+0x564/0x730 [c000000000cf97e0] neigh_hh_output+0xd0/0x180 [c000000000cfa69c] ip_finish_output2+0x31c/0x5c0 [c000000000cfd244] __ip_queue_xmit+0x194/0x4f0 [c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0 [c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0 [c000000000d2d984] tcp_retransmit_skb+0x34/0x130 [c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0 [c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330 [c000000000d317bc] tcp_write_timer+0x5c/0x200 [c000000000243270] call_timer_fn+0x50/0x1c0 [c000000000243704] __run_timers.part.0+0x324/0x460 [c000000000243894] run_timer_softirq+0x54/0xa0 [c000000000ea713c] __do_softirq+0x15c/0x3e0 [c000000000166258] __irq_exit_rcu+0x158/0x190 [c000000000166420] irq_exit+0x20/0x40 [c00000000002853c] timer_interrupt+0x14c/0x2b0 [c000000000009a00] decrementer_common_virt+0x210/0x220 --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c The immediate cause of the crash is the access of tx_scrq in the following snippet during a reset, where the tx_scrq can be either NULL or an address that will soon be invalid: ibmvnic_xmit() { ... tx_scrq = adapter->tx_scrq[queue_num]; txq = netdev_get_tx_queue(netdev, queue_num); ind_bufp = &tx_scrq->ind_buf; if (test_bit(0, &adapter->resetting)) { ... } But beyond that, the call to ibmvnic_xmit() itself is not safe during a reset and the reset path attempts to avoid this by stopping the queue in ibmvnic_cleanup(). However just after the queue was stopped, an in-flight ibmvnic_complete_tx() could have restarted the queue even as the reset is progressing. Since the queue was restarted we could get a call to ibmvnic_xmit() which can then access the bad tx_scrq (or other fields). We cannot however simply have ibmvnic_complete_tx() check the ->resetting bit and skip starting the queue. This can race at the "back-end" of a good reset which just restarted the queue but has not cleared the ->resetting bit yet. If we skip restarting the queue due to ->resetting being true, the queue would remain stopped indefinitely potentially leading to transmit timeouts. IOW ->resetting is too broad for this purpose. Instead use a new flag that indicates whether or not the queues are active. Only the open/ reset paths control when the queues are active. ibmvnic_complete_tx() and others wake up the queue only if the queue is marked active. So we will have: A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open() ->resetting = true ->tx_queues_active = false disable tx queues ... ->tx_queues_active = true start tx queues B. Tx interrupt in ibmvnic_complete_tx(): if (->tx_queues_active) netif_wake_subqueue(); To ensure that ->tx_queues_active and state of the queues are consistent, we need a lock which: - must also be taken in the interrupt path (ibmvnic_complete_tx()) - shared across the multiple ---truncated--- | ||||
| CVE-2022-48864 | 1 Linux | 1 Linux Kernel | 2026-08-05 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: add validation for VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command When control vq receives a VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command request from the driver, presently there is no validation against the number of queue pairs to configure, or even if multiqueue had been negotiated or not is unverified. This may lead to kernel panic due to uninitialized resource for the queues were there any bogus request sent down by untrusted driver. Tie up the loose ends there. | ||||