Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: clip: Fix potential null-ptr-deref in to_atmarpd().<br /> <br /> atmarpd is protected by RTNL since commit f3a0592b37b8 ("[ATM]: clip<br /> causes unregister hang").<br /> <br /> However, it is not enough because to_atmarpd() is called without RTNL,<br /> especially clip_neigh_solicit() / neigh_ops-&gt;solicit() is unsleepable.<br /> <br /> Also, there is no RTNL dependency around atmarpd.<br /> <br /> Let&amp;#39;s use a private mutex and RCU to protect access to atmarpd in<br /> to_atmarpd().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock: Fix transport_* TOCTOU<br /> <br /> Transport assignment may race with module unload. Protect new_transport<br /> from becoming a stale pointer.<br /> <br /> This also takes care of an insecure call in vsock_use_local_transport();<br /> add a lockdep assert.<br /> <br /> BUG: unable to handle page fault for address: fffffbfff8056000<br /> Oops: Oops: 0000 [#1] SMP KASAN<br /> RIP: 0010:vsock_assign_transport+0x366/0x600<br /> Call Trace:<br /> vsock_connect+0x59c/0xc40<br /> __sys_connect+0xe8/0x100<br /> __x64_sys_connect+0x6e/0xc0<br /> do_syscall_64+0x92/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight<br /> <br /> Reject migration of SEV{-ES} state if either the source or destination VM<br /> is actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the<br /> section between incrementing created_vcpus and online_vcpus. The bulk of<br /> vCPU creation runs _outside_ of kvm-&gt;lock to allow creating multiple vCPUs<br /> in parallel, and so sev_info.es_active can get toggled from false=&gt;true in<br /> the destination VM after (or during) svm_vcpu_create(), resulting in an<br /> SEV{-ES} VM effectively having a non-SEV{-ES} vCPU.<br /> <br /> The issue manifests most visibly as a crash when trying to free a vCPU&amp;#39;s<br /> NULL VMSA page in an SEV-ES VM, but any number of things can go wrong.<br /> <br /> BUG: unable to handle page fault for address: ffffebde00000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE<br /> Tainted: [U]=USER, [O]=OOT_MODULE<br /> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024<br /> RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline]<br /> RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline]<br /> RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline]<br /> RIP: 0010:PageHead include/linux/page-flags.h:866 [inline]<br /> RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067<br /> Code: f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0<br /> RSP: 0018:ffff8984551978d0 EFLAGS: 00010246<br /> RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98<br /> RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000<br /> RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000<br /> R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000<br /> R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000<br /> FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0<br /> DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169<br /> svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515<br /> kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396<br /> kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline]<br /> kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490<br /> kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895<br /> kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310<br /> kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369<br /> __fput+0x3e4/0x9e0 fs/file_table.c:465<br /> task_work_run+0x1a9/0x220 kernel/task_work.c:227<br /> exit_task_work include/linux/task_work.h:40 [inline]<br /> do_exit+0x7f0/0x25b0 kernel/exit.c:953<br /> do_group_exit+0x203/0x2d0 kernel/exit.c:1102<br /> get_signal+0x1357/0x1480 kernel/signal.c:3034<br /> arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337<br /> exit_to_user_mode_loop kernel/entry/common.c:111 [inline]<br /> exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]<br /> syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218<br /> do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f87a898e969<br /> <br /> Modules linked in: gq(O)<br /> gsmi: Log Shutdown Reason 0x03<br /> CR2: ffffebde00000000<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Deliberately don&amp;#39;t check for a NULL VMSA when freeing the vCPU, as crashing<br /> the host is likely desirable due to the VMSA being consumed by hardware.<br /> E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a<br /> bogus VMSA page. Accessing P<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ad1816a: Fix potential NULL pointer deref in snd_card_ad1816a_pnp()<br /> <br /> Use pr_warn() instead of dev_warn() when &amp;#39;pdev&amp;#39; is NULL to avoid a<br /> potential NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: u_serial: Fix race condition in TTY wakeup<br /> <br /> A race condition occurs when gs_start_io() calls either gs_start_rx() or<br /> gs_start_tx(), as those functions briefly drop the port_lock for<br /> usb_ep_queue(). This allows gs_close() and gserial_disconnect() to clear<br /> port.tty and port_usb, respectively.<br /> <br /> Use the null-safe TTY Port helper function to wake up TTY.<br /> <br /> Example<br /> CPU1: CPU2:<br /> gserial_connect() // lock<br /> gs_close() // await lock<br /> gs_start_rx() // unlock<br /> usb_ep_queue()<br /> gs_close() // lock, reset port.tty and unlock<br /> gs_start_rx() // lock<br /> tty_wakeup() // NPE

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/md-bitmap: fix GPF in bitmap_get_stats()<br /> <br /> The commit message of commit 6ec1f0239485 ("md/md-bitmap: fix stats<br /> collection for external bitmaps") states:<br /> <br /> Remove the external bitmap check as the statistics should be<br /> available regardless of bitmap storage location.<br /> <br /> Return -EINVAL only for invalid bitmap with no storage (neither in<br /> superblock nor in external file).<br /> <br /> But, the code does not adhere to the above, as it does only check for<br /> a valid super-block for "internal" bitmaps. Hence, we observe:<br /> <br /> Oops: GPF, probably for non-canonical address 0x1cd66f1f40000028<br /> RIP: 0010:bitmap_get_stats+0x45/0xd0<br /> Call Trace:<br /> <br /> seq_read_iter+0x2b9/0x46a<br /> seq_read+0x12f/0x180<br /> proc_reg_read+0x57/0xb0<br /> vfs_read+0xf6/0x380<br /> ksys_read+0x6d/0xf0<br /> do_syscall_64+0x8c/0x1b0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> We fix this by checking the existence of a super-block for both the<br /> internal and external case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: imx: Fix an out-of-bounds access in dispmix_csr_clk_dev_data<br /> <br /> When num_parents is 4, __clk_register() occurs an out-of-bounds<br /> when accessing parent_names member. Use ARRAY_SIZE() instead of<br /> hardcode number here.<br /> <br /> BUG: KASAN: global-out-of-bounds in __clk_register+0x1844/0x20d8<br /> Read of size 8 at addr ffff800086988e78 by task kworker/u24:3/59<br /> Hardware name: NXP i.MX95 19X19 board (DT)<br /> Workqueue: events_unbound deferred_probe_work_func<br /> Call trace:<br /> dump_backtrace+0x94/0xec<br /> show_stack+0x18/0x24<br /> dump_stack_lvl+0x8c/0xcc<br /> print_report+0x398/0x5fc<br /> kasan_report+0xd4/0x114<br /> __asan_report_load8_noabort+0x20/0x2c<br /> __clk_register+0x1844/0x20d8<br /> clk_hw_register+0x44/0x110<br /> __clk_hw_register_mux+0x284/0x3a8<br /> imx95_bc_probe+0x4f4/0xa70

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/rmap: fix potential out-of-bounds page table access during batched unmap<br /> <br /> As pointed out by David[1], the batched unmap logic in<br /> try_to_unmap_one() may read past the end of a PTE table when a large<br /> folio&amp;#39;s PTE mappings are not fully contained within a single page<br /> table.<br /> <br /> While this scenario might be rare, an issue triggerable from userspace<br /> must be fixed regardless of its likelihood. This patch fixes the<br /> out-of-bounds access by refactoring the logic into a new helper,<br /> folio_unmap_pte_batch().<br /> <br /> The new helper correctly calculates the safe batch size by capping the<br /> scan at both the VMA and PMD boundaries. To simplify the code, it also<br /> supports partial batching (i.e., any number of pages from 1 up to the<br /> calculated safe maximum), as there is no strong reason to special-case<br /> for fully mapped folios.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gem: Acquire references on GEM handles for framebuffers<br /> <br /> A GEM handle can be released while the GEM buffer object is attached<br /> to a DRM framebuffer. This leads to the release of the dma-buf backing<br /> the buffer object, if any. [1] Trying to use the framebuffer in further<br /> mode-setting operations leads to a segmentation fault. Most easily<br /> happens with driver that use shadow planes for vmap-ing the dma-buf<br /> during a page flip. An example is shown below.<br /> <br /> [ 156.791968] ------------[ cut here ]------------<br /> [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430<br /> [...]<br /> [ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430<br /> [ 157.043420] Call Trace:<br /> [ 157.045898] <br /> [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0<br /> [ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0<br /> [ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0<br /> [ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710<br /> [ 157.065567] ? dma_buf_vmap+0x224/0x430<br /> [ 157.069446] ? __warn.cold+0x58/0xe4<br /> [ 157.073061] ? dma_buf_vmap+0x224/0x430<br /> [ 157.077111] ? report_bug+0x1dd/0x390<br /> [ 157.080842] ? handle_bug+0x5e/0xa0<br /> [ 157.084389] ? exc_invalid_op+0x14/0x50<br /> [ 157.088291] ? asm_exc_invalid_op+0x16/0x20<br /> [ 157.092548] ? dma_buf_vmap+0x224/0x430<br /> [ 157.096663] ? dma_resv_get_singleton+0x6d/0x230<br /> [ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10<br /> [ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10<br /> [ 157.110697] drm_gem_shmem_vmap+0x74/0x710<br /> [ 157.114866] drm_gem_vmap+0xa9/0x1b0<br /> [ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0<br /> [ 157.123086] drm_gem_fb_vmap+0xab/0x300<br /> [ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10<br /> [ 157.133032] ? lockdep_init_map_type+0x19d/0x880<br /> [ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0<br /> [ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180<br /> [ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40<br /> [...]<br /> [ 157.346424] ---[ end trace 0000000000000000 ]---<br /> <br /> Acquiring GEM handles for the framebuffer&amp;#39;s GEM buffer objects prevents<br /> this from happening. The framebuffer&amp;#39;s cleanup later puts the handle<br /> references.<br /> <br /> Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object<br /> instance") triggers the segmentation fault easily by using the dma-buf<br /> field more widely. The underlying issue with reference counting has<br /> been present before.<br /> <br /> v2:<br /> - acquire the handle instead of the BO (Christian)<br /> - fix comment style (Christian)<br /> - drop the Fixes tag (Christian)<br /> - rename err_ gotos<br /> - add missing Link tag

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_sta_set_decap_offload()<br /> <br /> Add a NULL check for msta-&gt;vif before accessing its members to prevent<br /> a kernel panic in AP mode deployment. This also fix the issue reported<br /> in [1].<br /> <br /> The crash occurs when this function is triggered before the station is<br /> fully initialized. The call trace shows a page fault at<br /> mt7925_sta_set_decap_offload() due to accessing resources when msta-&gt;vif<br /> is NULL.<br /> <br /> Fix this by adding an early return if msta-&gt;vif is NULL and also check<br /> wcid.sta is ready. This ensures we only proceed with decap offload<br /> configuration when the station&amp;#39;s state is properly initialized.<br /> <br /> [14739.655703] Unable to handle kernel paging request at virtual address ffffffffffffffa0<br /> [14739.811820] CPU: 0 UID: 0 PID: 895854 Comm: hostapd Tainted: G<br /> [14739.821394] Tainted: [C]=CRAP, [O]=OOT_MODULE<br /> [14739.825746] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)<br /> [14739.831577] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [14739.838538] pc : mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common]<br /> [14739.845271] lr : mt7925_sta_set_decap_offload+0x58/0x1b8 [mt7925_common]<br /> [14739.851985] sp : ffffffc085efb500<br /> [14739.855295] x29: ffffffc085efb500 x28: 0000000000000000 x27: ffffff807803a158<br /> [14739.862436] x26: ffffff8041ececb8 x25: 0000000000000001 x24: 0000000000000001<br /> [14739.869577] x23: 0000000000000001 x22: 0000000000000008 x21: ffffff8041ecea88<br /> [14739.876715] x20: ffffff8041c19ca0 x19: ffffff8078031fe0 x18: 0000000000000000<br /> [14739.883853] x17: 0000000000000000 x16: ffffffe2aeac1110 x15: 000000559da48080<br /> [14739.890991] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000<br /> [14739.898130] x11: 0a10020001008e88 x10: 0000000000001a50 x9 : ffffffe26457bfa0<br /> [14739.905269] x8 : ffffff8042013bb0 x7 : ffffff807fb6cbf8 x6 : dead000000000100<br /> [14739.912407] x5 : dead000000000122 x4 : ffffff80780326c8 x3 : 0000000000000000<br /> [14739.919546] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8041ececb8<br /> [14739.926686] Call trace:<br /> [14739.929130] mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common]<br /> [14739.935505] ieee80211_check_fast_rx+0x19c/0x510 [mac80211]<br /> [14739.941344] _sta_info_move_state+0xe4/0x510 [mac80211]<br /> [14739.946860] sta_info_move_state+0x1c/0x30 [mac80211]<br /> [14739.952116] sta_apply_auth_flags.constprop.0+0x90/0x1b0 [mac80211]<br /> [14739.958708] sta_apply_parameters+0x234/0x5e0 [mac80211]<br /> [14739.964332] ieee80211_add_station+0xdc/0x190 [mac80211]<br /> [14739.969950] nl80211_new_station+0x46c/0x670 [cfg80211]<br /> [14739.975516] genl_family_rcv_msg_doit+0xdc/0x150<br /> [14739.980158] genl_rcv_msg+0x218/0x298<br /> [14739.983830] netlink_rcv_skb+0x64/0x138<br /> [14739.987670] genl_rcv+0x40/0x60<br /> [14739.990816] netlink_unicast+0x314/0x380<br /> [14739.994742] netlink_sendmsg+0x198/0x3f0<br /> [14739.998664] __sock_sendmsg+0x64/0xc0<br /> [14740.002324] ____sys_sendmsg+0x260/0x298<br /> [14740.006242] ___sys_sendmsg+0xb4/0x110

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: rtsn: Fix a null pointer dereference in rtsn_probe()<br /> <br /> Add check for the return value of rcar_gen4_ptp_alloc()<br /> to prevent potential null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/msg_ring: ensure io_kiocb freeing is deferred for RCU<br /> <br /> syzbot reports that defer/local task_work adding via msg_ring can hit<br /> a request that has been freed:<br /> <br /> CPU: 1 UID: 0 PID: 19356 Comm: iou-wrk-19354 Not tainted 6.16.0-rc4-syzkaller-00108-g17bbde2e1716 #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:408 [inline]<br /> print_report+0xd2/0x2b0 mm/kasan/report.c:521<br /> kasan_report+0x118/0x150 mm/kasan/report.c:634<br /> io_req_local_work_add io_uring/io_uring.c:1184 [inline]<br /> __io_req_task_work_add+0x589/0x950 io_uring/io_uring.c:1252<br /> io_msg_remote_post io_uring/msg_ring.c:103 [inline]<br /> io_msg_data_remote io_uring/msg_ring.c:133 [inline]<br /> __io_msg_ring_data+0x820/0xaa0 io_uring/msg_ring.c:151<br /> io_msg_ring_data io_uring/msg_ring.c:173 [inline]<br /> io_msg_ring+0x134/0xa00 io_uring/msg_ring.c:314<br /> __io_issue_sqe+0x17e/0x4b0 io_uring/io_uring.c:1739<br /> io_issue_sqe+0x165/0xfd0 io_uring/io_uring.c:1762<br /> io_wq_submit_work+0x6e9/0xb90 io_uring/io_uring.c:1874<br /> io_worker_handle_work+0x7cd/0x1180 io_uring/io-wq.c:642<br /> io_wq_worker+0x42f/0xeb0 io_uring/io-wq.c:696<br /> ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> <br /> which is supposed to be safe with how requests are allocated. But msg<br /> ring requests alloc and free on their own, and hence must defer freeing<br /> to a sane time.<br /> <br /> Add an rcu_head and use kfree_rcu() in both spots where requests are<br /> freed. Only the one in io_msg_tw_complete() is strictly required as it<br /> has been visible on the other ring, but use it consistently in the other<br /> spot as well.<br /> <br /> This should not cause any other issues outside of KASAN rightfully<br /> complaining about it.