Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: remove call_control in inactive contexts<br /> <br /> If damon_call() is executed against a DAMON context that is not running,<br /> the function returns error while keeping the damon_call_control object<br /> linked to the context&amp;#39;s call_controls list. Let&amp;#39;s suppose the object is<br /> deallocated after the damon_call(), and yet another damon_call() is<br /> executed against the same context. The function tries to add the new<br /> damon_call_control object to the call_controls list, which still has the<br /> pointer to the previous damon_call_control object, which is deallocated. <br /> As a result, use-after-free happens.<br /> <br /> This can actually be triggered using the DAMON sysfs interface. It is not<br /> easily exploitable since it requires the sysfs write permission and making<br /> a definitely weird file writes, though. Please refer to the report for<br /> more details about the issue reproduction steps.<br /> <br /> Fix the issue by making two changes. Firstly, move the final<br /> kdamond_call() for cancelling all existing damon_call() requests from<br /> terminating DAMON context to be done before the ctx-&gt;kdamond reset. This<br /> makes any code that sees NULL ctx-&gt;kdamond can safely assume the context<br /> may not access damon_call() requests anymore. Secondly, let damon_call()<br /> to cleanup the damon_call_control objects that were added to the<br /> already-terminated DAMON context, before returning the error.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: octeon_ep_vf: fix free_irq dev_id mismatch in IRQ rollback<br /> <br /> octep_vf_request_irqs() requests MSI-X queue IRQs with dev_id set to<br /> ioq_vector. If request_irq() fails part-way, the rollback loop calls<br /> free_irq() with dev_id set to &amp;#39;oct&amp;#39;, which does not match the original<br /> dev_id and may leave the irqaction registered.<br /> <br /> This can keep IRQ handlers alive while ioq_vector is later freed during<br /> unwind/teardown, leading to a use-after-free or crash when an interrupt<br /> fires.<br /> <br /> Fix the error path to free IRQs with the same ioq_vector dev_id used<br /> during request_irq().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/buildid: use __kernel_read() for sleepable context<br /> <br /> Prevent a "BUG: unable to handle kernel NULL pointer dereference in<br /> filemap_read_folio".<br /> <br /> For the sleepable context, convert freader to use __kernel_read() instead<br /> of direct page cache access via read_cache_folio(). This simplifies the<br /> faultable code path by using the standard kernel file reading interface<br /> which handles all the complexity of reading file data.<br /> <br /> At the moment we are not changing the code for non-sleepable context which<br /> uses filemap_get_folio() and only succeeds if the target folios are<br /> already in memory and up-to-date. The reason is to keep the patch simple<br /> and easier to backport to stable kernels.<br /> <br /> Syzbot repro does not crash the kernel anymore and the selftests run<br /> successfully.<br /> <br /> In the follow up we will make __kernel_read() with IOCB_NOWAIT work for<br /> non-sleepable contexts. In addition, I would like to replace the<br /> secretmem check with a more generic approach and will add fstest for the<br /> buildid code.

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

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

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: zero non-PI portion of auto integrity buffer<br /> <br /> The auto-generated integrity buffer for writes needs to be fully<br /> initialized before being passed to the underlying block device,<br /> otherwise the uninitialized memory can be read back by userspace or<br /> anyone with physical access to the storage device. If protection<br /> information is generated, that portion of the integrity buffer is<br /> already initialized. The integrity data is also zeroed if PI generation<br /> is disabled via sysfs or the PI tuple size is 0. However, this misses<br /> the case where PI is generated and the PI tuple size is nonzero, but the<br /> metadata size is larger than the PI tuple. In this case, the remainder<br /> ("opaque") of the metadata is left uninitialized.<br /> Generalize the BLK_INTEGRITY_CSUM_NONE check to cover any case when the<br /> metadata is larger than just the PI tuple.

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

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

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

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