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 /> net: mvpp2: guard flow control update with global_tx_fc in buffer switching<br /> <br /> mvpp2_bm_switch_buffers() unconditionally calls<br /> mvpp2_bm_pool_update_priv_fc() when switching between per-cpu and<br /> shared buffer pool modes. This function programs CM3 flow control<br /> registers via mvpp2_cm3_read()/mvpp2_cm3_write(), which dereference<br /> priv-&gt;cm3_base without any NULL check.<br /> <br /> When the CM3 SRAM resource is not present in the device tree (the<br /> third reg entry added by commit 60523583b07c ("dts: marvell: add CM3<br /> SRAM memory to cp11x ethernet device tree")), priv-&gt;cm3_base remains<br /> NULL and priv-&gt;global_tx_fc is false. Any operation that triggers<br /> mvpp2_bm_switch_buffers(), for example an MTU change that crosses<br /> the jumbo frame threshold, will crash:<br /> <br /> Unable to handle kernel NULL pointer dereference at<br /> virtual address 0000000000000000<br /> Mem abort info:<br /> ESR = 0x0000000096000006<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> pc : readl+0x0/0x18<br /> lr : mvpp2_cm3_read.isra.0+0x14/0x20<br /> Call trace:<br /> readl+0x0/0x18<br /> mvpp2_bm_pool_update_fc+0x40/0x12c<br /> mvpp2_bm_pool_update_priv_fc+0x94/0xd8<br /> mvpp2_bm_switch_buffers.isra.0+0x80/0x1c0<br /> mvpp2_change_mtu+0x140/0x380<br /> __dev_set_mtu+0x1c/0x38<br /> dev_set_mtu_ext+0x78/0x118<br /> dev_set_mtu+0x48/0xa8<br /> dev_ifsioc+0x21c/0x43c<br /> dev_ioctl+0x2d8/0x42c<br /> sock_ioctl+0x314/0x378<br /> <br /> Every other flow control call site in the driver already guards<br /> hardware access with either priv-&gt;global_tx_fc or port-&gt;tx_fc.<br /> mvpp2_bm_switch_buffers() is the only place that omits this check.<br /> <br /> Add the missing priv-&gt;global_tx_fc guard to both the disable and<br /> re-enable calls in mvpp2_bm_switch_buffers(), consistent with the<br /> rest of the driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: shaper: protect from late creation of hierarchy<br /> <br /> We look up a netdev during prep of Netlink ops (pre- callbacks)<br /> and take a ref to it. Then later in the body of the callback<br /> we take its lock or RCU which are the actual protections.<br /> <br /> The netdev may get unregistered in between the time we take<br /> the ref and the time we lock it. We may allocate the hierarchy<br /> after flush has already run, which would lead to a leak.<br /> <br /> Take the instance lock in pre- already, this saves us from the race<br /> and removes the need for dedicated lock/unlock callbacks completely.<br /> After all, if there&amp;#39;s any chance of write happening concurrently<br /> with the flush - we&amp;#39;re back to leaking the hierarchy.<br /> <br /> We may take the lock for devices which don&amp;#39;t support shapers but<br /> we&amp;#39;re only dealing with SET operations here, not taking the lock<br /> would be optimizing for an error case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86: Move event pointer setup earlier in x86_pmu_enable()<br /> <br /> A production AMD EPYC system crashed with a NULL pointer dereference<br /> in the PMU NMI handler:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000198<br /> RIP: x86_perf_event_update+0xc/0xa0<br /> Call Trace:<br /> <br /> amd_pmu_v2_handle_irq+0x1a6/0x390<br /> perf_event_nmi_handler+0x24/0x40<br /> <br /> The faulting instruction is `cmpq $0x0, 0x198(%rdi)` with RDI=0,<br /> corresponding to the `if (unlikely(!hwc-&gt;event_base))` check in<br /> x86_perf_event_update() where hwc = &amp;event-&gt;hw and event is NULL.<br /> <br /> drgn inspection of the vmcore on CPU 106 showed a mismatch between<br /> cpuc-&gt;active_mask and cpuc-&gt;events[]:<br /> <br /> active_mask: 0x1e (bits 1, 2, 3, 4)<br /> events[1]: 0xff1100136cbd4f38 (valid)<br /> events[2]: 0x0 (NULL, but active_mask bit 2 set)<br /> events[3]: 0xff1100076fd2cf38 (valid)<br /> events[4]: 0xff1100079e990a90 (valid)<br /> <br /> The event that should occupy events[2] was found in event_list[2]<br /> with hw.idx=2 and hw.state=0x0, confirming x86_pmu_start() had run<br /> (which clears hw.state and sets active_mask) but events[2] was<br /> never populated.<br /> <br /> Another event (event_list[0]) had hw.state=0x7 (STOPPED|UPTODATE|ARCH),<br /> showing it was stopped when the PMU rescheduled events, confirming the<br /> throttle-then-reschedule sequence occurred.<br /> <br /> The root cause is commit 7e772a93eb61 ("perf/x86: Fix NULL event access<br /> and potential PEBS record loss") which moved the cpuc-&gt;events[idx]<br /> assignment out of x86_pmu_start() and into step 2 of x86_pmu_enable(),<br /> after the PERF_HES_ARCH check. This broke any path that calls<br /> pmu-&gt;start() without going through x86_pmu_enable() -- specifically<br /> the unthrottle path:<br /> <br /> perf_adjust_freq_unthr_events()<br /> -&gt; perf_event_unthrottle_group()<br /> -&gt; perf_event_unthrottle()<br /> -&gt; event-&gt;pmu-&gt;start(event, 0)<br /> -&gt; x86_pmu_start() // sets active_mask but not events[]<br /> <br /> The race sequence is:<br /> <br /> 1. A group of perf events overflows, triggering group throttle via<br /> perf_event_throttle_group(). All events are stopped: active_mask<br /> bits cleared, events[] preserved (x86_pmu_stop no longer clears<br /> events[] after commit 7e772a93eb61).<br /> <br /> 2. While still throttled (PERF_HES_STOPPED), x86_pmu_enable() runs<br /> due to other scheduling activity. Stopped events that need to<br /> move counters get PERF_HES_ARCH set and events[old_idx] cleared.<br /> In step 2 of x86_pmu_enable(), PERF_HES_ARCH causes these events<br /> to be skipped -- events[new_idx] is never set.<br /> <br /> 3. The timer tick unthrottles the group via pmu-&gt;start(). Since<br /> commit 7e772a93eb61 removed the events[] assignment from<br /> x86_pmu_start(), active_mask[new_idx] is set but events[new_idx]<br /> remains NULL.<br /> <br /> 4. A PMC overflow NMI fires. The handler iterates active counters,<br /> finds active_mask[2] set, reads events[2] which is NULL, and<br /> crashes dereferencing it.<br /> <br /> Move the cpuc-&gt;events[hwc-&gt;idx] assignment in x86_pmu_enable() to<br /> before the PERF_HES_ARCH check, so that events[] is populated even<br /> for events that are not immediately started. This ensures the<br /> unthrottle path via pmu-&gt;start() always finds a valid event pointer.

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 /> 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 /> 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.

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 /> 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 /> 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.

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.