Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack: destroy stale expectfn expectations on unregister<br /> <br /> NAT helpers such as nf_nat_h323 store a raw pointer to module text in<br /> exp-&gt;expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister()<br /> only unlinks the callback descriptor and never walks the expectation table,<br /> so an expectation pending at module removal survives with a dangling<br /> exp-&gt;expectfn into freed module text.<br /> <br /> When the expected connection arrives, init_conntrack() invokes<br /> exp-&gt;expectfn(), now a stale pointer into the unloaded module. Reproduced<br /> on a KASAN build by loading the H.323 helpers, creating a Q.931<br /> expectation, unloading nf_nat_h323, then connecting to the expected port:<br /> <br /> Oops: int3: 0000 [#1] SMP KASAN NOPTI<br /> RIP: 0010:0xffffffffa06102d1<br /> init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862)<br /> nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049)<br /> ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223)<br /> nf_hook_slow (net/netfilter/core.c:619)<br /> __ip_local_out (net/ipv4/ip_output.c:120)<br /> __tcp_transmit_skb (net/ipv4/tcp_output.c:1715)<br /> tcp_connect (net/ipv4/tcp_output.c:4374)<br /> tcp_v4_connect (net/ipv4/tcp_ipv4.c:345)<br /> __sys_connect (net/socket.c:2167)<br /> Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323]<br /> <br /> Reaching the dangling state requires CAP_SYS_MODULE in the initial user<br /> namespace to remove a NAT helper that still has live expectations, so this<br /> is a robustness fix; leaving an expectation pointing at freed text is wrong<br /> regardless.<br /> <br /> Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and<br /> drops every expectation whose -&gt;expectfn matches the descriptor being torn<br /> down. Call it from each NAT helper&amp;#39;s exit path after the existing RCU grace<br /> period, so no expectation outlives the code it points at and no extra<br /> synchronize_rcu() is introduced. With the fix, the same reproducer runs to<br /> completion without the Oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: mcp23s08: Initialize mcp-&gt;dev and mcp-&gt;addr before regmap init<br /> <br /> Regmap initialization triggers regcache_maple_populate() which attempts<br /> SPI read to populate cache. SPI read requires mcp-&gt;dev and mcp-&gt;addr to<br /> be set, without them, NULL pointer dereference occurs during probe.<br /> <br /> Move initialization before mcp23s08_spi_regmap_init() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: imx: fix clock and pinctrl state inconsistency in runtime PM<br /> <br /> In i2c_imx_runtime_suspend(), the clock is disabled before switching<br /> the pinctrl state to sleep. If pinctrl_pm_select_sleep_state() fails,<br /> the runtime suspend is aborted but the clock remains disabled, causing<br /> a system crash when the hardware is subsequently accessed.<br /> <br /> Fix this by switching the pinctrl state before disabling the clock so<br /> that a pinctrl failure leaves the clock enabled and the hardware<br /> accessible.<br /> <br /> In i2c_imx_runtime_resume(), restore the pinctrl state back to sleep<br /> if clk_enable() fails to keep the consistent.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: mm: call pagetable dtor when freeing hot-removed page tables<br /> <br /> Since 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in<br /> __create_pgd_mapping()") page-table allocation on ARM64 always calls<br /> pagetable_{pte,pmd,pud,p4d}_ctor(). This sets the page_type to<br /> PGTY_table, increments NR_PAGETABLE and possible allocates a PTL. However<br /> the matching pagetable_dtor() calls were never added.<br /> <br /> With DEBUG_VM enabled on kernel versions prior to v6.17 without<br /> 2dfcd1608f3a9 ("mm/page_alloc: let page freeing clear any set page type")<br /> this leads to the following warning when freeing these pages due to<br /> page-&gt;page_type sharing page-&gt;_mapcount:<br /> <br /> BUG: Bad page state in process ... pfn:284fbb<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x284fbb<br /> flags: 0x17fffc000000000(node=0|zone=2|lastcpupid=0x1ffff)<br /> page_type: f2(table)<br /> page dumped because: nonzero mapcount<br /> Call trace:<br /> bad_page+0x13c/0x160<br /> __free_frozen_pages+0x6cc/0x860<br /> ___free_pages+0xf4/0x180<br /> free_pages+0x54/0x80<br /> free_hotplug_page_range.part.0+0x58/0x90<br /> free_empty_tables+0x438/0x500<br /> __remove_pgd_mapping.constprop.0+0x60/0xa8<br /> arch_remove_memory+0x48/0x80<br /> try_remove_memory+0x158/0x1d8<br /> offline_and_remove_memory+0x138/0x180<br /> <br /> It can also lead to leaking the ptl allocation if ALLOC_SPLIT_PTLOCKS is<br /> defined and incorrect NR_PAGETABLE stats. Fix this by calling<br /> pagetable_dtor() in free_hotplug_pgtable_page() prior to freeing the page<br /> to undo the effects of calling pagetable_*_ctor().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow<br /> <br /> Commit 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from<br /> VMAP shadow") added a dummy read from the KASAN VMAP stack shadow in<br /> __switch_to(). The read uses ldr, but the KASAN shadow address is<br /> byte-granular and is not guaranteed to be word aligned.<br /> <br /> ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and<br /> CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to()<br /> with an alignment exception before reaching init.<br /> <br /> Use ldrb for the dummy shadow access. The code only needs to fault in the<br /> shadow mapping if the stack shadow is missing, so a byte load is sufficient<br /> and matches the granularity of KASAN shadow memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fhandle: fix UAF due to unlocked -&gt;mnt_ns read in may_decode_fh()<br /> <br /> may_decode_fh() accesses mount::mnt_ns without holding any locks; that<br /> means the mount can concurrently be unmounted, and the mnt_namespace can<br /> concurrently be freed after an RCU grace period.<br /> <br /> This race can happens as follows, assuming that the mount point was<br /> created by open_tree(..., OPEN_TREE_CLONE):<br /> <br /> thread 1 thread 2 RCU<br /> __do_sys_open_by_handle_at<br /> do_handle_open<br /> handle_to_path<br /> may_decode_fh<br /> is_mounted<br /> [mount::mnt_ns access]<br /> [mount::mnt_ns access]<br /> __do_sys_close<br /> fput_close_sync<br /> __fput<br /> dissolve_on_fput<br /> umount_tree<br /> class_namespace_excl_destructor<br /> namespace_unlock<br /> free_mnt_ns<br /> mnt_ns_tree_remove<br /> call_rcu(mnt_ns_release_rcu)<br /> mnt_ns_release_rcu<br /> mnt_ns_release<br /> kfree<br /> [mnt_namespace::user_ns access] **UAF**<br /> <br /> Fix it by taking rcu_read_lock() around the mount::mnt_ns access, like<br /> in __prepend_path().<br /> Additionally, document the semantics of mount::mnt_ns, and use WRITE_ONCE()<br /> for writers that can race with lockless readers.<br /> <br /> This bug is unreachable unless one of the following is set:<br /> <br /> - CONFIG_PREEMPTION<br /> - CONFIG_RCU_STRICT_GRACE_PERIOD<br /> <br /> because it requires an RCU grace period to happen during a syscall without<br /> an explicit preemption.<br /> <br /> This doesn&amp;#39;t seem to have interesting security impact; worst-case, it could<br /> leak the result of an integer comparison to userspace (from the level<br /> check in cap_capable()), cause an endless loop, or crash the kernel by<br /> dereferencing an invalid address.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SDCA: fix NULL pointer dereference in sdca_dev_unregister_functions<br /> <br /> sdca_dev_unregister_functions() iterates over all SDCA function<br /> descriptors and calls sdca_dev_unregister() on each func_dev without<br /> checking for NULL. When a function registration has failed partway<br /> through, or the device cleanup races with probe deferral, func_dev<br /> entries may be NULL, leading to a kernel oops:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000040<br /> RIP: 0010:device_del+0x1e/0x3e0<br /> Call Trace:<br /> sdca_dev_unregister_functions+0x37/0x60 [snd_soc_sdca]<br /> release_nodes+0x35/0xb0<br /> devres_release_all+0x90/0x100<br /> device_unbind_cleanup+0xe/0x80<br /> device_release_driver_internal+0x1c1/0x200<br /> bus_remove_device+0xc6/0x130<br /> device_del+0x161/0x3e0<br /> device_unregister+0x17/0x60<br /> sdw_delete_slave+0xb6/0xd0 [soundwire_bus]<br /> sdw_bus_master_delete+0x1e/0x50 [soundwire_bus]<br /> ...<br /> sof_probe_work+0x19/0x30 [snd_sof]<br /> <br /> This was observed on a Lenovo ThinkPad X1 Carbon G14 (Panther Lake)<br /> with the SOF audio driver probe failing due to missing Panther Lake<br /> firmware, causing the subsequent cleanup of SoundWire devices to<br /> trigger the crash.<br /> <br /> Fix this with three changes:<br /> <br /> 1) Add a NULL guard in sdca_dev_unregister() so that callers do not<br /> need to pre-validate the pointer (defense in depth).<br /> <br /> 2) In sdca_dev_unregister_functions(), skip NULL func_dev entries<br /> and clear func_dev to NULL after unregistration, making the<br /> function idempotent and safe against double-invocation.<br /> <br /> 3) In sdca_dev_register_functions(), roll back all previously<br /> registered functions when a later one fails, so the function<br /> array is never left in a partially-populated state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/virtio: Fix driver removal with disabled KMS<br /> <br /> DRM atomic and modesetting aren&amp;#39;t initialized if virtio-gpu driver built<br /> with disabled KMS, leading to access of uninitialized data on driver<br /> removal/unbinding and crashing kernel. Fix it by skipping shutting down<br /> atomic core with unavailable KMS.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust: arm64: set uwtable llvm module flag for CONFIG_UNWIND_TABLES<br /> <br /> Due to a rustc bug [1] the -Cforce-unwind-tables=y flag only emits the<br /> uwtable annotation for functions, but not for the module. This means<br /> that compiler-generated functions such as &amp;#39;asan.module_ctor&amp;#39; do not<br /> receive the uwtable annotation.<br /> <br /> When CONFIG_UNWIND_PATCH_PAC_INTO_SCS is enabled, this leads to boot<br /> failures because the dwarf information emitted for the kasan<br /> constructors is wrong, which causes the SCS boot patching code to<br /> patch the constructor in an illegal manner. Specifically, the paciasp<br /> instruction is patched, but the autiasp instruction is not. This<br /> mismatch leads to a crash when the constructor is called during boot.<br /> <br /> ==================================================================<br /> BUG: KASAN: global-out-of-bounds in do_basic_setup+0x4c/0x90<br /> Read of size 8 at addr ffffffe3cc7eb488 by task swapper/0/1<br /> <br /> Specifically the faulting instruction is the (*fn)() to invoke the<br /> constructor in do_ctors() of the init/main.c file.<br /> <br /> Once the fix lands in rustc, this flag can be made conditional on the<br /> rustc version. Note that passing the flag on a rustc with the fix<br /> present has no effect.<br /> <br /> [ The fix [1] has landed for Rust 1.98.0 (expected release on<br /> 2026-08-20).<br /> <br /> Thus add a version check as discussed.<br /> <br /> - Miguel ]<br /> <br /> [ Adjusted link and comment. - Miguel ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Don&amp;#39;t WARN if memory is dirtied without a vCPU when the VM is dying<br /> <br /> When marking a page dirty, complain about not having a running/loaded vCPU<br /> if and only if the VM is still alive, i.e. its refcount is non-zero. This<br /> will allow fixing a memory leak for x86 SEV-ES guests without hitting what<br /> is effectively a false positive on the WARN.<br /> <br /> For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page<br /> across an exit to userspace, and typically unmaps the page on the next<br /> KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM<br /> needs to unmap the page when the vCPU is destroyed, which in turn triggers<br /> the WARN about not having a running vCPU.<br /> <br /> Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN,<br /> as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons;<br /> suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But<br /> loading a vCPU during destruction is gross (ideally nVMX code would be<br /> cleaned up), risks complicating the SEV-ES code (KVM would need to ensure<br /> the temporarily load()+put() only runs when the vCPU isn&amp;#39;t already loaded),<br /> and is ultimately pointless.<br /> <br /> The motivation for the WARN is to guard against KVM dirtying guest memory<br /> without pushing the corresponding GFN to the active vCPU&amp;#39;s dirty ring, e.g.<br /> to ensure userspace doesn&amp;#39;t miss a dirty page. But for the VM&amp;#39;s refcount<br /> to reach zero, there can&amp;#39;t be _any_ userspace mappings to the dirty ring,<br /> as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if<br /> userspace had a valid mapping for the dirty ring, then the vCPU file and<br /> thus the owning VM would still be alive. And so since userspace can&amp;#39;t<br /> possibly reach the dirty ring, whether or not KVM technically "misses" a<br /> push to the dirty ring is irrelevant.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd<br /> <br /> When the remoteproc starts in parallel with the NGD driver being probed,<br /> or the remoteproc is already up when the PDR lookup is being registered,<br /> or in the theoretical event that we get an interrupt from the hardware,<br /> these callbacks will operate on uninitialized data. This result in<br /> issues to boot the affected boards.<br /> <br /> One such example can be seen in the following fault, where<br /> qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work.<br /> <br /> [ 21.858578] ------------[ cut here ]------------<br /> [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116<br /> ...<br /> [ 21.859251] Call trace:<br /> [ 21.859255] __queue_work+0x5e0/0x790 (P)<br /> [ 21.859265] queue_work_on+0x6c/0xf0<br /> [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl]<br /> [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl]<br /> [ 21.859318] notifier_call_chain+0xa4/0x230<br /> [ 21.859329] srcu_notifier_call_chain+0x64/0xb8<br /> [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common]<br /> [ 21.859355] rproc_start+0x130/0x230<br /> [ 21.859367] rproc_boot+0x3d4/0x518<br /> ...<br /> <br /> Move the enablement of interrupts, and the registration of SSR and PDR<br /> until after the NGD device has been registered.<br /> <br /> This could be further refined by moving initialization to the control<br /> driver probe and by removing the platform driver model from the picture.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/mincore: handle non-swap entries before !CONFIG_SWAP guard<br /> <br /> mincore_swap() also fields migration/hwpoison entries (and shmem<br /> swapin-error entries), which can exist on !CONFIG_SWAP builds when<br /> CONFIG_MIGRATION or CONFIG_MEMORY_FAILURE is enabled. The<br /> !IS_ENABLED(CONFIG_SWAP) guard ran before the non-swap-entry early return,<br /> so mincore_pte_range() can spuriously WARN and report these pages<br /> nonresident on !CONFIG_SWAP kernels.<br /> <br /> Move the guard below the non-swap-entry check so only true swap entries<br /> trip the WARN, and migration/hwpoison entries take the existing "uptodate<br /> / non-shmem" path.