Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: octeon_ep_vf: corregir la falta de coincidencia de dev_id de free_irq en la reversión de IRQ<br /> <br /> octep_vf_request_irqs() solicita IRQs de cola MSI-X con dev_id establecido en ioq_vector. Si request_irq() falla a mitad de camino, el bucle de reversión llama a free_irq() con dev_id establecido en &amp;#39;oct&amp;#39;, lo que no coincide con el dev_id original y puede dejar la irqaction registrada.<br /> <br /> Esto puede mantener los manejadores de IRQ activos mientras ioq_vector es liberado posteriormente durante el desenrollado/desmontaje, lo que lleva a un uso después de liberación o un fallo cuando se dispara una interrupción.<br /> <br /> Corregir la ruta de error para liberar IRQs con el mismo dev_id de ioq_vector utilizado durante request_irq().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mm/damon/core: eliminar call_control en contextos inactivos<br /> <br /> Si damon_call() se ejecuta contra un contexto DAMON que no está en ejecución, la función devuelve un error mientras mantiene el objeto damon_call_control vinculado a la lista call_controls del contexto. Supongamos que el objeto es desasignado después de damon_call(), y se ejecuta otro damon_call() contra el mismo contexto. La función intenta añadir el nuevo objeto damon_call_control a la lista call_controls, que todavía tiene el puntero al objeto damon_call_control anterior, que está desasignado. Como resultado, ocurre un uso después de liberación.<br /> <br /> Esto puede ser realmente activado usando la interfaz sysfs de DAMON. Sin embargo, no es fácilmente explotable ya que requiere el permiso de escritura de sysfs y realizar escrituras de archivo definitivamente extrañas. Por favor, consulte el informe para más detalles sobre los pasos de reproducción del problema.<br /> <br /> Solucione el problema realizando dos cambios. En primer lugar, mueva la kdamond_call() final para cancelar todas las solicitudes damon_call() existentes del contexto DAMON que termina, para que se realice antes del reinicio de ctx-&amp;gt;kdamond. Esto hace que cualquier código que vea NULL en ctx-&amp;gt;kdamond pueda asumir con seguridad que el contexto ya no puede acceder a las solicitudes damon_call(). En segundo lugar, permita que damon_call() limpie los objetos damon_call_control que fueron añadidos al contexto DAMON ya terminado, antes de devolver el error.

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 /> ASoC: tlv320adcx140: corrección de puntero nulo<br /> <br /> El &amp;#39;snd_soc_component&amp;#39; en &amp;#39;adcx140_priv&amp;#39; solo se usó una vez pero nunca se configuró. Solo se usó para alcanzar &amp;#39;dev&amp;#39;, que ya está presente en &amp;#39;adcx140_priv&amp;#39;.

*** 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---

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

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> lib/buildid: usar __kernel_read() para contexto &amp;#39;sleepable&amp;#39;<br /> <br /> Prevenir un &amp;#39;BUG: unable to handle kernel NULL pointer dereference in filemap_read_folio&amp;#39;.<br /> <br /> Para el contexto &amp;#39;sleepable&amp;#39;, convertir freader para usar __kernel_read() en lugar del acceso directo a la caché de páginas a través de read_cache_folio(). Esto simplifica la ruta de código &amp;#39;faultable&amp;#39; al usar la interfaz estándar de lectura de archivos del kernel que maneja toda la complejidad de la lectura de datos de archivos.<br /> <br /> Por el momento no estamos cambiando el código para el contexto &amp;#39;non-sleepable&amp;#39; que usa filemap_get_folio() y solo tiene éxito si los folios objetivo ya están en memoria y actualizados. La razón es mantener el parche simple y más fácil de &amp;#39;backportear&amp;#39; a kernels estables.<br /> <br /> La reproducción de Syzbot ya no bloquea el kernel y las pruebas automáticas se ejecutan con éxito.<br /> <br /> En el seguimiento haremos que __kernel_read() con IOCB_NOWAIT funcione para contextos &amp;#39;non-sleepable&amp;#39;. Además, me gustaría reemplazar la verificación de secretmem con un enfoque más genérico y añadiré fstest para el código buildid.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dst: fix races in rt6_uncached_list_del() and rt_del_uncached_list()<br /> <br /> syzbot was able to crash the kernel in rt6_uncached_list_flush_dev()<br /> in an interesting way [1]<br /> <br /> Crash happens in list_del_init()/INIT_LIST_HEAD() while writing<br /> list-&gt;prev, while the prior write on list-&gt;next went well.<br /> <br /> static inline void INIT_LIST_HEAD(struct list_head *list)<br /> {<br /> WRITE_ONCE(list-&gt;next, list); // This went well<br /> WRITE_ONCE(list-&gt;prev, list); // Crash, @list has been freed.<br /> }<br /> <br /> Issue here is that rt6_uncached_list_del() did not attempt to lock<br /> ul-&gt;lock, as list_empty(&amp;rt-&gt;dst.rt_uncached) returned<br /> true because the WRITE_ONCE(list-&gt;next, list) happened on the other CPU.<br /> <br /> We might use list_del_init_careful() and list_empty_careful(),<br /> or make sure rt6_uncached_list_del() always grabs the spinlock<br /> whenever rt-&gt;dst.rt_uncached_list has been set.<br /> <br /> A similar fix is neeed for IPv4.<br /> <br /> [1]<br /> <br /> BUG: KASAN: slab-use-after-free in INIT_LIST_HEAD include/linux/list.h:46 [inline]<br /> BUG: KASAN: slab-use-after-free in list_del_init include/linux/list.h:296 [inline]<br /> BUG: KASAN: slab-use-after-free in rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline]<br /> BUG: KASAN: slab-use-after-free in rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020<br /> Write of size 8 at addr ffff8880294cfa78 by task kworker/u8:14/3450<br /> <br /> CPU: 0 UID: 0 PID: 3450 Comm: kworker/u8:14 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)}<br /> Tainted: [L]=SOFTLOCKUP<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> Workqueue: netns cleanup_net<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xca/0x240 mm/kasan/report.c:482<br /> kasan_report+0x118/0x150 mm/kasan/report.c:595<br /> INIT_LIST_HEAD include/linux/list.h:46 [inline]<br /> list_del_init include/linux/list.h:296 [inline]<br /> rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline]<br /> rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020<br /> addrconf_ifdown+0x143/0x18a0 net/ipv6/addrconf.c:3853<br /> addrconf_notify+0x1bc/0x1050 net/ipv6/addrconf.c:-1<br /> notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85<br /> call_netdevice_notifiers_extack net/core/dev.c:2268 [inline]<br /> call_netdevice_notifiers net/core/dev.c:2282 [inline]<br /> netif_close_many+0x29c/0x410 net/core/dev.c:1785<br /> unregister_netdevice_many_notify+0xb50/0x2330 net/core/dev.c:12353<br /> ops_exit_rtnl_list net/core/net_namespace.c:187 [inline]<br /> ops_undo_list+0x3dc/0x990 net/core/net_namespace.c:248<br /> cleanup_net+0x4de/0x7b0 net/core/net_namespace.c:696<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<br /> <br /> <br /> Allocated by task 803:<br /> kasan_save_stack mm/kasan/common.c:57 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:78<br /> unpoison_slab_object mm/kasan/common.c:340 [inline]<br /> __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366<br /> kasan_slab_alloc include/linux/kasan.h:253 [inline]<br /> slab_post_alloc_hook mm/slub.c:4953 [inline]<br /> slab_alloc_node mm/slub.c:5263 [inline]<br /> kmem_cache_alloc_noprof+0x18d/0x6c0 mm/slub.c:5270<br /> dst_alloc+0x105/0x170 net/core/dst.c:89<br /> ip6_dst_alloc net/ipv6/route.c:342 [inline]<br /> icmp6_dst_alloc+0x75/0x460 net/ipv6/route.c:3333<br /> mld_sendpack+0x683/0xe60 net/ipv6/mcast.c:1844<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/entr<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

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