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
31,739 matching · page 499/635Each CVE id links to its NVD record.
| CVE | Severity | CVSS | Summary | Published |
|---|---|---|---|---|
| CVE-2025-33100(opens NVD record) | Medium | 6.2 | IBM Concert Software 1.0.0 through 1.1.0 contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data. | Aug 18, 2025 |
| CVE-2025-33090(opens NVD record) | High | 7.5 | IBM Concert Software 1.0.0 through 1.1.0 could allow a remote attacker to cause a denial of service using a specially crafted regular expression that would cause excessive resource consumption. | Aug 18, 2025 |
| CVE-2025-27909(opens NVD record) | Medium | 5.4 | IBM Concert Software 1.0.0 through 1.1.0 uses cross-origin resource sharing (CORS) which could allow an attacker to carry out privileged actions as the domain name is not being limited to only trusted domains. | Aug 18, 2025 |
| CVE-2025-1759(opens NVD record) | Medium | 5.9 | IBM Concert Software 1.0.0 through 1.1.0 could allow a remote attacker to obtain sensitive information from allocated memory due to improper clearing of heap memory. | Aug 18, 2025 |
| CVE-2024-49827(opens NVD record) | Low | 3.7 | IBM Concert Software 1.0.0 through 1.1.0 is vulnerable to excessive data exposure, allowing attackers to access sensitive information without proper filtering. | Aug 18, 2025 |
| CVE-2023-4515(opens NVD record) | Critical | 9.1 | In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate command request size In commit 2b9b8f3b68ed ("ksmbd: validate command payload size"), except for SMB2_OPLOCK_BREAK_HE command, the request size of other commands is not checked, it's not expected. Fix it by add check for request size of other commands. | Aug 16, 2025 |
| CVE-2023-4130(opens NVD record) | High | 8.1 | In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix wrong next length validation of ea buffer in smb2_set_ea() There are multiple smb2_ea_info buffers in FILE_FULL_EA_INFORMATION request from client. ksmbd find next smb2_ea_info using ->NextEntryOffset of current smb2_ea_info. ksmbd need to validate buffer length Before accessing the next ea. ksmbd should check buffer length using buf_len, not next variable. next is the start offset of current ea that got from previous ea. | Aug 16, 2025 |
| CVE-2023-3867(opens NVD record) | Critical | 9.1 | In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out of bounds read in smb2_sess_setup ksmbd does not consider the case of that smb2 session setup is in compound request. If this is the second payload of the compound, OOB read issue occurs while processing the first payload in the smb2_sess_setup(). | Aug 16, 2025 |
| CVE-2023-3866(opens NVD record) | High | 7.5 | In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate session id and tree id in the compound request This patch validate session id and tree id in compound request. If first operation in the compound is SMB2 ECHO request, ksmbd bypass session and tree validation. So work->sess and work->tcon could be NULL. If secound request in the compound access work->sess or tcon, It cause NULL pointer dereferecing error. | Aug 16, 2025 |
| CVE-2023-3865(opens NVD record) | High | 8.1 | In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bound read in smb2_write ksmbd_smb2_check_message doesn't validate hdr->NextCommand. If ->NextCommand is bigger than Offset + Length of smb2 write, It will allow oversized smb2 write length. It will cause OOB read in smb2_write. | Aug 16, 2025 |
| CVE-2023-32249(opens NVD record) | Critical | 9.1 | In the Linux kernel, the following vulnerability has been resolved: ksmbd: not allow guest user on multichannel This patch return STATUS_NOT_SUPPORTED if binding session is guest. | Aug 16, 2025 |
| CVE-2025-38552(opens NVD record) | Critical | 9.4 | In the Linux kernel, the following vulnerability has been resolved: mptcp: plug races between subflow fail and subflow creation We have races similar to the one addressed by the previous patch between subflow failing and additional subflow creation. They are just harder to trigger. The solution is similar. Use a separate flag to track the condition 'socket state prevent any additional subflow creation' protected by the fallback lock. The socket fallback makes such flag true, and also receiving or sending an MP_FAIL option. The field 'allow_infinite_fallback' is now always touched under the relevant lock, we can drop the ONCE annotation on write. | Aug 16, 2025 |
| CVE-2025-38550(opens NVD record) | High | 7.8 | In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Delay put pmc->idev in mld_del_delrec() pmc->idev is still used in ip6_mc_clear_src(), so as mld_clear_delrec() does, the reference should be put after ip6_mc_clear_src() return. | Aug 16, 2025 |
| CVE-2025-38547(opens NVD record) | High | 7.3 | In the Linux kernel, the following vulnerability has been resolved: iio: adc: axp20x_adc: Add missing sentinel to AXP717 ADC channel maps The AXP717 ADC channel maps is missing a sentinel entry at the end. This causes a KASAN warning. Add the missing sentinel entry. | Aug 16, 2025 |
| CVE-2025-38545(opens NVD record) | High | 7.5 | In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw-nuss: Fix skb size by accounting for skb_shared_info While transitioning from netdev_alloc_ip_align() to build_skb(), memory for the "skb_shared_info" member of an "skb" was not allocated. Fix this by allocating "PAGE_SIZE" as the skb length, accounting for the packet length, headroom and tailroom, thereby including the required memory space for skb_shared_info. | Aug 16, 2025 |
| CVE-2025-38542(opens NVD record) | High | 7.8 | In the Linux kernel, the following vulnerability has been resolved: net: appletalk: Fix device refcount leak in atrtr_create() When updating an existing route entry in atrtr_create(), the old device reference was not being released before assigning the new device, leading to a device refcount leak. Fix this by calling dev_put() to release the old device reference before holding the new one. | Aug 16, 2025 |
| CVE-2025-38539(opens NVD record) | High | 7.8 | In the Linux kernel, the following vulnerability has been resolved: tracing: Add down_write(trace_event_sem) when adding trace event When a module is loaded, it adds trace events defined by the module. It may also need to modify the modules trace printk formats to replace enum names with their values. If two modules are loaded at the same time, the adding of the event to the ftrace_events list can corrupt the walking of the list in the code that is modifying the printk format strings and crash the kernel. The addition of the event should take the trace_event_sem for write while it adds the new event. Also add a lockdep_assert_held() on that semaphore in __trace_add_event_dirs() as it iterates the list. | Aug 16, 2025 |
| CVE-2025-38536(opens NVD record) | High | 7.8 | In the Linux kernel, the following vulnerability has been resolved: net: airoha: fix potential use-after-free in airoha_npu_get() np->name was being used after calling of_node_put(np), which releases the node and can lead to a use-after-free bug. Previously, of_node_put(np) was called unconditionally after of_find_device_by_node(np), which could result in a use-after-free if pdev is NULL. This patch moves of_node_put(np) after the error check to ensure the node is only released after both the error and success cases are handled appropriately, preventing potential resource issues. | Aug 16, 2025 |
| CVE-2025-38533(opens NVD record) | Critical | 9.8 | In the Linux kernel, the following vulnerability has been resolved: net: libwx: fix the using of Rx buffer DMA The wx_rx_buffer structure contained two DMA address fields: 'dma' and 'page_dma'. However, only 'page_dma' was actually initialized and used to program the Rx descriptor. But 'dma' was uninitialized and used in some paths. This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized 'dma' was used. Althrough such error has not yet occurred, it is worth fixing in the code. | Aug 16, 2025 |
| CVE-2025-38532(opens NVD record) | High | 7.8 | In the Linux kernel, the following vulnerability has been resolved: net: libwx: properly reset Rx ring descriptor When device reset is triggered by feature changes such as toggling Rx VLAN offload, wx->do_reset() is called to reinitialize Rx rings. The hardware descriptor ring may retain stale values from previous sessions. And only set the length to 0 in rx_desc[0] would result in building malformed SKBs. Fix it to ensure a clean slate after device reset. [ 549.186435] [ C16] ------------[ cut here ]------------ [ 549.186457] [ C16] kernel BUG at net/core/skbuff.c:2814! [ 549.186468] [ C16] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 549.186472] [ C16] CPU: 16 UID: 0 PID: 0 Comm: swapper/16 Kdump: loaded Not tainted 6.16.0-rc4+ #23 PREEMPT(voluntary) [ 549.186476] [ C16] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 [ 549.186478] [ C16] RIP: 0010:__pskb_pull_tail+0x3ff/0x510 [ 549.186484] [ C16] Code: 06 f0 ff 4f 34 74 7b 4d 8b 8c 24 c8 00 00 00 45 8b 84 24 c0 00 00 00 e9 c8 fd ff ff 48 c7 44 24 08 00 00 00 00 e9 5e fe ff ff <0f> 0b 31 c0 e9 23 90 5b ff 41 f7 c6 ff 0f 00 00 75 bf 49 8b 06 a8 [ 549.186487] [ C16] RSP: 0018:ffffb391c0640d70 EFLAGS: 00010282 [ 549.186490] [ C16] RAX: 00000000fffffff2 RBX: ffff8fe7e4d40200 RCX: 00000000fffffff2 [ 549.186492] [ C16] RDX: ffff8fe7c3a4bf8e RSI: 0000000000000180 RDI: ffff8fe7c3a4bf40 [ 549.186494] [ C16] RBP: ffffb391c0640da8 R08: ffff8fe7c3a4c0c0 R09: 000000000000000e [ 549.186496] [ C16] R10: ffffb391c0640d88 R11: 000000000000000e R12: ffff8fe7e4d40200 [ 549.186497] [ C16] R13: 00000000fffffff2 R14: ffff8fe7fa01a000 R15: 00000000fffffff2 [ 549.186499] [ C16] FS: 0000000000000000(0000) GS:ffff8fef5ae40000(0000) knlGS:0000000000000000 [ 549.186502] [ C16] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 549.186503] [ C16] CR2: 00007f77d81d6000 CR3: 000000051a032000 CR4: 0000000000750ef0 [ 549.186505] [ C16] PKRU: 55555554 [ 549.186507] [ C16] Call Trace: [ 549.186510] [ C16] <IRQ> [ 549.186513] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186517] [ C16] __skb_pad+0xc7/0xf0 [ 549.186523] [ C16] wx_clean_rx_irq+0x355/0x3b0 [libwx] [ 549.186533] [ C16] wx_poll+0x92/0x120 [libwx] [ 549.186540] [ C16] __napi_poll+0x28/0x190 [ 549.186544] [ C16] net_rx_action+0x301/0x3f0 [ 549.186548] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186551] [ C16] ? __raw_spin_lock_irqsave+0x1e/0x50 [ 549.186554] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186557] [ C16] ? wake_up_nohz_cpu+0x35/0x160 [ 549.186559] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186563] [ C16] handle_softirqs+0xf9/0x2c0 [ 549.186568] [ C16] __irq_exit_rcu+0xc7/0x130 [ 549.186572] [ C16] common_interrupt+0xb8/0xd0 [ 549.186576] [ C16] </IRQ> [ 549.186577] [ C16] <TASK> [ 549.186579] [ C16] asm_common_interrupt+0x22/0x40 [ 549.186582] [ C16] RIP: 0010:cpuidle_enter_state+0xc2/0x420 [ 549.186585] [ C16] Code: 00 00 e8 11 0e 5e ff e8 ac f0 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 0d ed 5c ff 45 84 ff 0f 85 40 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 84 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d [ 549.186587] [ C16] RSP: 0018:ffffb391c0277e78 EFLAGS: 00000246 [ 549.186590] [ C16] RAX: ffff8fef5ae40000 RBX: 0000000000000003 RCX: 0000000000000000 [ 549.186591] [ C16] RDX: 0000007fde0faac5 RSI: ffffffff826e53f6 RDI: ffffffff826fa9b3 [ 549.186593] [ C16] RBP: ffff8fe7c3a20800 R08: 0000000000000002 R09: 0000000000000000 [ 549.186595] [ C16] R10: 0000000000000000 R11: 000000000000ffff R12: ffffffff82ed7a40 [ 549.186596] [ C16] R13: 0000007fde0faac5 R14: 0000000000000003 R15: 0000000000000000 [ 549.186601] [ C16] ? cpuidle_enter_state+0xb3/0x420 [ 549.186605] [ C16] cpuidle_en ---truncated--- | Aug 16, 2025 |
| CVE-2025-38528(opens NVD record) | High | 7.1 | In the Linux kernel, the following vulnerability has been resolved: bpf: Reject %p% format string in bprintf-like helpers static const char fmt[] = "%p%"; bpf_trace_printk(fmt, sizeof(fmt)); The above BPF program isn't rejected and causes a kernel warning at runtime: Please remove unsupported %\x00 in format string WARNING: CPU: 1 PID: 7244 at lib/vsprintf.c:2680 format_decode+0x49c/0x5d0 This happens because bpf_bprintf_prepare skips over the second %, detected as punctuation, while processing %p. This patch fixes it by not skipping over punctuation. %\x00 is then processed in the next iteration and rejected. | Aug 16, 2025 |
| CVE-2025-38527(opens NVD record) | Critical | 9.8 | In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free in cifs_oplock_break A race condition can occur in cifs_oplock_break() leading to a use-after-free of the cinode structure when unmounting: cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAF The issue occurs when umount has already released its reference to the superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifs_oplock_break() continues to access the cinode after this point, resulting in use-after-free. Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes. | Aug 16, 2025 |
| CVE-2025-38526(opens NVD record) | High | 7.5 | In the Linux kernel, the following vulnerability has been resolved: ice: add NULL check in eswitch lag check The function ice_lag_is_switchdev_running() is being called from outside of the LAG event handler code. This results in the lag->upper_netdev being NULL sometimes. To avoid a NULL-pointer dereference, there needs to be a check before it is dereferenced. | Aug 16, 2025 |
| CVE-2025-38525(opens NVD record) | High | 7.5 | In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix irq-disabled in local_bh_enable() The rxrpc_assess_MTU_size() function calls down into the IP layer to find out the MTU size for a route. When accepting an incoming call, this is called from rxrpc_new_incoming_call() which holds interrupts disabled across the code that calls down to it. Unfortunately, the IP layer uses local_bh_enable() which, config dependent, throws a warning if IRQs are enabled: WARNING: CPU: 1 PID: 5544 at kernel/softirq.c:387 __local_bh_enable_ip+0x43/0xd0 ... RIP: 0010:__local_bh_enable_ip+0x43/0xd0 ... Call Trace: <TASK> rt_cache_route+0x7e/0xa0 rt_set_nexthop.isra.0+0x3b3/0x3f0 __mkroute_output+0x43a/0x460 ip_route_output_key_hash+0xf7/0x140 ip_route_output_flow+0x1b/0x90 rxrpc_assess_MTU_size.isra.0+0x2a0/0x590 rxrpc_new_incoming_peer+0x46/0x120 rxrpc_alloc_incoming_call+0x1b1/0x400 rxrpc_new_incoming_call+0x1da/0x5e0 rxrpc_input_packet+0x827/0x900 rxrpc_io_thread+0x403/0xb60 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30 ... hardirqs last enabled at (23): _raw_spin_unlock_irq+0x24/0x50 hardirqs last disabled at (24): _raw_read_lock_irq+0x17/0x70 softirqs last enabled at (0): copy_process+0xc61/0x2730 softirqs last disabled at (25): rt_add_uncached_list+0x3c/0x90 Fix this by moving the call to rxrpc_assess_MTU_size() out of rxrpc_init_peer() and further up the stack where it can be done without interrupts disabled. It shouldn't be a problem for rxrpc_new_incoming_call() to do it after the locks are dropped as pmtud is going to be performed by the I/O thread - and we're in the I/O thread at this point. | Aug 16, 2025 |
| CVE-2025-38524(opens NVD record) | High | 7.5 | In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix recv-recv race of completed call If a call receives an event (such as incoming data), the call gets placed on the socket's queue and a thread in recvmsg can be awakened to go and process it. Once the thread has picked up the call off of the queue, further events will cause it to be requeued, and once the socket lock is dropped (recvmsg uses call->user_mutex to allow the socket to be used in parallel), a second thread can come in and its recvmsg can pop the call off the socket queue again. In such a case, the first thread will be receiving stuff from the call and the second thread will be blocked on call->user_mutex. The first thread can, at this point, process both the event that it picked call for and the event that the second thread picked the call for and may see the call terminate - in which case the call will be "released", decoupling the call from the user call ID assigned to it (RXRPC_USER_CALL_ID in the control message). The first thread will return okay, but then the second thread will wake up holding the user_mutex and, if it sees that the call has been released by the first thread, it will BUG thusly: kernel BUG at net/rxrpc/recvmsg.c:474! Fix this by just dequeuing the call and ignoring it if it is seen to be already released. We can't tell userspace about it anyway as the user call ID has become stale. | Aug 16, 2025 |
| CVE-2025-38523(opens NVD record) | High | 7.5 | In the Linux kernel, the following vulnerability has been resolved: cifs: Fix the smbd_response slab to allow usercopy The handling of received data in the smbdirect client code involves using copy_to_iter() to copy data from the smbd_reponse struct's packet trailer to a folioq buffer provided by netfslib that encapsulates a chunk of pagecache. If, however, CONFIG_HARDENED_USERCOPY=y, this will result in the checks then performed in copy_to_iter() oopsing with something like the following: CIFS: Attempting to mount //172.31.9.1/test CIFS: VFS: RDMA transport established usercopy: Kernel memory exposure attempt detected from SLUB object 'smbd_response_0000000091e24ea1' (offset 81, size 63)! ------------[ cut here ]------------ kernel BUG at mm/usercopy.c:102! ... RIP: 0010:usercopy_abort+0x6c/0x80 ... Call Trace: <TASK> __check_heap_object+0xe3/0x120 __check_object_size+0x4dc/0x6d0 smbd_recv+0x77f/0xfe0 [cifs] cifs_readv_from_socket+0x276/0x8f0 [cifs] cifs_read_from_socket+0xcd/0x120 [cifs] cifs_demultiplex_thread+0x7e9/0x2d50 [cifs] kthread+0x396/0x830 ret_from_fork+0x2b8/0x3b0 ret_from_fork_asm+0x1a/0x30 The problem is that the smbd_response slab's packet field isn't marked as being permitted for usercopy. Fix this by passing parameters to kmem_slab_create() to indicate that copy_to_iter() is permitted from the packet region of the smbd_response slab objects, less the header space. | Aug 16, 2025 |
| CVE-2025-38514(opens NVD record) | High | 7.5 | In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix oops due to non-existence of prealloc backlog struct If an AF_RXRPC service socket is opened and bound, but calls are preallocated, then rxrpc_alloc_incoming_call() will oops because the rxrpc_backlog struct doesn't get allocated until the first preallocation is made. Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is no backlog struct. This will cause the incoming call to be aborted. | Aug 16, 2025 |
| CVE-2025-38512(opens NVD record) | High | 8.8 | In the Linux kernel, the following vulnerability has been resolved: wifi: prevent A-MSDU attacks in mesh networks This patch is a mitigation to prevent the A-MSDU spoofing vulnerability for mesh networks. The initial update to the IEEE 802.11 standard, in response to the FragAttacks, missed this case (CVE-2025-27558). It can be considered a variant of CVE-2020-24588 but for mesh networks. This patch tries to detect if a standard MSDU was turned into an A-MSDU by an adversary. This is done by parsing a received A-MSDU as a standard MSDU, calculating the length of the Mesh Control header, and seeing if the 6 bytes after this header equal the start of an rfc1042 header. If equal, this is a strong indication of an ongoing attack attempt. This defense was tested with mac80211_hwsim against a mesh network that uses an empty Mesh Address Extension field, i.e., when four addresses are used, and when using a 12-byte Mesh Address Extension field, i.e., when six addresses are used. Functionality of normal MSDUs and A-MSDUs was also tested, and confirmed working, when using both an empty and 12-byte Mesh Address Extension field. It was also tested with mac80211_hwsim that A-MSDU attacks in non-mesh networks keep being detected and prevented. Note that the vulnerability being patched, and the defense being implemented, was also discussed in the following paper and in the following IEEE 802.11 presentation: https://papers.mathyvanhoef.com/wisec2025.pdf https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx | Aug 16, 2025 |
| CVE-2025-38511(opens NVD record) | High | 8.8 | In the Linux kernel, the following vulnerability has been resolved: drm/xe/pf: Clear all LMTT pages on alloc Our LMEM buffer objects are not cleared by default on alloc and during VF provisioning we only setup LMTT PTEs for the actually provisioned LMEM range. But beyond that valid range we might leave some stale data that could either point to some other VFs allocations or even to the PF pages. Explicitly clear all new LMTT page to avoid the risk that a malicious VF would try to exploit that gap. While around add asserts to catch any undesired PTE overwrites and low-level debug traces to track LMTT PT life-cycle. (cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d) | Aug 16, 2025 |
| CVE-2025-38508(opens NVD record) | High | 7.3 | In the Linux kernel, the following vulnerability has been resolved: x86/sev: Use TSC_FACTOR for Secure TSC frequency calculation When using Secure TSC, the GUEST_TSC_FREQ MSR reports a frequency based on the nominal P0 frequency, which deviates slightly (typically ~0.2%) from the actual mean TSC frequency due to clocking parameters. Over extended VM uptime, this discrepancy accumulates, causing clock skew between the hypervisor and a SEV-SNP VM, leading to early timer interrupts as perceived by the guest. The guest kernel relies on the reported nominal frequency for TSC-based timekeeping, while the actual frequency set during SNP_LAUNCH_START may differ. This mismatch results in inaccurate time calculations, causing the guest to perceive hrtimers as firing earlier than expected. Utilize the TSC_FACTOR from the SEV firmware's secrets page (see "Secrets Page Format" in the SNP Firmware ABI Specification) to calculate the mean TSC frequency, ensuring accurate timekeeping and mitigating clock skew in SEV-SNP VMs. Use early_ioremap_encrypted() to map the secrets page as ioremap_encrypted() uses kmalloc() which is not available during early TSC initialization and causes a panic. [ bp: Drop the silly dummy var: https://lore.kernel.org/r/20250630192726.GBaGLlHl84xIopx4Pt@fat_crate.local ] | Aug 16, 2025 |
| CVE-2025-38505(opens NVD record) | High | 7.1 | In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: discard erroneous disassoc frames on STA interface When operating in concurrent STA/AP mode with host MLME enabled, the firmware incorrectly sends disassociation frames to the STA interface when clients disconnect from the AP interface. This causes kernel warnings as the STA interface processes disconnect events that don't apply to it: [ 1303.240540] WARNING: CPU: 0 PID: 513 at net/wireless/mlme.c:141 cfg80211_process_disassoc+0x78/0xec [cfg80211] [ 1303.250861] Modules linked in: 8021q garp stp mrp llc rfcomm bnep btnxpuart nls_iso8859_1 nls_cp437 onboard_us [ 1303.327651] CPU: 0 UID: 0 PID: 513 Comm: kworker/u9:2 Not tainted 6.16.0-rc1+ #3 PREEMPT [ 1303.335937] Hardware name: Toradex Verdin AM62 WB on Verdin Development Board (DT) [ 1303.343588] Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex] [ 1303.350856] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1303.357904] pc : cfg80211_process_disassoc+0x78/0xec [cfg80211] [ 1303.364065] lr : cfg80211_process_disassoc+0x70/0xec [cfg80211] [ 1303.370221] sp : ffff800083053be0 [ 1303.373590] x29: ffff800083053be0 x28: 0000000000000000 x27: 0000000000000000 [ 1303.380855] x26: 0000000000000000 x25: 00000000ffffffff x24: ffff000002c5b8ae [ 1303.388120] x23: ffff000002c5b884 x22: 0000000000000001 x21: 0000000000000008 [ 1303.395382] x20: ffff000002c5b8ae x19: ffff0000064dd408 x18: 0000000000000006 [ 1303.402646] x17: 3a36333a61623a30 x16: 32206d6f72662063 x15: ffff800080bfe048 [ 1303.409910] x14: ffff000003625300 x13: 0000000000000001 x12: 0000000000000000 [ 1303.417173] x11: 0000000000000002 x10: ffff000003958600 x9 : ffff000003625300 [ 1303.424434] x8 : ffff00003fd9ef40 x7 : ffff0000039fc280 x6 : 0000000000000002 [ 1303.431695] x5 : ffff0000038976d4 x4 : 0000000000000000 x3 : 0000000000003186 [ 1303.438956] x2 : 000000004836ba20 x1 : 0000000000006986 x0 : 00000000d00479de [ 1303.446221] Call trace: [ 1303.448722] cfg80211_process_disassoc+0x78/0xec [cfg80211] (P) [ 1303.454894] cfg80211_rx_mlme_mgmt+0x64/0xf8 [cfg80211] [ 1303.460362] mwifiex_process_mgmt_packet+0x1ec/0x460 [mwifiex] [ 1303.466380] mwifiex_process_sta_rx_packet+0x1bc/0x2a0 [mwifiex] [ 1303.472573] mwifiex_handle_rx_packet+0xb4/0x13c [mwifiex] [ 1303.478243] mwifiex_rx_work_queue+0x158/0x198 [mwifiex] [ 1303.483734] process_one_work+0x14c/0x28c [ 1303.487845] worker_thread+0x2cc/0x3d4 [ 1303.491680] kthread+0x12c/0x208 [ 1303.495014] ret_from_fork+0x10/0x20 Add validation in the STA receive path to verify that disassoc/deauth frames originate from the connected AP. Frames that fail this check are discarded early, preventing them from reaching the MLME layer and triggering WARN_ON(). This filtering logic is similar with that used in the ieee80211_rx_mgmt_disassoc() function in mac80211, which drops disassoc frames that don't match the current BSSID (!ether_addr_equal(mgmt->bssid, sdata->vif.cfg.ap_addr)), ensuring only relevant frames are processed. Tested on: - 8997 with FW 16.68.1.p197 | Aug 16, 2025 |
| CVE-2025-38502(opens NVD record) | High | 7.8 | In the Linux kernel, the following vulnerability has been resolved: bpf: Fix oob access in cgroup local storage Lonial reported that an out-of-bounds access in cgroup local storage can be crafted via tail calls. Given two programs each utilizing a cgroup local storage with a different value size, and one program doing a tail call into the other. The verifier will validate each of the indivial programs just fine. However, in the runtime context the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the BPF program as well as any cgroup local storage flavor the program uses. Helpers such as bpf_get_local_storage() pick this up from the runtime context: ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype]; if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf); For the second program which was called from the originally attached one, this means bpf_get_local_storage() will pick up the former program's map, not its own. With mismatching sizes, this can result in an unintended out-of-bounds access. To fix this issue, we need to extend bpf_map_owner with an array of storage_cookie[] to match on i) the exact maps from the original program if the second program was using bpf_get_local_storage(), or ii) allow the tail call combination if the second program was not using any of the cgroup local storage maps. | Aug 16, 2025 |
| CVE-2025-36088(opens NVD record) | Medium | 5.4 | IBM TS4500 1.11.0.0-D00, 1.11.0.1-C00, 1.11.0.2-C00, and 1.10.00-F00 web GUI is vulnerable to cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. | Aug 15, 2025 |
| CVE-2025-9019(opens NVD record) | Low | 3.1 | A vulnerability has been found in tcpreplay 4.5.1. This vulnerability affects the function mask_cidr6 of the file cidr.c of the component tcpprep. The manipulation leads to heap-based buffer overflow. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The researcher is able to reproduce this with the latest official release 4.5.1 and the current master branch. The code maintainer cannot reproduce this for 4.5.2-beta1. In his reply the maintainer explains that "[i]n that case, this is a duplicate that was fixed in 4.5.2." | Aug 15, 2025 |
| CVE-2025-51965(opens NVD record) | Medium | 6.1 | OURPHP thru 8.6.1 is vulnerable to Cross-Site Scripting (XSS) via the "Name" field of the "Complete Profile" functionality under the "My User Center" page, which can be accessed after registering through the front-end interface. | Aug 14, 2025 |
| CVE-2025-50862(opens NVD record) | Medium | 5.9 | The Lotus Cars Android app (com.lotus.carsdomestic.intl) 1.2.8 has allowBackup=true set in its manifest, allowing data exfiltration via ADB backup on rooted or debug-enabled devices. This presents a risk of user data exposure. | Aug 14, 2025 |
| CVE-2025-50861(opens NVD record) | Medium | 6.5 | The Lotus Cars Android app (com.lotus.carsdomestic.intl) 1.2.8 contains an exported component, PushDeepLinkActivity, which is accessible without authentication via ADB or malicious apps. This poses a risk of unintended access to application internals and can cause denial of service or logic abuse. | Aug 14, 2025 |
| CVE-2025-52335(opens NVD record) | Medium | 6.1 | EyouCMS 1.7.3 is vulnerale to Cross Site Scripting (XSS) in index.php, which can be exploited to obtain sensitive information. | Aug 14, 2025 |
| CVE-2025-21110(opens NVD record) | Medium | 6.7 | Dell Data Lakehouse, versions prior to 1.5.0.0, contains an Execution with Unnecessary Privileges vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to Denial of service. | Aug 14, 2025 |
| CVE-2025-20306(opens NVD record) | Medium | 4.9 | A vulnerability in the web-based management interface of Cisco Secure Firewall Management Center (FMC) Software could allow an authenticated, remote attacker with Administrator-level privileges to execute arbitrary commands on the underlying operating system. This vulnerability is due to insufficient input validation of certain HTTP request parameters that are sent to the web-based management interface. An attacker could exploit this vulnerability by authenticating to the interface and sending a crafted HTTP request to an affected device. A successful exploit could allow the attacker to execute commands as the root user on the affected device. To exploit this vulnerability, an attacker would need Administrator-level credentials. | Aug 14, 2025 |
| CVE-2025-20302(opens NVD record) | Medium | 4.3 | A vulnerability in the web-based management interface of Cisco Secure FMC Software could allow an authenticated, low-privileged, remote attacker to retrieve a generated report from a different domain. This vulnerability is due to missing authorization checks. An attacker could exploit this vulnerability by directly accessing a generated report file for a different domain that is managed on the same Cisco Secure FMC instance. A successful exploit could allow the attacker to access a previously run report for a different domain, which could allow an attacker to read activity recorded in that domain. | Aug 14, 2025 |
| CVE-2025-20301(opens NVD record) | Medium | 6.5 | A vulnerability in the web-based management interface of Cisco Secure FMC Software could allow an authenticated, low-privileged, remote attacker to access troubleshoot files for a different domain. This vulnerability is due to missing authorization checks. An attacker could exploit this vulnerability by directly accessing a troubleshoot file for a different domain that is managed on the same Cisco Secure FMC instance. A successful exploit could allow the attacker to retrieve a troubleshoot file for a different domain, which could allow the attacker to access sensitive information contained in the troubleshoot file. | Aug 14, 2025 |
| CVE-2025-20265(opens NVD record) | Critical | 10.0 | A vulnerability in the RADIUS subsystem implementation of Cisco Secure Firewall Management Center (FMC) Software could allow an unauthenticated, remote attacker to inject arbitrary shell commands that are executed by the device. This vulnerability is due to a lack of proper handling of user input during the authentication phase. An attacker could exploit this vulnerability by sending crafted input when entering credentials that will be authenticated at the configured RADIUS server. A successful exploit could allow the attacker to execute commands at a high privilege level. Note: For this vulnerability to be exploited, Cisco Secure FMC Software must be configured for RADIUS authentication for the web-based management interface, SSH management, or both. | Aug 14, 2025 |
| CVE-2025-20235(opens NVD record) | Medium | 6.1 | A vulnerability in the web-based management interface of Cisco Secure Firewall Management Center (FMC) Software could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the interface. This vulnerability is due to insufficient validation of user-supplied input by the web-based management interface. An attacker could exploit this vulnerability by inserting crafted input into various data fields in an affected interface. A successful exploit could allow the attacker to execute arbitrary script code in the context of the interface or access sensitive, browser-based information. | Aug 14, 2025 |
| CVE-2025-20218(opens NVD record) | Medium | 4.9 | A vulnerability in the web-based management interface of Cisco Secure Firewall Management Center (FMC) Software could allow an authenticated, remote attacker to retrieve sensitive information from an affected device. This vulnerability is due to insufficient input validation. An attacker could exploit this vulnerability by sending a crafted request to the web-based management interface of an affected device. A successful exploit could allow the attacker to retrieve sensitive information from the affected device. To exploit this vulnerability, the attacker must have valid administrative credentials. | Aug 14, 2025 |
| CVE-2025-20148(opens NVD record) | High | 8.5 | A vulnerability in the web-based management interface of Cisco Secure Firewall Management Center (FMC) Software could allow an authenticated, remote attacker to inject arbitrary HTML content into a device-generated document. This vulnerability is due to improper validation of user-supplied data. An attacker could exploit this vulnerability by submitting malicious content to an affected device and using the device to generate a document that contains sensitive information. A successful exploit could allow the attacker to alter the standard layout of the device-generated documents, read arbitrary files from the underlying operating system, and conduct server-side request forgery (SSRF) attacks. To exploit this vulnerability, the attacker must have valid credentials for a user account with at least the role of Security Analyst (Read Only). | Aug 14, 2025 |
| CVE-2025-20127(opens NVD record) | High | 7.7 | A vulnerability in the TLS 1.3 implementation for a specific cipher for Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Cisco Secure Firewall Threat Defense (FTD) Software for Cisco Firepower 3100 and 4200 Series devices could allow an authenticated, remote attacker to consume resources that are associated with incoming TLS 1.3 connections, which eventually could cause the device to stop accepting any new SSL/TLS or VPN requests. This vulnerability is due to the implementation of the TLS 1.3 Cipher TLS_CHACHA20_POLY1305_SHA256. An attacker could exploit this vulnerability by sending a large number of TLS 1.3 connections with the specific TLS 1.3 Cipher TLS_CHACHA20_POLY1305_SHA256. A successful exploit could allow the attacker to cause a denial of service (DoS) condition where no new incoming encrypted connections are accepted. The device must be reloaded to clear this condition. Note: These incoming TLS 1.3 connections include both data traffic and user-management traffic. After the device is in the vulnerable state, no new encrypted connections can be accepted. | Aug 14, 2025 |
| CVE-2025-36047(opens NVD record) | Medium | 5.3 | IBM WebSphere Application Server Liberty 18.0.0.2 through 25.0.0.8 is vulnerable to a denial of service, caused by sending a specially-crafted request. A remote attacker could exploit this vulnerability to cause the server to consume memory resources. | Aug 14, 2025 |
| CVE-2025-33142(opens NVD record) | Medium | 5.3 | IBM WebSphere Application Server 8.5 and 9.0 could provide weaker than expected security for TLS connections. | Aug 14, 2025 |
| CVE-2025-38745(opens NVD record) | Medium | 4.8 | Dell OpenManage Enterprise, versions 3.10, 4.0, 4.1, and 4.2, contains an Insertion of Sensitive Information into Log File vulnerability in the Backup and Restore. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to Information exposure. | Aug 14, 2025 |