Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n<br /> <br /> When CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0<br /> (success) without actually creating a socket. Callers such as<br /> fou_create() then proceed to dereference the uninitialized socket<br /> pointer, resulting in a NULL pointer dereference.<br /> <br /> The captured NULL deref crash:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764)<br /> [...]<br /> Call Trace:<br /> <br /> genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114)<br /> genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209)<br /> [...]<br /> netlink_rcv_skb (net/netlink/af_netlink.c:2550)<br /> genl_rcv (net/netlink/genetlink.c:1219)<br /> netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)<br /> netlink_sendmsg (net/netlink/af_netlink.c:1894)<br /> __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1))<br /> __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1))<br /> __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1))<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))<br /> entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130)<br /> <br /> This patch makes udp_sock_create6 return -EPFNOSUPPORT instead, so<br /> callers correctly take their error paths. There is only one caller of<br /> the vulnerable function and only privileged users can trigger it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/sva: Fix crash in iommu_sva_unbind_device()<br /> <br /> domain-&gt;mm-&gt;iommu_mm can be freed by iommu_domain_free():<br /> iommu_domain_free()<br /> mmdrop()<br /> __mmdrop()<br /> mm_pasid_drop()<br /> After iommu_domain_free() returns, accessing domain-&gt;mm-&gt;iommu_mm may<br /> dereference a freed mm structure, leading to a crash.<br /> <br /> Fix this by moving the code that accesses domain-&gt;mm-&gt;iommu_mm to before<br /> the call to iommu_domain_free().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: Don&amp;#39;t overwrite KMS surface dirty tracker<br /> <br /> We were overwriting the surface&amp;#39;s dirty tracker here causing a memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: amlogic-spisg: Fix memory leak in aml_spisg_probe()<br /> <br /> In aml_spisg_probe(), ctlr is allocated by<br /> spi_alloc_target()/spi_alloc_host(), but fails to call<br /> spi_controller_put() in several error paths. This leads<br /> to a memory leak whenever the driver fails to probe after<br /> the initial allocation.<br /> <br /> Convert to use devm_spi_alloc_host()/devm_spi_alloc_target()<br /> to fix the memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mshv: Fix use-after-free in mshv_map_user_memory error path<br /> <br /> In the error path of mshv_map_user_memory(), calling vfree() directly on<br /> the region leaves the MMU notifier registered. When userspace later unmaps<br /> the memory, the notifier fires and accesses the freed region, causing a<br /> use-after-free and potential kernel panic.<br /> <br /> Replace vfree() with mshv_partition_put() to properly unregister<br /> the MMU notifier before freeing the region.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm_mpam: Fix null pointer dereference when restoring bandwidth counters<br /> <br /> When an MSC supporting memory bandwidth monitoring is brought offline and<br /> then online, mpam_restore_mbwu_state() calls __ris_msmon_read() via ipi to<br /> restore the configuration of the bandwidth counters. It doesn&amp;#39;t care about<br /> the value read, mbwu_arg.val, and doesn&amp;#39;t set it leading to a null pointer<br /> dereference when __ris_msmon_read() adds to it. This results in a kernel<br /> oops with a call trace such as:<br /> <br /> Call trace:<br /> __ris_msmon_read+0x19c/0x64c (P)<br /> mpam_restore_mbwu_state+0xa0/0xe8<br /> smp_call_on_cpu_callback+0x1c/0x38<br /> process_one_work+0x154/0x4b4<br /> worker_thread+0x188/0x310<br /> kthread+0x11c/0x130<br /> ret_from_fork+0x10/0x20<br /> <br /> Provide a local variable for val to avoid __ris_msmon_read() dereferencing<br /> a null pointer when adding to val.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: rawnand: serialize lock/unlock against other NAND operations<br /> <br /> nand_lock() and nand_unlock() call into chip-&gt;ops.lock_area/unlock_area<br /> without holding the NAND device lock. On controllers that implement<br /> SET_FEATURES via multiple low-level PIO commands, these can race with<br /> concurrent UBI/UBIFS background erase/write operations that hold the<br /> device lock, resulting in cmd_pending conflicts on the NAND controller.<br /> <br /> Add nand_get_device()/nand_release_device() around the lock/unlock<br /> operations to serialize them against all other NAND controller access.

FastMCP is the standard framework for building MCP applications. Prior to version 3.2.0, server names containing shell metacharacters (e.g., &amp;) can cause command injection on Windows when passed to fastmcp install claude-code or fastmcp install gemini-cli. These install paths use subprocess.run() with a list argument, but on Windows the target CLIs often resolve to .cmd wrappers that are executed through cmd.exe, which interprets metacharacters in the flattened command string. This issue has been patched in version 3.2.0.

Juju is an open source application orchestration engine that enables any application operation on any infrastructure at any scale through special operators called ‘charms’. From versions 2.9 to before 2.9.56 and 3.6 to before 3.6.19, it is possible that a compromised workload machine under a Juju controller can read any log file for any entity in any model at any level. This issue has been patched in versions 2.9.56 and 3.6.19.

Juju is an open source application orchestration engine that enables any application operation on any infrastructure at any scale through special operators called ‘charms’. From versions 2.9 to before 2.9.56 and 3.6 to before 3.6.19, any authenticated user, machine or controller under a Juju controller can modify the resources of an application within the entire controller. This issue has been patched in versions 2.9.56 and 3.6.19.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in durable v2 replay of active file handles<br /> <br /> parse_durable_handle_context() unconditionally assigns dh_info-&gt;fp-&gt;conn<br /> to the current connection when handling a DURABLE_REQ_V2 context with<br /> SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by<br /> fp-&gt;conn, so it returns file handles that are already actively connected.<br /> The unconditional overwrite replaces fp-&gt;conn, and when the overwriting<br /> connection is subsequently freed, __ksmbd_close_fd() dereferences the<br /> stale fp-&gt;conn via spin_lock(&amp;fp-&gt;conn-&gt;llist_lock), causing a<br /> use-after-free.<br /> <br /> KASAN report:<br /> <br /> [ 7.349357] ==================================================================<br /> [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0<br /> [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108<br /> [ 7.350010]<br /> [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY<br /> [ 7.350068] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work<br /> [ 7.350083] Call Trace:<br /> [ 7.350087] <br /> [ 7.350087] dump_stack_lvl+0x64/0x80<br /> [ 7.350094] print_report+0xce/0x660<br /> [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 7.350101] ? __pfx___mod_timer+0x10/0x10<br /> [ 7.350106] ? _raw_spin_lock+0x75/0xe0<br /> [ 7.350108] kasan_report+0xce/0x100<br /> [ 7.350109] ? _raw_spin_lock+0x75/0xe0<br /> [ 7.350114] kasan_check_range+0x105/0x1b0<br /> [ 7.350116] _raw_spin_lock+0x75/0xe0<br /> [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10<br /> [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780<br /> [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0<br /> [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0<br /> [ 7.350131] ksmbd_close_fd+0x135/0x1b0<br /> [ 7.350133] smb2_close+0xb19/0x15b0<br /> [ 7.350142] ? __pfx_smb2_close+0x10/0x10<br /> [ 7.350143] ? xas_load+0x18/0x270<br /> [ 7.350146] ? _raw_spin_lock+0x84/0xe0<br /> [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10<br /> [ 7.350150] ? _raw_spin_unlock+0xe/0x30<br /> [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0<br /> [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0<br /> [ 7.350154] handle_ksmbd_work+0x40f/0x1080<br /> [ 7.350156] process_one_work+0x5fa/0xef0<br /> [ 7.350162] ? assign_work+0x122/0x3e0<br /> [ 7.350163] worker_thread+0x54b/0xf70<br /> [ 7.350165] ? __pfx_worker_thread+0x10/0x10<br /> [ 7.350166] kthread+0x346/0x470<br /> [ 7.350170] ? recalc_sigpending+0x19b/0x230<br /> [ 7.350176] ? __pfx_kthread+0x10/0x10<br /> [ 7.350178] ret_from_fork+0x4fb/0x6c0<br /> [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10<br /> [ 7.350185] ? __switch_to+0x36c/0xbe0<br /> [ 7.350188] ? __pfx_kthread+0x10/0x10<br /> [ 7.350190] ret_from_fork_asm+0x1a/0x30<br /> [ 7.350197] <br /> [ 7.350197]<br /> [ 7.355160] Allocated by task 123:<br /> [ 7.355261] kasan_save_stack+0x33/0x60<br /> [ 7.355373] kasan_save_track+0x14/0x30<br /> [ 7.355484] __kasan_kmalloc+0x8f/0xa0<br /> [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0<br /> [ 7.355711] ksmbd_kthread_fn+0x243/0xd70<br /> [ 7.355839] kthread+0x346/0x470<br /> [ 7.355942] ret_from_fork+0x4fb/0x6c0<br /> [ 7.356051] ret_from_fork_asm+0x1a/0x30<br /> [ 7.356164]<br /> [ 7.356214] Freed by task 134:<br /> [ 7.356305] kasan_save_stack+0x33/0x60<br /> [ 7.356416] kasan_save_track+0x14/0x30<br /> [ 7.356527] kasan_save_free_info+0x3b/0x60<br /> [ 7.356646] __kasan_slab_free+0x43/0x70<br /> [ 7.356761] kfree+0x1ca/0x430<br /> [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0<br /> [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40<br /> [ 7.357138] kthread+0x346/0x470<br /> [ 7.357240] ret_from_fork+0x4fb/0x6c0<br /> [ 7.357350] ret_from_fork_asm+0x1a/0x30<br /> [ 7.357463]<br /> [ 7.357513] The buggy address belongs to the object at ffff8881056ac000<br /> [ 7.357513] which belongs to the cache kmalloc-1k of size 1024<br /> [ 7.357857] The buggy address is located 396 bytes inside of<br /> [ 7.357857] freed 1024-byte region <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free of share_conf in compound request<br /> <br /> smb2_get_ksmbd_tcon() reuses work-&gt;tcon in compound requests without<br /> validating tcon-&gt;t_state. ksmbd_tree_conn_lookup() checks t_state ==<br /> TREE_CONNECTED on the initial lookup path, but the compound reuse path<br /> bypasses this check entirely.<br /> <br /> If a prior command in the compound (SMB2_TREE_DISCONNECT) sets t_state<br /> to TREE_DISCONNECTED and frees share_conf via ksmbd_share_config_put(),<br /> subsequent commands dereference the freed share_conf through<br /> work-&gt;tcon-&gt;share_conf.<br /> <br /> KASAN report:<br /> <br /> [ 4.144653] ==================================================================<br /> [ 4.145059] BUG: KASAN: slab-use-after-free in smb2_write+0xc74/0xe70<br /> [ 4.145415] Read of size 4 at addr ffff88810430c194 by task kworker/1:1/44<br /> [ 4.145772]<br /> [ 4.145867] CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted 7.0.0-rc3+ #60 PREEMPTLAZY<br /> [ 4.145871] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 4.145875] Workqueue: ksmbd-io handle_ksmbd_work<br /> [ 4.145888] Call Trace:<br /> [ 4.145892] <br /> [ 4.145894] dump_stack_lvl+0x64/0x80<br /> [ 4.145910] print_report+0xce/0x660<br /> [ 4.145919] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 4.145928] ? smb2_write+0xc74/0xe70<br /> [ 4.145931] kasan_report+0xce/0x100<br /> [ 4.145934] ? smb2_write+0xc74/0xe70<br /> [ 4.145937] smb2_write+0xc74/0xe70<br /> [ 4.145939] ? __pfx_smb2_write+0x10/0x10<br /> [ 4.145942] ? _raw_spin_unlock+0xe/0x30<br /> [ 4.145945] ? ksmbd_smb2_check_message+0xeb2/0x24c0<br /> [ 4.145948] ? smb2_tree_disconnect+0x31c/0x480<br /> [ 4.145951] handle_ksmbd_work+0x40f/0x1080<br /> [ 4.145953] process_one_work+0x5fa/0xef0<br /> [ 4.145962] ? assign_work+0x122/0x3e0<br /> [ 4.145964] worker_thread+0x54b/0xf70<br /> [ 4.145967] ? __pfx_worker_thread+0x10/0x10<br /> [ 4.145970] kthread+0x346/0x470<br /> [ 4.145976] ? recalc_sigpending+0x19b/0x230<br /> [ 4.145980] ? __pfx_kthread+0x10/0x10<br /> [ 4.145984] ret_from_fork+0x4fb/0x6c0<br /> [ 4.145992] ? __pfx_ret_from_fork+0x10/0x10<br /> [ 4.145995] ? __switch_to+0x36c/0xbe0<br /> [ 4.145999] ? __pfx_kthread+0x10/0x10<br /> [ 4.146003] ret_from_fork_asm+0x1a/0x30<br /> [ 4.146013] <br /> [ 4.146014]<br /> [ 4.149858] Allocated by task 44:<br /> [ 4.149953] kasan_save_stack+0x33/0x60<br /> [ 4.150061] kasan_save_track+0x14/0x30<br /> [ 4.150169] __kasan_kmalloc+0x8f/0xa0<br /> [ 4.150274] ksmbd_share_config_get+0x1dd/0xdd0<br /> [ 4.150401] ksmbd_tree_conn_connect+0x7e/0x600<br /> [ 4.150529] smb2_tree_connect+0x2e6/0x1000<br /> [ 4.150645] handle_ksmbd_work+0x40f/0x1080<br /> [ 4.150761] process_one_work+0x5fa/0xef0<br /> [ 4.150873] worker_thread+0x54b/0xf70<br /> [ 4.150978] kthread+0x346/0x470<br /> [ 4.151071] ret_from_fork+0x4fb/0x6c0<br /> [ 4.151176] ret_from_fork_asm+0x1a/0x30<br /> [ 4.151286]<br /> [ 4.151332] Freed by task 44:<br /> [ 4.151418] kasan_save_stack+0x33/0x60<br /> [ 4.151526] kasan_save_track+0x14/0x30<br /> [ 4.151634] kasan_save_free_info+0x3b/0x60<br /> [ 4.151751] __kasan_slab_free+0x43/0x70<br /> [ 4.151861] kfree+0x1ca/0x430<br /> [ 4.151952] __ksmbd_tree_conn_disconnect+0xc8/0x190<br /> [ 4.152088] smb2_tree_disconnect+0x1cd/0x480<br /> [ 4.152211] handle_ksmbd_work+0x40f/0x1080<br /> [ 4.152326] process_one_work+0x5fa/0xef0<br /> [ 4.152438] worker_thread+0x54b/0xf70<br /> [ 4.152545] kthread+0x346/0x470<br /> [ 4.152638] ret_from_fork+0x4fb/0x6c0<br /> [ 4.152743] ret_from_fork_asm+0x1a/0x30<br /> [ 4.152853]<br /> [ 4.152900] The buggy address belongs to the object at ffff88810430c180<br /> [ 4.152900] which belongs to the cache kmalloc-96 of size 96<br /> [ 4.153226] The buggy address is located 20 bytes inside of<br /> [ 4.153226] freed 96-byte region [ffff88810430c180, ffff88810430c1e0)<br /> [ 4.153549]<br /> [ 4.153596] The buggy address belongs to the physical page:<br /> [ 4.153750] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810430ce80 pfn:0x10430c<br /> [ 4.154000] flags: 0x<br /> ---truncated---