Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bloque: poner a cero la porción no-PI del búfer de integridad automático<br /> <br /> El búfer de integridad autogenerado para escrituras necesita ser completamente inicializado antes de ser pasado al dispositivo de bloque subyacente, de lo contrario la memoria no inicializada puede ser leída por el espacio de usuario o cualquier persona con acceso físico al dispositivo de almacenamiento. Si se genera información de protección, esa porción del búfer de integridad ya está inicializada. Los datos de integridad también se ponen a cero si la generación de PI está deshabilitada a través de sysfs o el tamaño de la tupla PI es 0. Sin embargo, esto omite el caso en que se genera PI y el tamaño de la tupla PI no es cero, pero el tamaño de los metadatos es mayor que la tupla PI. En este caso, el resto (&amp;#39;opaco&amp;#39;) de los metadatos se deja sin inicializar.<br /> Generalizar la comprobación BLK_INTEGRITY_CSUM_NONE para cubrir cualquier caso en que los metadatos sean más grandes que solo la tupla PI.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/vmwgfx: Corregir KMS con 3D en la versión de HW 10<br /> <br /> La versión de HW 10 no tiene GB Surfaces por lo que no hay un búfer de respaldo para FBs respaldados por superficie. Esto resultaría en una desreferencia de puntero nulo y colapsaría el controlador causando una pantalla negra.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> xhci: banda lateral: no desreferenciar el anillo liberado al eliminar el punto final de banda lateral<br /> <br /> xhci_sideband_remove_endpoint() asume incorrectamente que el punto final está en ejecución y tiene un anillo de transferencia válido.<br /> <br /> Lianqin informó de un fallo durante las pruebas de estrés de suspensión/activación, y encontró que la causa era la desreferenciación de un anillo de transferencia inexistente &amp;#39;ep-&amp;gt;ring&amp;#39; durante xhci_sideband_remove_endpoint().<br /> <br /> El punto final y su anillo pueden estar en un estado desconocido si esta función se llama después de que xHCI fuera reinicializado en la reanudación (pérdida de energía), o si el dispositivo está siendo reenumerado, desconectado o el punto final ya ha sido descartado.<br /> <br /> Solucione esto eliminando el acceso innecesario al anillo y comprobando que &amp;#39;ep-&amp;gt;ring&amp;#39; existe antes de desreferenciarlo. También asegúrese de que el punto final esté en ejecución antes de intentar detenerlo.<br /> <br /> Elimine la llamada a xhci_initialize_ring_info() durante la eliminación del punto final de banda lateral, ya que solo inicializa los valores de estado de encolamiento, desencolamiento y ciclo de la estructura del anillo a sus valores iniciales sin cambiar el estado real de encolamiento, desencolamiento y ciclo del hardware. Dejarlos fuera de sincronización es peor que dejarlo como está. El punto final será liberado después de esto en la mayoría de los casos de uso.<br /> <br /> Si el controlador de clase (de audio) desea reutilizar el punto final después de la descarga, entonces es responsabilidad del controlador de clase asegurar que el punto final esté configurado correctamente.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ip6_tunnel: usar skb_vlan_inet_prepare() en __ip6_tnl_rcv()<br /> <br /> El commit culpable no tuvo en cuenta las encapsulaciones VLAN como fue detectado por syzbot [1].<br /> <br /> Usar skb_vlan_inet_prepare() en lugar de pskb_inet_may_pull().<br /> <br /> [1]<br /> ERROR: KMSAN: valor no inicializado en __INET_ECN_decapsulate include/net/inet_ecn.h:253 [en línea]<br /> ERROR: KMSAN: valor no inicializado en INET_ECN_decapsulate include/net/inet_ecn.h:275 [en línea]<br /> ERROR: KMSAN: valor no inicializado en IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321<br /> __INET_ECN_decapsulate include/net/inet_ecn.h:253 [en línea]<br /> INET_ECN_decapsulate include/net/inet_ecn.h:275 [en línea]<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 [en línea]<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 [en línea]<br /> ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79<br /> NF_HOOK include/linux/netfilter.h:318 [en línea]<br /> ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311<br /> __netif_receive_skb_one_core net/core/dev.c:6139 [en línea]<br /> __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252<br /> netif_receive_skb_internal net/core/dev.c:6338 [en línea]<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 [en línea]<br /> vfs_write+0xbe2/0x15d0 fs/read_write.c:686<br /> ksys_write fs/read_write.c:738 [en línea]<br /> __do_sys_write fs/read_write.c:749 [en línea]<br /> __se_sys_write fs/read_write.c:746 [en línea]<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 [en línea]<br /> do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> El valor no inicializado fue creado en:<br /> slab_post_alloc_hook mm/slub.c:4960 [en línea]<br /> slab_alloc_node mm/slub.c:5263 [en línea]<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 [en línea]<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 [en línea]<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 [en línea]<br /> vfs_write+0xbe2/0x15d0 fs/read_write.c:686<br /> ksys_write fs/read_write.c:738 [en línea]<br /> __do_sys_write fs/read_write.c:749 [en línea]<br /> __se_sys_write fs/read_write.c:746 [en línea]<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 [en línea]<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 No contaminado syzkaller #0 PREEMPT(none)<br /> Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/10/2025

*** Pendiente de traducción *** 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---

*** Pendiente de traducción *** 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---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ipv4: ip_gre: hacer ipgre_header() robusto<br /> <br /> Análogo al commit db5b4e39c4e6 (&amp;#39;ip6_gre: hacer ip6gre_header() robusto&amp;#39;)<br /> <br /> A lo largo de los años, syzbot encontró muchas maneras de colapsar el kernel en ipgre_header() [1].<br /> <br /> Esto implica la capacidad de los controladores de equipo o de enlace (bonding drivers) de cambiar dinámicamente su dev-&amp;gt;needed_headroom y/o dev-&amp;gt;hard_header_len<br /> <br /> En este colapso particular, mld_newpack() asignó un skb con una reserva/espacio de cabecera (headroom) demasiado pequeño, y para cuando se llamó a mld_sendpack(), syzbot logró adjuntar un dispositivo ipgre.<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

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/mlx5e: No almacenar mlx5e_priv en mlx5e_dev devlink priv<br /> <br /> mlx5e_priv es una estructura inestable que puede ser memset(0) si falla la conexión del perfil. mlx5e_priv en mlx5e_dev devlink private se utiliza para referenciar el netdev y mdev asociados con esa estructura. En su lugar, almacenar netdev directamente en mlx5e_dev y obtener mdev de la estructura del dispositivo auxiliar mlx5_adev que lo contiene.<br /> <br /> Esto corrige un kernel oops en mlx5e_remove cuando el modo switchdev falla debido a un fallo en el cambio de perfil.<br /> <br /> $ devlink dev eswitch set pci/0000:00:03.0 mode switchdev<br /> Error: mlx5_core: Falló al establecer eswitch en offloads.<br /> dmesg:<br /> workqueue: Falló al crear un kthread de rescate para 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: Falló al crear un kthread de rescate para 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 ==&amp;gt; oops<br /> <br /> BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000520<br /> #PF: acceso de lectura de supervisor en modo kernel<br /> #PF: error_code(0x0000) - página no presente<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 /> Nombre del hardware: 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 /> Rastro de Llamada:<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

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: can: j1939: j1939_xtp_rx_rts_session_active(): desactivar sesión al recibir el segundo rts<br /> <br /> Dado que j1939_session_deactivate_activate_next() en j1939_tp_rxtimer() se<br /> llama solo cuando el temporizador está habilitado, necesitamos llamar a<br /> j1939_session_deactivate_activate_next() si cancelamos el temporizador.<br /> De lo contrario, la cuenta de referencias (refcount) para j1939_session se fuga, lo que más tarde aparecerá como<br /> <br /> | unregister_netdevice: esperando que vcan0 quede libre. Recuento de uso = 2.<br /> <br /> problema.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nvme-tcp: soluciona desreferencias de puntero NULL en nvmet_tcp_build_pdu_iovec<br /> <br /> El commit efa56305908b (&amp;#39;nvmet-tcp: Soluciona un pánico del kernel cuando el host envía una longitud de PDU H2C inválida&amp;#39;) añadió la comprobación de límites de ttag y la validación de data_offset en nvmet_tcp_handle_h2c_data_pdu(), pero no validó si las estructuras de datos del comando (cmd-&amp;gt;req.sg y cmd-&amp;gt;iov) han sido inicializadas correctamente antes de procesar las PDUs H2C_DATA.<br /> <br /> La función nvmet_tcp_build_pdu_iovec() desreferencia estos punteros sin comprobaciones de NULL. Esto puede ser provocado enviando una PDU H2C_DATA inmediatamente después del handshake ICREQ/ICRESP, antes de enviar un comando CONNECT o un comando de escritura NVMe.<br /> <br /> Vectores de ataque que provocan desreferencias de puntero NULL:<br /> 1. PDU H2C_DATA enviada antes de CONNECT ? ambos punteros NULL<br /> 2. PDU H2C_DATA para comando READ ? cmd-&amp;gt;req.sg asignado, cmd-&amp;gt;iov NULL<br /> 3. PDU H2C_DATA para slot de comando no inicializado ? ambos punteros NULL<br /> <br /> La solución valida tanto cmd-&amp;gt;req.sg como cmd-&amp;gt;iov antes de llamar a nvmet_tcp_build_pdu_iovec(). Ambas comprobaciones son necesarias porque:<br /> - Comandos no inicializados: ambos NULL<br /> - Comandos READ: cmd-&amp;gt;req.sg asignado, cmd-&amp;gt;iov NULL<br /> - Comandos WRITE: ambos asignados

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: sch_qfq: no liberar la clase existente en qfq_change_class()<br /> <br /> Corrige el caso de error de qfq_change_class().<br /> <br /> cl-&amp;gt;qdisc y cl solo deben liberarse si se asignaron una nueva clase y qdisc, o nos arriesgamos a varios UAF.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: net/mlx5e: Soluciona el fallo en el fallo de reversión del cambio de perfil mlx5e_netdev_change_profile puede fallar al adjuntar un nuevo perfil y puede fallar al revertir al perfil antiguo; en tal caso, podríamos terminar con un netdev colgante con un netdev_priv completamente reiniciado. Un reintento de cambiar el perfil, p. ej., otro intento de llamar a mlx5e_netdev_change_profile a través del cambio de modo switchdev, fallará al intentar acceder al ahora NULL priv-&amp;gt;mdev. Esta solución permite a mlx5e_netdev_change_profile() manejar fallos anteriores y un priv vacío, al no asumir que priv es válido. Pase netdev y mdev a todos los flujos que requieran mlx5e_netdev_change_profile() y evite pasar priv. En mlx5e_netdev_change_profile() verifique si el priv actual es válido, y si no lo es, simplemente adjunte el nuevo perfil sin intentar acceder al antiguo. Esto soluciona el siguiente oops, al habilitar el modo switchdev por segunda vez después del primer fallo: ## Habilitando el modo switchdev por primera vez: mlx5_core 0012:03:00.1: E-Switch: Descarga de cadenas tc y prios soportadas workqueue: Fallo al crear un kthread de rescate para wq &amp;#39;mlx5e&amp;#39;: -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init falló, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: la inicialización del nuevo perfil falló, -12 workqueue: Fallo al crear un kthread de rescate para wq &amp;#39;mlx5e&amp;#39;: -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init falló, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: falló al revertir al perfil original, -12 ^^^^^^^^ mlx5_core 0000:00:03.0: E-Switch: Deshabilitar: modo(LEGACY), nvfs(0), necvfs(0), vports activos(0) ## reintento: Habilitando el modo switchdev por segunda vez: mlx5_core 0000:00:03.0: E-Switch: Descarga de cadenas tc y prios soportadas BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000038 #PF: acceso de lectura de supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_detach_netdev+0x3c/0x90 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 &amp;lt;48&amp;gt; 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07 RSP: 0018:ffffc90000673890 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000 RDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000 R10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000 FS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0 Traza de Llamada: mlx5e_netdev_change_profile+0x45/0xb0 mlx5e_vport_rep_load+0x27b/0x2d0 mlx5_esw_offloads_rep_load+0x72/0xf0 esw_offloads_enable+0x5d0/0x970 mlx5_eswitch_enable_locked+0x349/0x430 ? is_mp_supported+0x57/0xb0 mlx5_devlink_eswitch_mode_set+0x26b/0x430 devlink_nl_eswitch_set_doit+0x6f/0xf0 genl_family_rcv_msg_doit+0xe8/0x140 genl_rcv_msg+0x18b/0x290 ? __pfx_devlink_nl_pre_doit+0x10/0x10 ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10 ? __pfx_devlink_nl_post_doit+0x10/0x10 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x52/0x100 genl_rcv+0x28/0x40 netlink_unicast+0x282/0x3e0 ? __alloc_skb+0xd6/0x190 netlink_sendmsg+0x1f7/0x430 __sys_sendto+0x213/0x220 ? __sys_recvmsg+0x6a/0xd0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e