Total
339292 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-37786 | 1 Linux | 1 Linux Kernel | 2026-03-17 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: net: dsa: free routing table on probe failure If complete = true in dsa_tree_setup(), it means that we are the last switch of the tree which is successfully probing, and we should be setting up all switches from our probe path. After "complete" becomes true, dsa_tree_setup_cpu_ports() or any subsequent function may fail. If that happens, the entire tree setup is in limbo: the first N-1 switches have successfully finished probing (doing nothing but having allocated persistent memory in the tree's dst->ports, and maybe dst->rtable), and switch N failed to probe, ending the tree setup process before anything is tangible from the user's PoV. If switch N fails to probe, its memory (ports) will be freed and removed from dst->ports. However, the dst->rtable elements pointing to its ports, as created by dsa_link_touch(), will remain there, and will lead to use-after-free if dereferenced. If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirely possible because that is where ds->ops->setup() is, we get a kasan report like this: ================================================================== BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568 Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42 Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 The simplest way to fix the bug is to delete the routing table in its entirety. dsa_tree_setup_routing_table() has no problem in regenerating it even if we deleted links between ports other than those of switch N, because dsa_link_touch() first checks whether the port pair already exists in dst->rtable, allocating if not. The deletion of the routing table in its entirety already exists in dsa_tree_teardown(), so refactor that into a function that can also be called from the tree setup error path. In my analysis of the commit to blame, it is the one which added dsa_link elements to dst->rtable. Prior to that, each switch had its own ds->rtable which is freed when the switch fails to probe. But the tree is potentially persistent memory. | |||||
| CVE-2025-37791 | 1 Linux | 1 Linux Kernel | 2026-03-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ethtool: cmis_cdb: use correct rpl size in ethtool_cmis_module_poll() rpl is passed as a pointer to ethtool_cmis_module_poll(), so the correct size of rpl is sizeof(*rpl) which should be just 1 byte. Using the pointer size instead can cause stack corruption: Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ethtool_cmis_wait_for_cond+0xf4/0x100 CPU: 72 UID: 0 PID: 4440 Comm: kworker/72:2 Kdump: loaded Tainted: G OE 6.11.0 #24 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. PowerEdge R760/04GWWM, BIOS 1.6.6 09/20/2023 Workqueue: events module_flash_fw_work Call Trace: <TASK> panic+0x339/0x360 ? ethtool_cmis_wait_for_cond+0xf4/0x100 ? __pfx_status_success+0x10/0x10 ? __pfx_status_fail+0x10/0x10 __stack_chk_fail+0x10/0x10 ethtool_cmis_wait_for_cond+0xf4/0x100 ethtool_cmis_cdb_execute_cmd+0x1fc/0x330 ? __pfx_status_fail+0x10/0x10 cmis_cdb_module_features_get+0x6d/0xd0 ethtool_cmis_cdb_init+0x8a/0xd0 ethtool_cmis_fw_update+0x46/0x1d0 module_flash_fw_work+0x17/0xa0 process_one_work+0x179/0x390 worker_thread+0x239/0x340 ? __pfx_worker_thread+0x10/0x10 kthread+0xcc/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> | |||||
| CVE-2026-29774 | 1 Freerdp | 1 Freerdp | 2026-03-17 | N/A | 5.3 MEDIUM |
| FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.24.0, a client-side heap buffer overflow occurs in the FreeRDP client's AVC420/AVC444 YUV-to-RGB conversion path due to missing horizontal bounds validation of H.264 metablock regionRects coordinates. In yuv.c, the clamp() function (line 347) only validates top/bottom against the surface/YUV height, but never checks left/right against the surface width. When avc420_yuv_to_rgb (line 67) computes destination and source pointers using rect->left, it performs unchecked pointer arithmetic that can reach far beyond the allocated surface buffer. A malicious server sends a WIRE_TO_SURFACE_PDU_1 with AVC420 codec containing a regionRects entry where left greatly exceeds the surface width (e.g., left=60000 on a 128px surface). The H.264 bitstream decodes successfully, then yuv420_process_work_callback calls avc420_yuv_to_rgb which computes pDstPoint = pDstData + rect->top * nDstStep + rect->left * 4, writing 16-byte SSE vectors 1888+ bytes past the allocated heap region. This vulnerability is fixed in 3.24.0. | |||||
| CVE-2025-37778 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-03-17 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix dangling pointer in krb_authenticate krb_authenticate frees sess->user and does not set the pointer to NULL. It calls ksmbd_krb5_authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2_sess_setup, which calls krb_authenticate, will be accessing free'd memory when it later uses sess->user. | |||||
| CVE-2026-29775 | 1 Freerdp | 1 Freerdp | 2026-03-17 | N/A | 5.3 MEDIUM |
| FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.24.0, a client-side heap out-of-bounds read/write occurs in FreeRDP's bitmap cache subsystem due to an off-by-one boundary check in bitmap_cache_put. A malicious server can send a CACHE_BITMAP_ORDER (Rev1) with cacheId equal to maxCells, bypassing the guard and accessing cells[] one element past the allocated array. This vulnerability is fixed in 3.24.0. | |||||
| CVE-2024-43105 | 1 Mattermost | 1 Channel Export | 2026-03-17 | N/A | 4.3 MEDIUM |
| Mattermost Plugin Channel Export versions <=1.0.0 fail to restrict concurrent runs of the /export command which allows a user to consume excessive resource by running the /export command multiple times at once. | |||||
| CVE-2025-23155 | 1 Linux | 1 Linux Kernel | 2026-03-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix accessing freed irq affinity_hint In stmmac_request_irq_multi_msi(), a pointer to the stack variable cpu_mask is passed to irq_set_affinity_hint(). This value is stored in irq_desc->affinity_hint, but once stmmac_request_irq_multi_msi() returns, the pointer becomes dangling. The affinity_hint is exposed via procfs with S_IRUGO permissions, allowing any unprivileged process to read it. Accessing this stale pointer can lead to: - a kernel oops or panic if the referenced memory has been released and unmapped, or - leakage of kernel data into userspace if the memory is re-used for other purposes. All platforms that use stmmac with PCI MSI (Intel, Loongson, etc) are affected. | |||||
| CVE-2025-37775 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-03-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix the warning from __kernel_write_iter [ 2110.972290] ------------[ cut here ]------------ [ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280 This patch doesn't allow writing to directory. | |||||
| CVE-2025-38104 | 1 Linux | 1 Linux Kernel | 2026-03-17 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Replace Mutex with Spinlock for RLCG register access to avoid Priority Inversion in SRIOV RLCG Register Access is a way for virtual functions to safely access GPU registers in a virtualized environment., including TLB flushes and register reads. When multiple threads or VFs try to access the same registers simultaneously, it can lead to race conditions. By using the RLCG interface, the driver can serialize access to the registers. This means that only one thread can access the registers at a time, preventing conflicts and ensuring that operations are performed correctly. Additionally, when a low-priority task holds a mutex that a high-priority task needs, ie., If a thread holding a spinlock tries to acquire a mutex, it can lead to priority inversion. register access in amdgpu_virt_rlcg_reg_rw especially in a fast code path is critical. The call stack shows that the function amdgpu_virt_rlcg_reg_rw is being called, which attempts to acquire the mutex. This function is invoked from amdgpu_sriov_wreg, which in turn is called from gmc_v11_0_flush_gpu_tlb. The [ BUG: Invalid wait context ] indicates that a thread is trying to acquire a mutex while it is in a context that does not allow it to sleep (like holding a spinlock). Fixes the below: [ 253.013423] ============================= [ 253.013434] [ BUG: Invalid wait context ] [ 253.013446] 6.12.0-amdstaging-drm-next-lol-050225 #14 Tainted: G U OE [ 253.013464] ----------------------------- [ 253.013475] kworker/0:1/10 is trying to lock: [ 253.013487] ffff9f30542e3cf8 (&adev->virt.rlcg_reg_lock){+.+.}-{3:3}, at: amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.013815] other info that might help us debug this: [ 253.013827] context-{4:4} [ 253.013835] 3 locks held by kworker/0:1/10: [ 253.013847] #0: ffff9f3040050f58 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x3f5/0x680 [ 253.013877] #1: ffffb789c008be40 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: process_one_work+0x1d6/0x680 [ 253.013905] #2: ffff9f3054281838 (&adev->gmc.invalidate_lock){+.+.}-{2:2}, at: gmc_v11_0_flush_gpu_tlb+0x198/0x4f0 [amdgpu] [ 253.014154] stack backtrace: [ 253.014164] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G U OE 6.12.0-amdstaging-drm-next-lol-050225 #14 [ 253.014189] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 253.014203] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/18/2024 [ 253.014224] Workqueue: events work_for_cpu_fn [ 253.014241] Call Trace: [ 253.014250] <TASK> [ 253.014260] dump_stack_lvl+0x9b/0xf0 [ 253.014275] dump_stack+0x10/0x20 [ 253.014287] __lock_acquire+0xa47/0x2810 [ 253.014303] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014321] lock_acquire+0xd1/0x300 [ 253.014333] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.014562] ? __lock_acquire+0xa6b/0x2810 [ 253.014578] __mutex_lock+0x85/0xe20 [ 253.014591] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.014782] ? sched_clock_noinstr+0x9/0x10 [ 253.014795] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014808] ? local_clock_noinstr+0xe/0xc0 [ 253.014822] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015012] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.015029] mutex_lock_nested+0x1b/0x30 [ 253.015044] ? mutex_lock_nested+0x1b/0x30 [ 253.015057] amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015249] amdgpu_sriov_wreg+0xc5/0xd0 [amdgpu] [ 253.015435] gmc_v11_0_flush_gpu_tlb+0x44b/0x4f0 [amdgpu] [ 253.015667] gfx_v11_0_hw_init+0x499/0x29c0 [amdgpu] [ 253.015901] ? __pfx_smu_v13_0_update_pcie_parameters+0x10/0x10 [amdgpu] [ 253.016159] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.016173] ? smu_hw_init+0x18d/0x300 [amdgpu] [ 253.016403] amdgpu_device_init+0x29ad/0x36a0 [amdgpu] [ 253.016614] amdgpu_driver_load_kms+0x1a/0xc0 [amdgpu] [ 253.0170 ---truncated--- | |||||
| CVE-2026-29776 | 1 Freerdp | 1 Freerdp | 2026-03-17 | N/A | 3.1 LOW |
| FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.24.0, Integer Underflow in update_read_cache_bitmap_order Function of FreeRDP's Core Library This vulnerability is fixed in 3.24.0. | |||||
| CVE-2025-38575 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-03-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: use aead_request_free to match aead_request_alloc Use aead_request_free() instead of kfree() to properly free memory allocated by aead_request_alloc(). This ensures sensitive crypto data is zeroed before being freed. | |||||
| CVE-2026-31806 | 1 Freerdp | 1 Freerdp | 2026-03-17 | N/A | 9.8 CRITICAL |
| FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.24.0, the gdi_surface_bits() function processes SURFACE_BITS_COMMAND messages sent by the RDP server. When the command is handled using NSCodec, the bmp.width and bmp.height values provided by the server are not properly validated against the actual desktop dimensions. A malicious RDP server can supply crafted bmp.width and bmp.height values that exceed the expected surface size. Because these values are used during bitmap decoding and memory operations without proper bounds checking, this can lead to a heap buffer overflow. Since the attacker can also control the associated pixel data transmitted by the server, the overflow may be exploitable to overwrite adjacent heap memory. This vulnerability is fixed in 3.24.0. | |||||
| CVE-2026-31883 | 1 Freerdp | 1 Freerdp | 2026-03-17 | N/A | 6.5 MEDIUM |
| FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.24.0, a size_t underflow in the IMA-ADPCM and MS-ADPCM audio decoders leads to heap-buffer-overflow write via the RDPSND audio channel. In libfreerdp/codec/dsp.c, the IMA-ADPCM and MS-ADPCM decoders subtract block header sizes from a size_t variable without checking for underflow. When nBlockAlign (received from the server) is set such that size % block_size == 0 triggers the header parsing at a point where size is smaller than the header (4 or 8 bytes), the subtraction wraps size to ~SIZE_MAX. The while (size > 0) loop then continues for an astronomical number of iterations. This vulnerability is fixed in 3.24.0. | |||||
| CVE-2025-22119 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-03-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: init wiphy_work before allocating rfkill fails syzbort reported a uninitialize wiphy_work_lock in cfg80211_dev_free. [1] After rfkill allocation fails, the wiphy release process will be performed, which will cause cfg80211_dev_free to access the uninitialized wiphy_work related data. Move the initialization of wiphy_work to before rfkill initialization to avoid this issue. [1] INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 UID: 0 PID: 5935 Comm: syz-executor550 Not tainted 6.14.0-rc6-syzkaller-00103-g4003c9e78778 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 assign_lock_key kernel/locking/lockdep.c:983 [inline] register_lock_class+0xc39/0x1240 kernel/locking/lockdep.c:1297 __lock_acquire+0x135/0x3c40 kernel/locking/lockdep.c:5103 lock_acquire.part.0+0x11b/0x380 kernel/locking/lockdep.c:5851 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3a/0x60 kernel/locking/spinlock.c:162 cfg80211_dev_free+0x30/0x3d0 net/wireless/core.c:1196 device_release+0xa1/0x240 drivers/base/core.c:2568 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1e4/0x5a0 lib/kobject.c:737 put_device+0x1f/0x30 drivers/base/core.c:3774 wiphy_free net/wireless/core.c:1224 [inline] wiphy_new_nm+0x1c1f/0x2160 net/wireless/core.c:562 ieee80211_alloc_hw_nm+0x1b7a/0x2260 net/mac80211/main.c:835 mac80211_hwsim_new_radio+0x1d6/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5185 hwsim_new_radio_nl+0xb42/0x12b0 drivers/net/wireless/virtual/mac80211_hwsim.c:6242 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2533 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1882 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg net/socket.c:733 [inline] ____sys_sendmsg+0xaaf/0xc90 net/socket.c:2573 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2627 __sys_sendmsg+0x16e/0x220 net/socket.c:2659 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 Close: https://syzkaller.appspot.com/bug?extid=aaf0488c83d1d5f4f029 | |||||
| CVE-2026-31884 | 1 Freerdp | 1 Freerdp | 2026-03-17 | N/A | 6.5 MEDIUM |
| FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.24.0, division by zero in MS-ADPCM and IMA-ADPCM decoders when nBlockAlign is 0, leading to a crash. In libfreerdp/codec/dsp.c, both ADPCM decoders use size % block_size where block_size = context->common.format.nBlockAlign. The nBlockAlign value comes from the Server Audio Formats PDU on the RDPSND channel. The value 0 is not validated anywhere before reaching the decoder. When nBlockAlign = 0, the modulo operation causes a SIGFPE (floating point exception) crash. This vulnerability is fixed in 3.24.0. | |||||
| CVE-2025-15540 | 1 Raytha | 1 Raytha | 2026-03-17 | N/A | 8.8 HIGH |
| "Functions" module in Raytha CMS allows privileged users to write custom code to add functionality to application. Due to a lack of sandboxing or access restrictions, JavaScript code executed through Raytha’s “functions” feature can instantiate .NET components and perform arbitrary operations within the application’s hosting environment. This issue was fixed in version 1.4.6. | |||||
| CVE-2026-3060 | 1 Lmsys | 1 Sglang | 2026-03-17 | N/A | 9.8 CRITICAL |
| SGLang' encoder parallel disaggregation system is vulnerable to unauthenticated remote code execution through the disaggregation module, which deserializes untrusted data using pickle.loads() without authentication. | |||||
| CVE-2026-4177 | 2026-03-17 | N/A | 9.1 CRITICAL | ||
| YAML::Syck versions through 1.36 for Perl has several potential security vulnerabilities including a high-severity heap buffer overflow in the YAML emitter. The heap overflow occurs when class names exceed the initial 512-byte allocation. The base64 decoder could read past the buffer end on trailing newlines. strtok mutated n->type_id in place, corrupting shared node data. A memory leak occurred in syck_hdlr_add_anchor when a node already had an anchor. The incoming anchor string 'a' was leaked on early return. | |||||
| CVE-2026-4270 | 2026-03-17 | N/A | 5.5 MEDIUM | ||
| Improper Protection of Alternate Path exists in the no-access and workdir feature of the AWS API MCP Server versions >= 0.2.14 and < 1.3.9 on all platforms may allow the bypass of intended file access restriction and expose arbitrary local file contents in the MCP client application context. To remediate this issue, users should upgrade to version 1.3.9. | |||||
| CVE-2026-23862 | 2026-03-17 | N/A | 7.8 HIGH | ||
| Dell ThinOS 10 versions prior to ThinOS 2602_10.0573, contain an Improper Neutralization of Special Elements used in a Command ('Command Injection') vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of Privileges. | |||||