Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: errata: Mitigate TLBI errata on various Arm CPUs<br /> <br /> A number of CPUs developed by Arm suffer from errata whereby a broadcast<br /> TLBI;DSB sequence may complete before the global observation of writes<br /> which are translated by an affected TLB entry.<br /> <br /> These errata ONLY affect the completion of memory accesses which have<br /> been translated by an invalidated TLB entry, and these errata DO NOT<br /> affect the actual invalidation of TLB entries. TLB entries are removed<br /> correctly.<br /> <br /> This issue has been assigned CVE ID CVE-2025-10263.<br /> <br /> To mitigate this issue, Arm recommends that software follows any<br /> affected TLBI;DSB sequence with an additional TLBI;DSB, which will<br /> ensure that all memory write effects affected by the first TLBI have<br /> been globally observed. The additional TLBI can use any operation that<br /> is broadcast to affected CPUs, and the additional DSB can use any option<br /> that is sufficient to complete the additional TLBI.<br /> <br /> The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate<br /> the issue. Enable this workaround for affected CPUs, and update the<br /> silicon errata documentation accordingly.<br /> <br /> Note that due to the manner in which Arm develops IP and tracks errata,<br /> some CPUs share a common erratum number.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hsr: Remove WARN_ONCE() in hsr_addr_is_self().<br /> <br /> syzbot reported the warning [0] in hsr_addr_is_self(),<br /> whose assumption is simply wrong.<br /> <br /> hsr-&gt;self_node is cleared in hsr_del_self_node(), which<br /> is called from hsr_dellink().<br /> <br /> Since dev-&gt;rtnl_link_ops-&gt;dellink() is called before<br /> unregister_netdevice_many(), there is a window when<br /> user can find the device but without hsr-&gt;self_node.<br /> <br /> Let&amp;#39;s remove WARN_ONCE() in hsr_addr_is_self().<br /> <br /> [0]:<br /> HSR: No self node<br /> WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)}<br /> Tainted: [L]=SOFTLOCKUP<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026<br /> RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39<br /> Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96<br /> RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283<br /> RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000<br /> RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700<br /> RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000<br /> R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000<br /> FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0<br /> DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002<br /> DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> check_local_dest net/hsr/hsr_forward.c:592 [inline]<br /> fill_frame_info net/hsr/hsr_forward.c:728 [inline]<br /> hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739<br /> hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236<br /> __netdev_start_xmit include/linux/netdevice.h:5368 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:5377 [inline]<br /> xmit_one net/core/dev.c:3888 [inline]<br /> dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904<br /> __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870<br /> neigh_output include/net/neighbour.h:556 [inline]<br /> ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237<br /> ip_send_skb net/ipv4/ip_output.c:1510 [inline]<br /> ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530<br /> raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659<br /> sock_sendmsg_nosec net/socket.c:787 [inline]<br /> __sock_sendmsg net/socket.c:802 [inline]<br /> ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698<br /> ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752<br /> __sys_sendmsg net/socket.c:2784 [inline]<br /> __do_sys_sendmsg net/socket.c:2789 [inline]<br /> __se_sys_sendmsg net/socket.c:2787 [inline]<br /> __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f6feb62ce59<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59<br /> RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004<br /> RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads()<br /> <br /> When a multi-threaded process receives a stop signal (e.g., SIGSTOP),<br /> do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all<br /> threads and sets signal-&gt;group_stop_count to the number of threads. If<br /> one of the threads concurrently calls execve(), de_thread() invokes<br /> zap_other_threads() to kill all other threads. zap_other_threads()<br /> aborts the pending group stop by resetting signal-&gt;group_stop_count to 0<br /> and clears the JOBCTL_PENDING_MASK for all other threads. However, it<br /> fails to clear the job control flags for the calling thread.<br /> <br /> When execve() completes, the calling thread returns to user mode and<br /> checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag,<br /> it calls do_signal_stop(), which invokes task_participate_group_stop().<br /> Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the<br /> already-zero signal-&gt;group_stop_count, triggering a warning:<br /> <br /> sig-&gt;group_stop_count == 0<br /> WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373<br /> task_participate_group_stop+0x215/0x2d0<br /> Call Trace:<br /> <br /> do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619<br /> get_signal+0xa8c/0x1330 kernel/signal.c:2884<br /> arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337<br /> exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98<br /> do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> Fix this race condition by clearing the JOBCTL_PENDING_MASK for the<br /> calling thread in zap_other_threads(), ensuring it does not retain any<br /> stale job control state after the thread group is destroyed. This aligns<br /> with other functions that tear down a thread group and abort group<br /> stops, such as zap_process() and complete_signal(), which correctly<br /> clear these flags for all threads including the current one.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv/ptrace: Use USER_REGSET_NOTE_TYPE for REGSET_CFI<br /> <br /> Fixes a warning while dumping core:<br /> <br /> [54983.546369][ C7] WARNING: [!note_name] fs/binfmt_elf.c:1771 at elf_core_dump+0x910/0xf68, CPU#7: abort01/31982

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: wm_adsp: Fix NULL dereference when removing firmware controls<br /> <br /> In wm_adsp_control_remove() check that the priv pointer is not NULL<br /> before attempting to cleanup what it points to.<br /> <br /> When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that<br /> wm_adsp can create its own private control data. There are two cases<br /> where private data is not created:<br /> <br /> 1. The control is a SYSTEM control, so an ALSA control is not created.<br /> <br /> 2. The codec driver has registered a control_add() callback that<br /> hides the control, so wm_adsp_control_add() is not called.<br /> <br /> When cs_dsp_remove destroys its control list it calls<br /> wm_adsp_control_remove() for each control. But wm_adsp_control_remove()<br /> was attempting to cleanup the private data pointed to by cs_ctl-&gt;priv<br /> without checking the pointer for NULL.

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