Search
CVE Explorer
Search the full tracked CVE corpus across every vendor — by keyword, vendor, severity, CVSS band and publication date. Server-rendered; each filtered view has its own URL.
01
Filters
Submit to refine — state is held in the URL.
02
Results
34,808 matching · page 642/697Each CVE id links to its NVD record.
| CVE | Severity | CVSS | Summary | Published |
|---|---|---|---|---|
| CVE-2024-57875(opens NVD record) | High | 7.8 | In the Linux kernel, the following vulnerability has been resolved: block: RCU protect disk->conv_zones_bitmap Ensure that a disk revalidation changing the conventional zones bitmap of a disk does not cause invalid memory references when using the disk_zone_is_conv() helper by RCU protecting the disk->conv_zones_bitmap pointer. disk_zone_is_conv() is modified to operate under the RCU read lock and the function disk_set_conv_zones_bitmap() is added to update a disk conv_zones_bitmap pointer using rcu_replace_pointer() with the disk zone_wplugs_lock spinlock held. disk_free_zone_resources() is modified to call disk_update_zone_resources() with a NULL bitmap pointer to free the disk conv_zones_bitmap. disk_set_conv_zones_bitmap() is also used in disk_update_zone_resources() to set the new (revalidated) bitmap and free the old one. | Jan 11, 2025 |
| CVE-2024-57850(opens NVD record) | High | 7.8 | In the Linux kernel, the following vulnerability has been resolved: jffs2: Prevent rtime decompress memory corruption The rtime decompression routine does not fully check bounds during the entirety of the decompression pass and can corrupt memory outside the decompression buffer if the compressed data is corrupted. This adds the required check to prevent this failure mode. | Jan 11, 2025 |
| CVE-2024-57849(opens NVD record) | High | 7.8 | In the Linux kernel, the following vulnerability has been resolved: s390/cpum_sf: Handle CPU hotplug remove during sampling CPU hotplug remove handling triggers the following function call sequence: CPUHP_AP_PERF_S390_SF_ONLINE --> s390_pmu_sf_offline_cpu() ... CPUHP_AP_PERF_ONLINE --> perf_event_exit_cpu() The s390 CPUMF sampling CPU hotplug handler invokes: s390_pmu_sf_offline_cpu() +--> cpusf_pmu_setup() +--> setup_pmc_cpu() +--> deallocate_buffers() This function de-allocates all sampling data buffers (SDBs) allocated for that CPU at event initialization. It also clears the PMU_F_RESERVED bit. The CPU is gone and can not be sampled. With the event still being active on the removed CPU, the CPU event hotplug support in kernel performance subsystem triggers the following function calls on the removed CPU: perf_event_exit_cpu() +--> perf_event_exit_cpu_context() +--> __perf_event_exit_context() +--> __perf_remove_from_context() +--> event_sched_out() +--> cpumsf_pmu_del() +--> cpumsf_pmu_stop() +--> hw_perf_event_update() to stop and remove the event. During removal of the event, the sampling device driver tries to read out the remaining samples from the sample data buffers (SDBs). But they have already been freed (and may have been re-assigned). This may lead to a use after free situation in which case the samples are most likely invalid. In the best case the memory has not been reassigned and still contains valid data. Remedy this situation and check if the CPU is still in reserved state (bit PMU_F_RESERVED set). In this case the SDBs have not been released an contain valid data. This is always the case when the event is removed (and no CPU hotplug off occured). If the PMU_F_RESERVED bit is not set, the SDB buffers are gone. | Jan 11, 2025 |
| CVE-2024-57843(opens NVD record) | Critical | 9.8 | In the Linux kernel, the following vulnerability has been resolved: virtio-net: fix overflow inside virtnet_rq_alloc When the frag just got a page, then may lead to regression on VM. Specially if the sysctl net.core.high_order_alloc_disable value is 1, then the frag always get a page when do refill. Which could see reliable crashes or scp failure (scp a file 100M in size to VM). The issue is that the virtnet_rq_dma takes up 16 bytes at the beginning of a new frag. When the frag size is larger than PAGE_SIZE, everything is fine. However, if the frag is only one page and the total size of the buffer and virtnet_rq_dma is larger than one page, an overflow may occur. The commit f9dac92ba908 ("virtio_ring: enable premapped mode whatever use_dma_api") introduced this problem. And we reverted some commits to fix this in last linux version. Now we try to enable it and fix this bug directly. Here, when the frag size is not enough, we reduce the buffer len to fix this problem. | Jan 11, 2025 |
| CVE-2024-57804(opens NVD record) | High | 7.3 | In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix corrupt config pages PHY state is switched in sysfs The driver, through the SAS transport, exposes a sysfs interface to enable/disable PHYs in a controller/expander setup. When multiple PHYs are disabled and enabled in rapid succession, the persistent and current config pages related to SAS IO unit/SAS Expander pages could get corrupted. Use separate memory for each config request. | Jan 11, 2025 |
| CVE-2024-57793(opens NVD record) | Critical | 9.3 | In the Linux kernel, the following vulnerability has been resolved: virt: tdx-guest: Just leak decrypted memory on unrecoverable errors In CoCo VMs it is possible for the untrusted host to cause set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. Leak the decrypted memory when set_memory_decrypted() fails, and don't need to print an error since set_memory_decrypted() will call WARN_ONCE(). | Jan 11, 2025 |
| CVE-2024-57792(opens NVD record) | High | 7.3 | In the Linux kernel, the following vulnerability has been resolved: power: supply: gpio-charger: Fix set charge current limits Fix set charge current limits for devices which allow to set the lowest charge current limit to be greater zero. If requested charge current limit is below lowest limit, the index equals current_limit_map_size which leads to accessing memory beyond allocated memory. | Jan 11, 2025 |
| CVE-2024-57791(opens NVD record) | High | 7.5 | In the Linux kernel, the following vulnerability has been resolved: net/smc: check return value of sock_recvmsg when draining clc data When receiving clc msg, the field length in smc_clc_msg_hdr indicates the length of msg should be received from network and the value should not be fully trusted as it is from the network. Once the value of length exceeds the value of buflen in function smc_clc_wait_msg it may run into deadloop when trying to drain the remaining data exceeding buflen. This patch checks the return value of sock_recvmsg when draining data in case of deadloop in draining. | Jan 11, 2025 |
| CVE-2024-56788(opens NVD record) | High | 7.5 | In the Linux kernel, the following vulnerability has been resolved: net: ethernet: oa_tc6: fix tx skb race condition between reference pointers There are two skb pointers to manage tx skb's enqueued from n/w stack. waiting_tx_skb pointer points to the tx skb which needs to be processed and ongoing_tx_skb pointer points to the tx skb which is being processed. SPI thread prepares the tx data chunks from the tx skb pointed by the ongoing_tx_skb pointer. When the tx skb pointed by the ongoing_tx_skb is processed, the tx skb pointed by the waiting_tx_skb is assigned to ongoing_tx_skb and the waiting_tx_skb pointer is assigned with NULL. Whenever there is a new tx skb from n/w stack, it will be assigned to waiting_tx_skb pointer if it is NULL. Enqueuing and processing of a tx skb handled in two different threads. Consider a scenario where the SPI thread processed an ongoing_tx_skb and it moves next tx skb from waiting_tx_skb pointer to ongoing_tx_skb pointer without doing any NULL check. At this time, if the waiting_tx_skb pointer is NULL then ongoing_tx_skb pointer is also assigned with NULL. After that, if a new tx skb is assigned to waiting_tx_skb pointer by the n/w stack and there is a chance to overwrite the tx skb pointer with NULL in the SPI thread. Finally one of the tx skb will be left as unhandled, resulting packet missing and memory leak. - Consider the below scenario where the TXC reported from the previous transfer is 10 and ongoing_tx_skb holds an tx ethernet frame which can be transported in 20 TXCs and waiting_tx_skb is still NULL. tx_credits = 10; /* 21 are filled in the previous transfer */ ongoing_tx_skb = 20; waiting_tx_skb = NULL; /* Still NULL */ - So, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) becomes true. - After oa_tc6_prepare_spi_tx_buf_for_tx_skbs() ongoing_tx_skb = 10; waiting_tx_skb = NULL; /* Still NULL */ - Perform SPI transfer. - Process SPI rx buffer to get the TXC from footers. - Now let's assume previously filled 21 TXCs are freed so we are good to transport the next remaining 10 tx chunks from ongoing_tx_skb. tx_credits = 21; ongoing_tx_skb = 10; waiting_tx_skb = NULL; - So, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) becomes true again. - In the oa_tc6_prepare_spi_tx_buf_for_tx_skbs() ongoing_tx_skb = NULL; waiting_tx_skb = NULL; - Now the below bad case might happen, Thread1 (oa_tc6_start_xmit) Thread2 (oa_tc6_spi_thread_handler) --------------------------- ----------------------------------- - if waiting_tx_skb is NULL - if ongoing_tx_skb is NULL - ongoing_tx_skb = waiting_tx_skb - waiting_tx_skb = skb - waiting_tx_skb = NULL ... - ongoing_tx_skb = NULL - if waiting_tx_skb is NULL - waiting_tx_skb = skb To overcome the above issue, protect the moving of tx skb reference from waiting_tx_skb pointer to ongoing_tx_skb pointer and assigning new tx skb to waiting_tx_skb pointer, so that the other thread can't access the waiting_tx_skb pointer until the current thread completes moving the tx skb reference safely. | Jan 11, 2025 |
| CVE-2024-56368(opens NVD record) | High | 7.1 | In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix overflow in __rb_map_vma An overflow occurred when performing the following calculation: nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff; Add a check before the calculation to avoid this problem. syzbot reported this as a slab-out-of-bounds in __rb_map_vma: BUG: KASAN: slab-out-of-bounds in __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058 Read of size 8 at addr ffff8880767dd2b8 by task syz-executor187/5836 CPU: 0 UID: 0 PID: 5836 Comm: syz-executor187 Not tainted 6.13.0-rc2-syzkaller-00159-gf932fb9b4074 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xc3/0x620 mm/kasan/report.c:489 kasan_report+0xd9/0x110 mm/kasan/report.c:602 __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058 ring_buffer_map+0x56e/0x9b0 kernel/trace/ring_buffer.c:7138 tracing_buffers_mmap+0xa6/0x120 kernel/trace/trace.c:8482 call_mmap include/linux/fs.h:2183 [inline] mmap_file mm/internal.h:124 [inline] __mmap_new_file_vma mm/vma.c:2291 [inline] __mmap_new_vma mm/vma.c:2355 [inline] __mmap_region+0x1786/0x2670 mm/vma.c:2456 mmap_region+0x127/0x320 mm/mmap.c:1348 do_mmap+0xc00/0xfc0 mm/mmap.c:496 vm_mmap_pgoff+0x1ba/0x360 mm/util.c:580 ksys_mmap_pgoff+0x32c/0x5c0 mm/mmap.c:542 __do_sys_mmap arch/x86/kernel/sys_x86_64.c:89 [inline] __se_sys_mmap arch/x86/kernel/sys_x86_64.c:82 [inline] __x64_sys_mmap+0x125/0x190 arch/x86/kernel/sys_x86_64.c:82 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The reproducer for this bug is: ------------------------8<------------------------- #include <fcntl.h> #include <stdlib.h> #include <unistd.h> #include <asm/types.h> #include <sys/mman.h> int main(int argc, char **argv) { int page_size = getpagesize(); int fd; void *meta; system("echo 1 > /sys/kernel/tracing/buffer_size_kb"); fd = open("/sys/kernel/tracing/per_cpu/cpu0/trace_pipe_raw", O_RDONLY); meta = mmap(NULL, page_size, PROT_READ, MAP_SHARED, fd, page_size * 5); } ------------------------>8------------------------- | Jan 11, 2025 |
| CVE-2024-55639(opens NVD record) | High | 8.4 | In the Linux kernel, the following vulnerability has been resolved: net: renesas: rswitch: avoid use-after-put for a device tree node The device tree node saved in the rswitch_device structure is used at several driver locations. So passing this node to of_node_put() after the first use is wrong. Move of_node_put() for this node to exit paths. | Jan 11, 2025 |
| CVE-2024-52319(opens NVD record) | High | 7.8 | In the Linux kernel, the following vulnerability has been resolved: mm: use aligned address in clear_gigantic_page() In current kernel, hugetlb_no_page() calls folio_zero_user() with the fault address. Where the fault address may be not aligned with the huge page size. Then, folio_zero_user() may call clear_gigantic_page() with the address, while clear_gigantic_page() requires the address to be huge page size aligned. So, this may cause memory corruption or information leak, addtional, use more obvious naming 'addr_hint' instead of 'addr' for clear_gigantic_page(). | Jan 11, 2025 |
| CVE-2024-51729(opens NVD record) | High | 7.8 | In the Linux kernel, the following vulnerability has been resolved: mm: use aligned address in copy_user_gigantic_page() In current kernel, hugetlb_wp() calls copy_user_large_folio() with the fault address. Where the fault address may be not aligned with the huge page size. Then, copy_user_large_folio() may call copy_user_gigantic_page() with the address, while copy_user_gigantic_page() requires the address to be huge page size aligned. So, this may cause memory corruption or information leak, addtional, use more obvious naming 'addr_hint' instead of 'addr' for copy_user_gigantic_page(). | Jan 11, 2025 |
| CVE-2024-49573(opens NVD record) | High | 7.0 | In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix NEXT_BUDDY Adam reports that enabling NEXT_BUDDY insta triggers a WARN in pick_next_entity(). Moving clear_buddies() up before the delayed dequeue bits ensures no ->next buddy becomes delayed. Further ensure no new ->next buddy ever starts as delayed. | Jan 11, 2025 |
| CVE-2024-49571(opens NVD record) | Critical | 9.1 | In the Linux kernel, the following vulnerability has been resolved: net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msg When receiving proposal msg in server, the field iparea_offset and the field ipv6_prefixes_cnt in proposal msg are from the remote client and can not be fully trusted. Especially the field iparea_offset, once exceed the max value, there has the chance to access wrong address, and crash may happen. This patch checks iparea_offset and ipv6_prefixes_cnt before using them. | Jan 11, 2025 |
| CVE-2024-49569(opens NVD record) | High | 7.5 | In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: unquiesce admin_q before destroy it Kernel will hang on destroy admin_q while we create ctrl failed, such as following calltrace: PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme" #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15 #1 [ff61d23de260fc08] schedule at ffffffff8323c014 #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1 #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006 #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362 #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25 RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574 RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 0000000000000004 RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004 R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b This due to we have quiesced admi_q before cancel requests, but forgot to unquiesce before destroy it, as a result we fail to drain the pending requests, and hang on blk_mq_freeze_queue_wait() forever. Here try to reuse nvme_rdma_teardown_admin_queue() to fix this issue and simplify the code. | Jan 11, 2025 |
| CVE-2024-49568(opens NVD record) | Critical | 9.8 | In the Linux kernel, the following vulnerability has been resolved: net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msg When receiving proposal msg in server, the fields v2_ext_offset/ eid_cnt/ism_gid_cnt in proposal msg are from the remote client and can not be fully trusted. Especially the field v2_ext_offset, once exceed the max value, there has the chance to access wrong address, and crash may happen. This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cnt before using them. | Jan 11, 2025 |
| CVE-2024-47809(opens NVD record) | Medium | 5.5 | In the Linux kernel, the following vulnerability has been resolved: dlm: fix possible lkb_resource null dereference This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb->lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded. The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference. In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists. | Jan 11, 2025 |
| CVE-2024-47794(opens NVD record) | High | 7.8 | In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tailcall infinite loop caused by freplace There is a potential infinite loop issue that can occur when using a combination of tail calls and freplace. In an upcoming selftest, the attach target for entry_freplace of tailcall_freplace.c is subprog_tc of tc_bpf2bpf.c, while the tail call in entry_freplace leads to entry_tc. This results in an infinite loop: entry_tc -> subprog_tc -> entry_freplace --tailcall-> entry_tc. The problem arises because the tail_call_cnt in entry_freplace resets to zero each time entry_freplace is executed, causing the tail call mechanism to never terminate, eventually leading to a kernel panic. To fix this issue, the solution is twofold: 1. Prevent updating a program extended by an freplace program to a prog_array map. 2. Prevent extending a program that is already part of a prog_array map with an freplace program. This ensures that: * If a program or its subprogram has been extended by an freplace program, it can no longer be updated to a prog_array map. * If a program has been added to a prog_array map, neither it nor its subprograms can be extended by an freplace program. Moreover, an extension program should not be tailcalled. As such, return -EINVAL if the program has a type of BPF_PROG_TYPE_EXT when adding it to a prog_array map. Additionally, fix a minor code style issue by replacing eight spaces with a tab for proper formatting. | Jan 11, 2025 |
| CVE-2024-47408(opens NVD record) | Critical | 9.8 | In the Linux kernel, the following vulnerability has been resolved: net/smc: check smcd_v2_ext_offset when receiving proposal msg When receiving proposal msg in server, the field smcd_v2_ext_offset in proposal msg is from the remote client and can not be fully trusted. Once the value of smcd_v2_ext_offset exceed the max value, there has the chance to access wrong address, and crash may happen. This patch checks the value of smcd_v2_ext_offset before using it. | Jan 11, 2025 |
| CVE-2025-0107(opens NVD record) | Critical | 9.8 | An OS command injection vulnerability in Palo Alto Networks Expedition enables an unauthenticated attacker to run arbitrary OS commands as the www-data user in Expedition, which results in the disclosure of usernames, cleartext passwords, device configurations, and device API keys for firewalls running PAN-OS software. | Jan 11, 2025 |
| CVE-2025-0106(opens NVD record) | Medium | 5.3 | A wildcard expansion vulnerability in Palo Alto Networks Expedition allows an unauthenticated attacker to enumerate files on the host filesystem. | Jan 11, 2025 |
| CVE-2025-0105(opens NVD record) | Critical | 9.1 | An arbitrary file deletion vulnerability in Palo Alto Networks Expedition enables an unauthenticated attacker to delete arbitrary files accessible to the www-data user on the host filesystem. | Jan 11, 2025 |
| CVE-2025-0104(opens NVD record) | Medium | 6.1 | A reflected cross-site scripting (XSS) vulnerability in Palo Alto Networks Expedition enables attackers to execute malicious JavaScript code in the context of an authenticated Expedition user’s browser if that authenticated user clicks a malicious link that allows phishing attacks and could lead to Expedition browser-session theft. | Jan 11, 2025 |
| CVE-2025-0103(opens NVD record) | High | 8.8 | An SQL injection vulnerability in Palo Alto Networks Expedition enables an authenticated attacker to reveal Expedition database contents, such as password hashes, usernames, device configurations, and device API keys. This vulnerability also enables attackers to create and read arbitrary files on the Expedition system. | Jan 11, 2025 |
| CVE-2024-9188(opens NVD record) | High | 8.8 | Specially constructed queries cause cross platform scripting leaking administrator tokens | Jan 10, 2025 |
| CVE-2024-9134(opens NVD record) | High | 8.3 | Multiple SQL Injection vulnerabilities exist in the reporting application. A user with advanced report application access rights can exploit the SQL injection, allowing them to execute commands on the underlying operating system with elevated privileges. | Jan 10, 2025 |
| CVE-2024-9133(opens NVD record) | Medium | 6.6 | A user with administrator privileges is able to retrieve authentication tokens | Jan 10, 2025 |
| CVE-2024-9132(opens NVD record) | High | 8.1 | The administrator is able to configure an insecure captive portal script | Jan 10, 2025 |
| CVE-2024-9131(opens NVD record) | High | 7.2 | A user with administrator privileges can perform command injection | Jan 10, 2025 |
| CVE-2024-47520(opens NVD record) | High | 7.6 | A user with advanced report application access rights can perform actions for which they are not authorized | Jan 10, 2025 |
| CVE-2024-47519(opens NVD record) | High | 8.3 | Backup uploads to ETM subject to man-in-the-middle interception | Jan 10, 2025 |
| CVE-2024-47518(opens NVD record) | Medium | 6.4 | Specially constructed queries targeting ETM could discover active remote access sessions | Jan 10, 2025 |
| CVE-2024-47517(opens NVD record) | Medium | 6.8 | Expired and unusable administrator authentication tokens can be revealed by units that have timed out from ETM access | Jan 10, 2025 |
| CVE-2024-54998(opens NVD record) | Medium | 5.4 | MonicaHQ v4.1.2 was discovered to contain an authenticated Client-Side Injection vulnerability via the Reason parameter at /people/h:[id]/debts/create. | Jan 10, 2025 |
| CVE-2024-54997(opens NVD record) | Medium | 5.4 | MonicaHQ v4.1.1 was discovered to contain an authenticated Client-Side Injection vulnerability via the entry text field at /journal/entries/ID/edit. | Jan 10, 2025 |
| CVE-2024-54996(opens NVD record) | High | 8.8 | MonicaHQ v4.1.2 was discovered to contain multiple authenticated Client-Side Injection vulnerabilities via the title and description parameters at /people/ID/reminders/create. | Jan 10, 2025 |
| CVE-2024-54994(opens NVD record) | Medium | 6.5 | MonicaHQ v4.1.2 was discovered to contain multiple Client-Side Injection vulnerabilities via the first_name and last_name parameters in the Add a new relationship feature. | Jan 10, 2025 |
| CVE-2024-41787(opens NVD record) | Critical | 9.8 | IBM Engineering Requirements Management DOORS Next 7.0.2 and 7.0.3 could allow a remote attacker to bypass security restrictions, caused by a race condition. By sending a specially crafted request, an attacker could exploit this vulnerability to remotely execute code. | Jan 10, 2025 |
| CVE-2025-21380(opens NVD record) | High | 8.8 | Improper access control in Azure SaaS Resources allows an authorized attacker to disclose information over a network. | Jan 9, 2025 |
| CVE-2025-21385(opens NVD record) | High | 8.8 | A Server-Side Request Forgery (SSRF) vulnerability in Microsoft Purview allows an authorized attacker to disclose information over a network. | Jan 9, 2025 |
| CVE-2024-54887(opens NVD record) | High | 8.0 | TP-Link TL-WR940N V3 and V4 with firmware 3.16.9 and earlier contain a buffer overflow via the dnsserver1 and dnsserver2 parameters at /userRpm/Wan6to4TunnelCfgRpm.htm. This vulnerability allows an authenticated attacker to execute arbitrary code on the remote device in the context of the root user. | Jan 9, 2025 |
| CVE-2024-54724(opens NVD record) | Critical | 9.8 | PHPYun before 7.0.2 is vulnerable to code execution through backdoor-restricted arbitrary file writing and file inclusion. | Jan 9, 2025 |
| CVE-2024-42898(opens NVD record) | Medium | 5.4 | A cross-site scripting (XSS) vulnerability in Nagios XI 2024R1.1.4 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Name parameter in the Account Settings page. | Jan 9, 2025 |
| CVE-2024-13272(opens NVD record) | Medium | 6.3 | Insufficient Granularity of Access Control vulnerability in Drupal Paragraphs table allows Content Spoofing.This issue affects Paragraphs table: from 0.0.0 before 1.23.0, from 2.0.0 before 2.0.2. | Jan 9, 2025 |
| CVE-2025-21598(opens NVD record) | High | 7.5 | An Out-of-bounds Read vulnerability in Juniper Networks Junos OS and Junos OS Evolved's routing protocol daemon (rpd) allows an unauthenticated, network-based attacker to send malformed BGP packets to a device configured with packet receive trace options enabled to crash rpd. This issue affects: Junos OS: * from 21.2R3-S8 before 21.2R3-S9, * from 21.4R3-S7 before 21.4R3-S9, * from 22.2R3-S4 before 22.2R3-S5, * from 22.3R3-S2 before 22.3R3-S4, * from 22.4R3 before 22.4R3-S5, * from 23.2R2 before 23.2R2-S2, * from 23.4R1 before 23.4R2-S1, * from 24.2R1 before 24.2R1-S1, 24.2R2. Junos OS Evolved: * from 21.4R3-S7-EVO before 21.4R3-S9-EVO, * from 22.2R3-S4-EVO before 22.2R3-S5-EVO, * from 22.3R3-S2-EVO before 22.3R3-S4-EVO, * from 22.4R3-EVO before 22.4R3-S5-EVO, * from 23.2R2-EVO before 23.2R2-S2-EVO, * from 23.4R1-EVO before 23.4R2-S1-EVO, * from 24.2R1-EVO before 24.2R1-S2-EVO, 24.2R2-EVO. This issue requires a BGP session to be established. This issue can propagate and multiply through multiple ASes until reaching vulnerable devices. This issue affects iBGP and eBGP. This issue affects IPv4 and IPv6. An indicator of compromise may be the presence of malformed update messages in a neighboring AS which is unaffected by this issue: For example, by issuing the command on the neighboring device: show log messages Reviewing for similar messages from devices within proximity to each other may indicate this malformed packet is propagating: rpd[<pid>]: Received malformed update from <IP address> (External AS <AS#>) and rpd[<pid>]: Malformed Attribute | Jan 9, 2025 |
| CVE-2025-21602(opens NVD record) | Medium | 6.5 | An Improper Handling of Exceptional Conditions vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated adjacent attacker sending a specific BGP update packet to cause rpd to crash and restart, resulting in a Denial of Service (DoS). Continuous receipt and processing of this packet will create a sustained Denial of Service (DoS) condition. This issue affects iBGP and eBGP, and both IPv4 and IPv6 are affected by this vulnerability. This issue affects Junos OS: * from 21.4 before 21.4R3-S9, * from 22.2 before 22.2R3-S5, * from 22.3 before 22.3R3-S4, * from 22.4 before 22.4R3-S5, * from 23.2 before 23.2R2-S3, * from 23.4 before 23.4R2-S3, * from 24.2 before 24.2R1-S2, 24.2R2; This issue does not affect versions prior to 21.1R1. Junos OS Evolved: * from 21.4 before 21.4R3-S9-EVO, * from 22.2 before 22.2R3-S5-EVO, * from 22.3 before 22.3R3-S4-EVO, * from 22.4 before 22.4R3-S5-EVO, * from 23.2 before 23.2R2-S3-EVO, * from 23.4 before 23.4R2-S3-EVO, * from 24.2 before 24.2R1-S2-EVO, 24.2R2-EVO. This issue does not affect versions prior to 21.1R1-EVO | Jan 9, 2025 |
| CVE-2025-21600(opens NVD record) | Medium | 6.5 | An Out-of-Bounds Read vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, logically adjacent BGP peer sending a specifically malformed BGP packet to cause rpd to crash and restart, resulting in a Denial of Service (DoS). Continued receipt and processing of this packet will create a sustained Denial of Service (DoS) condition. This issue only affects systems configured in either of two ways: * systems with BGP traceoptions enabled * systems with BGP family traffic-engineering (BGP-LS) configured and can be exploited from a directly connected and configured BGP peer. This issue affects iBGP and eBGP with any address family configured, and both IPv4 and IPv6 are affected by this vulnerability. This issue affects: Junos OS: * from 21.4 before 21.4R3-S9, * from 22.2 before 22.2R3-S5, * from 22.3 before 22.3R3-S4, * from 22.4 before 22.4R3-S5, * from 23.2 before 23.2R2-S3, * from 23.4 before 23.4R2-S3, * from 24.2 before 24.2R1-S2, 24.2R2; Junos OS Evolved: * from 21.4-EVO before 21.4R3-S9-EVO, * from 22.2-EVO before 22.2R3-S5-EVO, * from 22.3-EVO before 22.3R3-S4-EVO, * from 22.4-EVO before 22.4R3-S5-EVO, * from 23.2-EVO before 23.2R2-S3-EVO, * from 23.4-EVO before 23.4R2-S2-EVO, * from 24.2-EVO before 24.2R1-S2-EVO, 24.2R2-EVO. This issue does not affect versions of Junos OS prior to 21.3R1. This issue does not affect versions of Junos OS Evolved prior to 21.3R1-EVO. This is a similar, but different vulnerability than the issue reported as CVE-2024-39516. | Jan 9, 2025 |
| CVE-2025-21599(opens NVD record) | High | 7.5 | A Missing Release of Memory after Effective Lifetime vulnerability in the Juniper Tunnel Driver (jtd) of Juniper Networks Junos OS Evolved allows an unauthenticated network-based attacker to cause Denial of Service. Receipt of specifically malformed IPv6 packets, destined to the device, causes kernel memory to not be freed, resulting in memory exhaustion leading to a system crash and Denial of Service (DoS). Continuous receipt and processing of these packets will continue to exhaust kernel memory, creating a sustained Denial of Service (DoS) condition. This issue only affects systems configured with IPv6. This issue affects Junos OS Evolved: * from 22.4-EVO before 22.4R3-S5-EVO, * from 23.2-EVO before 23.2R2-S2-EVO, * from 23.4-EVO before 23.4R2-S2-EVO, * from 24.2-EVO before 24.2R1-S2-EVO, 24.2R2-EVO. This issue does not affect Juniper Networks Junos OS Evolved versions prior to 22.4R1-EVO. | Jan 9, 2025 |
| CVE-2025-21596(opens NVD record) | Medium | 5.5 | An Improper Handling of Exceptional Conditions vulnerability in the command-line processing of Juniper Networks Junos OS on SRX1500, SRX4100, and SRX4200 devices allows a local, low-privileged authenticated attacker executing the 'show chassis environment pem' command to cause the chassis daemon (chassisd) to crash and restart, resulting in a temporary Denial of Service (DoS). However, repeated execution of this command will eventually cause the chassisd process to fail to restart, impacting packet processing on the system. This issue affects Junos OS on SRX1500, SRX4100, SRX4200: * All versions before 21.4R3-S9, * from 22.2 before 22.2R3-S5, * from 22.3 before 22.3R3-S4, * from 22.4 before 22.4R3-S4, * from 23.2 before 23.2R2-S3, * from 23.4 before 23.4R2-S1. | Jan 9, 2025 |