Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: Fix KMS with 3D on HW version 10<br /> <br /> HW version 10 does not have GB Surfaces so there is no backing buffer for<br /> surface backed FBs. This would result in a nullptr dereference and crash<br /> the driver causing a black screen.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: sideband: don&amp;#39;t dereference freed ring when removing sideband endpoint<br /> <br /> xhci_sideband_remove_endpoint() incorrecly assumes that the endpoint is<br /> running and has a valid transfer ring.<br /> <br /> Lianqin reported a crash during suspend/wake-up stress testing, and<br /> found the cause to be dereferencing a non-existing transfer ring<br /> &amp;#39;ep-&gt;ring&amp;#39; during xhci_sideband_remove_endpoint().<br /> <br /> The endpoint and its ring may be in unknown state if this function<br /> is called after xHCI was reinitialized in resume (lost power), or if<br /> device is being re-enumerated, disconnected or endpoint already dropped.<br /> <br /> Fix this by both removing unnecessary ring access, and by checking<br /> ep-&gt;ring exists before dereferencing it. Also make sure endpoint is<br /> running before attempting to stop it.<br /> <br /> Remove the xhci_initialize_ring_info() call during sideband endpoint<br /> removal as is it only initializes ring structure enqueue, dequeue and<br /> cycle state values to their starting values without changing actual<br /> hardware enqueue, dequeue and cycle state. Leaving them out of sync<br /> is worse than leaving it as it is. The endpoint will get freed in after<br /> this in most usecases.<br /> <br /> If the (audio) class driver want&amp;#39;s to reuse the endpoint after offload<br /> then it is up to the class driver to ensure endpoint is properly set up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()<br /> <br /> Blamed commit did not take care of VLAN encapsulations<br /> as spotted by syzbot [1].<br /> <br /> Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull().<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]<br /> BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]<br /> BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321<br /> __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]<br /> INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]<br /> IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321<br /> ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729<br /> __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860<br /> ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903<br /> gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1<br /> ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438<br /> ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500<br /> ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590<br /> dst_input include/net/dst.h:474 [inline]<br /> ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311<br /> __netif_receive_skb_one_core net/core/dev.c:6139 [inline]<br /> __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252<br /> netif_receive_skb_internal net/core/dev.c:6338 [inline]<br /> netif_receive_skb+0x57/0x630 net/core/dev.c:6397<br /> tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485<br /> tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953<br /> tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0xbe2/0x15d0 fs/read_write.c:686<br /> ksys_write fs/read_write.c:738 [inline]<br /> __do_sys_write fs/read_write.c:749 [inline]<br /> __se_sys_write fs/read_write.c:746 [inline]<br /> __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746<br /> x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:4960 [inline]<br /> slab_alloc_node mm/slub.c:5263 [inline]<br /> kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315<br /> kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586<br /> __alloc_skb+0x805/0x1040 net/core/skbuff.c:690<br /> alloc_skb include/linux/skbuff.h:1383 [inline]<br /> alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712<br /> sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995<br /> tun_alloc_skb drivers/net/tun.c:1461 [inline]<br /> tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794<br /> tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0xbe2/0x15d0 fs/read_write.c:686<br /> ksys_write fs/read_write.c:738 [inline]<br /> __do_sys_write fs/read_write.c:749 [inline]<br /> __se_sys_write fs/read_write.c:746 [inline]<br /> __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746<br /> x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> CPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1<br /> <br /> When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in<br /> response to a guest WRMSR, clear XFD-disabled features in the saved (or to<br /> be restored) XSTATE_BV to ensure KVM doesn&amp;#39;t attempt to load state for<br /> features that are disabled via the guest&amp;#39;s XFD. Because the kernel<br /> executes XRSTOR with the guest&amp;#39;s XFD, saving XSTATE_BV[i]=1 with XFD[i]=1<br /> will cause XRSTOR to #NM and panic the kernel.<br /> <br /> E.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:exc_device_not_available+0x101/0x110<br /> Call Trace:<br /> <br /> asm_exc_device_not_available+0x1a/0x20<br /> RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90<br /> switch_fpu_return+0x4a/0xb0<br /> kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm]<br /> kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]<br /> __x64_sys_ioctl+0x8f/0xd0<br /> do_syscall_64+0x62/0x940<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> This can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1,<br /> and a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler&amp;#39;s<br /> call to fpu_update_guest_xfd().<br /> <br /> and if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:exc_device_not_available+0x101/0x110<br /> Call Trace:<br /> <br /> asm_exc_device_not_available+0x1a/0x20<br /> RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90<br /> fpu_swap_kvm_fpstate+0x6b/0x120<br /> kvm_load_guest_fpu+0x30/0x80 [kvm]<br /> kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm]<br /> kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]<br /> __x64_sys_ioctl+0x8f/0xd0<br /> do_syscall_64+0x62/0x940<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The new behavior is consistent with the AMX architecture. Per Intel&amp;#39;s SDM,<br /> XSAVE saves XSTATE_BV as &amp;#39;0&amp;#39; for components that are disabled via XFD<br /> (and non-compacted XSAVE saves the initial configuration of the state<br /> component):<br /> <br /> If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i,<br /> the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1;<br /> instead, it operates as if XINUSE[i] = 0 (and the state component was<br /> in its initial state): it saves bit i of XSTATE_BV field of the XSAVE<br /> header as 0; in addition, XSAVE saves the initial configuration of the<br /> state component (the other instructions do not save state component i).<br /> <br /> Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using<br /> a constant XFD based on the set of enabled features when XSAVEing for<br /> a struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled<br /> features can only happen in the above interrupt case, or in similar<br /> scenarios involving preemption on preemptible kernels, because<br /> fpu_swap_kvm_fpstate()&amp;#39;s call to save_fpregs_to_fpstate() saves the<br /> outgoing FPU state with the current XFD; and that is (on all but the<br /> first WRMSR to XFD) the guest XFD.<br /> <br /> Therefore, XFD can only go out of sync with XSTATE_BV in the above<br /> interrupt case, or in similar scenarios involving preemption on<br /> preemptible kernels, and it we can consider it (de facto) part of KVM<br /> ABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.<br /> <br /> [Move clea<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: tlv320adcx140: fix null pointer<br /> <br /> The "snd_soc_component" in "adcx140_priv" was only used once but never<br /> set. It was only used for reaching "dev" which is already present in<br /> "adcx140_priv".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix use-after-free in inet6_addr_del().<br /> <br /> syzbot reported use-after-free of inet6_ifaddr in<br /> inet6_addr_del(). [0]<br /> <br /> The cited commit accidentally moved ipv6_del_addr() for<br /> mngtmpaddr before reading its ifp-&gt;flags for temporary<br /> addresses in inet6_addr_del().<br /> <br /> Let&amp;#39;s move ipv6_del_addr() down to fix the UAF.<br /> <br /> [0]:<br /> BUG: KASAN: slab-use-after-free in inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117<br /> Read of size 4 at addr ffff88807b89c86c by task syz.3.1618/9593<br /> <br /> CPU: 0 UID: 0 PID: 9593 Comm: syz.3.1618 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xcd/0x630 mm/kasan/report.c:482<br /> kasan_report+0xe0/0x110 mm/kasan/report.c:595<br /> inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117<br /> addrconf_del_ifaddr+0x11e/0x190 net/ipv6/addrconf.c:3181<br /> inet6_ioctl+0x1e5/0x2b0 net/ipv6/af_inet6.c:582<br /> sock_do_ioctl+0x118/0x280 net/socket.c:1254<br /> sock_ioctl+0x227/0x6b0 net/socket.c:1375<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl fs/ioctl.c:583 [inline]<br /> __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f164cf8f749<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f164de64038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007f164d1e5fa0 RCX: 00007f164cf8f749<br /> RDX: 0000200000000000 RSI: 0000000000008936 RDI: 0000000000000003<br /> RBP: 00007f164d013f91 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f164d1e6038 R14: 00007f164d1e5fa0 R15: 00007ffde15c8288<br /> <br /> <br /> Allocated by task 9593:<br /> kasan_save_stack+0x33/0x60 mm/kasan/common.c:56<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:77<br /> poison_kmalloc_redzone mm/kasan/common.c:397 [inline]<br /> __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:414<br /> kmalloc_noprof include/linux/slab.h:957 [inline]<br /> kzalloc_noprof include/linux/slab.h:1094 [inline]<br /> ipv6_add_addr+0x4e3/0x2010 net/ipv6/addrconf.c:1120<br /> inet6_addr_add+0x256/0x9b0 net/ipv6/addrconf.c:3050<br /> addrconf_add_ifaddr+0x1fc/0x450 net/ipv6/addrconf.c:3160<br /> inet6_ioctl+0x103/0x2b0 net/ipv6/af_inet6.c:580<br /> sock_do_ioctl+0x118/0x280 net/socket.c:1254<br /> sock_ioctl+0x227/0x6b0 net/socket.c:1375<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl fs/ioctl.c:583 [inline]<br /> __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 6099:<br /> kasan_save_stack+0x33/0x60 mm/kasan/common.c:56<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:77<br /> kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584<br /> poison_slab_object mm/kasan/common.c:252 [inline]<br /> __kasan_slab_free+0x5f/0x80 mm/kasan/common.c:284<br /> kasan_slab_free include/linux/kasan.h:234 [inline]<br /> slab_free_hook mm/slub.c:2540 [inline]<br /> slab_free_freelist_hook mm/slub.c:2569 [inline]<br /> slab_free_bulk mm/slub.c:6696 [inline]<br /> kmem_cache_free_bulk mm/slub.c:7383 [inline]<br /> kmem_cache_free_bulk+0x2bf/0x680 mm/slub.c:7362<br /> kfree_bulk include/linux/slab.h:830 [inline]<br /> kvfree_rcu_bulk+0x1b7/0x1e0 mm/slab_common.c:1523<br /> kvfree_rcu_drain_ready mm/slab_common.c:1728 [inline]<br /> kfree_rcu_monitor+0x1d0/0x2f0 mm/slab_common.c:1801<br /> process_one_work+0x9ba/0x1b20 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqu<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: ip_gre: make ipgre_header() robust<br /> <br /> Analog to commit db5b4e39c4e6 ("ip6_gre: make ip6gre_header() robust")<br /> <br /> Over the years, syzbot found many ways to crash the kernel<br /> in ipgre_header() [1].<br /> <br /> This involves team or bonding drivers ability to dynamically<br /> change their dev-&gt;needed_headroom and/or dev-&gt;hard_header_len<br /> <br /> In this particular crash mld_newpack() allocated an skb<br /> with a too small reserve/headroom, and by the time mld_sendpack()<br /> was called, syzbot managed to attach an ipgre device.<br /> <br /> [1]<br /> skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0<br /> kernel BUG at net/core/skbuff.c:213 !<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN PTI<br /> CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> Workqueue: mld mld_ifc_work<br /> RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213<br /> Call Trace:<br /> <br /> skb_under_panic net/core/skbuff.c:223 [inline]<br /> skb_push+0xc3/0xe0 net/core/skbuff.c:2641<br /> ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897<br /> dev_hard_header include/linux/netdevice.h:3436 [inline]<br /> neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618<br /> NF_HOOK_COND include/linux/netfilter.h:307 [inline]<br /> ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247<br /> NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318<br /> mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855<br /> mld_send_cr net/ipv6/mcast.c:2154 [inline]<br /> mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693<br /> process_one_work kernel/workqueue.c:3257 [inline]<br /> process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340<br /> worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421<br /> kthread+0x711/0x8a0 kernel/kthread.c:463<br /> ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Don&amp;#39;t store mlx5e_priv in mlx5e_dev devlink priv<br /> <br /> mlx5e_priv is an unstable structure that can be memset(0) if profile<br /> attaching fails, mlx5e_priv in mlx5e_dev devlink private is used to<br /> reference the netdev and mdev associated with that struct. Instead,<br /> store netdev directly into mlx5e_dev and get mdev from the containing<br /> mlx5_adev aux device structure.<br /> <br /> This fixes a kernel oops in mlx5e_remove when switchdev mode fails due<br /> to change profile failure.<br /> <br /> $ devlink dev eswitch set pci/0000:00:03.0 mode switchdev<br /> Error: mlx5_core: Failed setting eswitch to offloads.<br /> dmesg:<br /> workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12<br /> mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12<br /> workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12<br /> mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12<br /> <br /> $ devlink dev reload pci/0000:00:03.0 ==&gt; oops<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000520<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 NOPTI<br /> CPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:mlx5e_remove+0x68/0x130<br /> RSP: 0018:ffffc900034838f0 EFLAGS: 00010246<br /> RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45<br /> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000<br /> RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10<br /> R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0<br /> R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400<br /> FS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0<br /> Call Trace:<br /> <br /> device_release_driver_internal+0x19c/0x200<br /> bus_remove_device+0xc6/0x130<br /> device_del+0x160/0x3d0<br /> ? devl_param_driverinit_value_get+0x2d/0x90<br /> mlx5_detach_device+0x89/0xe0<br /> mlx5_unload_one_devl_locked+0x3a/0x70<br /> mlx5_devlink_reload_down+0xc8/0x220<br /> devlink_reload+0x7d/0x260<br /> devlink_nl_reload_doit+0x45b/0x5a0<br /> genl_family_rcv_msg_doit+0xe8/0x140

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix crash on profile change rollback failure<br /> <br /> mlx5e_netdev_change_profile can fail to attach a new profile and can<br /> fail to rollback to old profile, in such case, we could end up with a<br /> dangling netdev with a fully reset netdev_priv. A retry to change<br /> profile, e.g. another attempt to call mlx5e_netdev_change_profile via<br /> switchdev mode change, will crash trying to access the now NULL<br /> priv-&gt;mdev.<br /> <br /> This fix allows mlx5e_netdev_change_profile() to handle previous<br /> failures and an empty priv, by not assuming priv is valid.<br /> <br /> Pass netdev and mdev to all flows requiring<br /> mlx5e_netdev_change_profile() and avoid passing priv.<br /> In mlx5e_netdev_change_profile() check if current priv is valid, and if<br /> not, just attach the new profile without trying to access the old one.<br /> <br /> This fixes the following oops, when enabling switchdev mode for the 2nd<br /> time after first time failure:<br /> <br /> ## Enabling switchdev mode first time:<br /> <br /> mlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offload<br /> workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12<br /> mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12<br /> workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12<br /> mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12<br /> ^^^^^^^^<br /> mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)<br /> <br /> ## retry: Enabling switchdev mode 2nd time:<br /> <br /> mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload<br /> BUG: kernel NULL pointer dereference, address: 0000000000000038<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 NOPTI<br /> CPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:mlx5e_detach_netdev+0x3c/0x90<br /> Code: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07<br /> RSP: 0018:ffffc90000673890 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000<br /> RDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000<br /> R10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000<br /> R13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000<br /> FS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0<br /> Call Trace:<br /> <br /> mlx5e_netdev_change_profile+0x45/0xb0<br /> mlx5e_vport_rep_load+0x27b/0x2d0<br /> mlx5_esw_offloads_rep_load+0x72/0xf0<br /> esw_offloads_enable+0x5d0/0x970<br /> mlx5_eswitch_enable_locked+0x349/0x430<br /> ? is_mp_supported+0x57/0xb0<br /> mlx5_devlink_eswitch_mode_set+0x26b/0x430<br /> devlink_nl_eswitch_set_doit+0x6f/0xf0<br /> genl_family_rcv_msg_doit+0xe8/0x140<br /> genl_rcv_msg+0x18b/0x290<br /> ? __pfx_devlink_nl_pre_doit+0x10/0x10<br /> ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10<br /> ? __pfx_devlink_nl_post_doit+0x10/0x10<br /> ? __pfx_genl_rcv_msg+0x10/0x10<br /> netlink_rcv_skb+0x52/0x100<br /> genl_rcv+0x28/0x40<br /> netlink_unicast+0x282/0x3e0<br /> ? __alloc_skb+0xd6/0x190<br /> netlink_sendmsg+0x1f7/0x430<br /> __sys_sendto+0x213/0x220<br /> ? __sys_recvmsg+0x6a/0xd0<br /> __x64_sys_sendto+0x24/0x30<br /> do_syscall_64+0x50/0x1f0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fdfb8495047

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: fix device leaks on compat bind and unbind<br /> <br /> Make sure to drop the reference taken when looking up the idxd device as<br /> part of the compat bind and unbind sysfs interface.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts<br /> <br /> Since j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() is<br /> called only when the timer is enabled, we need to call<br /> j1939_session_deactivate_activate_next() if we cancelled the timer.<br /> Otherwise, refcount for j1939_session leaks, which will later appear as<br /> <br /> | unregister_netdevice: waiting for vcan0 to become free. Usage count = 2.<br /> <br /> problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec<br /> <br /> Commit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length")<br /> added ttag bounds checking and data_offset<br /> validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate<br /> whether the command&amp;#39;s data structures (cmd-&gt;req.sg and cmd-&gt;iov) have<br /> been properly initialized before processing H2C_DATA PDUs.<br /> <br /> The nvmet_tcp_build_pdu_iovec() function dereferences these pointers<br /> without NULL checks. This can be triggered by sending H2C_DATA PDU<br /> immediately after the ICREQ/ICRESP handshake, before<br /> sending a CONNECT command or NVMe write command.<br /> <br /> Attack vectors that trigger NULL pointer dereferences:<br /> 1. H2C_DATA PDU sent before CONNECT → both pointers NULL<br /> 2. H2C_DATA PDU for READ command → cmd-&gt;req.sg allocated, cmd-&gt;iov NULL<br /> 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL<br /> <br /> The fix validates both cmd-&gt;req.sg and cmd-&gt;iov before calling<br /> nvmet_tcp_build_pdu_iovec(). Both checks are required because:<br /> - Uninitialized commands: both NULL<br /> - READ commands: cmd-&gt;req.sg allocated, cmd-&gt;iov NULL<br /> - WRITE commands: both allocated