Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/hns: Se corrige la doble destrucción de rsv_qp. rsv_qp puede sufrir una doble destrucción en el flujo de errores, primero en free_mr_init() y luego en hns_roce_exit(). Se corrige trasladando la llamada a free_mr_init() a hns_roce_v2_init(). Corrupción de list_del, ffff589732eb9b50->el siguiente es LIST_POISON1 (dead000000000100) ADVERTENCIA: CPU: 8 PID: 1047115 en lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240 ... Rastreo de llamadas: __list_del_entry_valid+0x148/0x240 hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2] hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2] hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2] free_mr_exit+0x6c/0x120 [hns_roce_hw_v2] hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2] hns_roce_exit+0x118/0x350 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2] hclge_notify_roce_client+0x6c/0x160 [hclge] hclge_reset_rebuild+0x150/0x5c0 [hclge] hclge_reset+0x10c/0x140 [hclge] hclge_reset_subtask+0x80/0x104 [hclge] hclge_reset_service_task+0x168/0x3ac [hclge] hclge_service_task+0x50/0x100 [hclge] process_one_work+0x250/0x9a0 worker_thread+0x324/0x990 kthread+0x190/0x210 ret_from_fork+0x10/0x18

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: se corrige el uso de inodo use after free en ext4_end_io_rsv_work() En ext4_io_end_defer_completion(), se comprueba si io_end->list_vec está vacío para evitar añadir un io_end que no requiere conversión a i_rsv_conversion_list, lo que a su vez impide iniciar un trabajador innecesario. También se añade una comprobación ext4_emergency_state() para evitar intentar abortar el diario en un estado de emergencia. Además, ext4_put_io_end_defer() se refactoriza para llamar a ext4_io_end_defer_completion() directamente en lugar de estar en código abierto. Esto también impide iniciar un trabajador innecesario cuando EXT4_IO_END_FAILED está configurado pero data_err=abort no está habilitado. Esto garantiza que la comprobación en ext4_put_io_end_defer() sea coherente con la comprobación en ext4_end_bio(). De lo contrario, podríamos agregar un io_end a i_rsv_conversion_list y luego llamar a ext4_finish_bio(), después de lo cual el inodo podría liberarse antes de que se llame a ext4_end_io_rsv_work(), lo que desencadenaría un problema de use-after-free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: rechazar paquetes maliciosos en ipv6_gso_segment(). syzbot pudo manipular un paquete con encabezados de extensión IPv6 muy largos, lo que provocó un desbordamiento de skb->transport_header. Este campo de 16 bits tiene un alcance limitado. Agregue el asistente skb_reset_transport_header_careful() y úselo desde ipv6_gso_segment() ADVERTENCIA: CPU: 0 PID: 5871 en ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [en línea] ADVERTENCIA: CPU: 0 PID: 5871 en ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Módulos vinculados: CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 No contaminado 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(completo) Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/07/2025 RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [en línea] RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Rastreo de llamadas: skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110 skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 __skb_gso_segment+0x342/0x510 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950 validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000 sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329 __dev_xmit_skb net/core/dev.c:4102 [inline] __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar UAF en f2fs_sync_inode_meta() syzbot informó un problema de UAF como el siguiente: [1] [2] [1] https://syzkaller.appspot.com/text?tag=CrashReport&x=16594c60580000 ===================================================================== ERROR: KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 Read of size 8 at addr ffff888100567dc8 by task kworker/u4:0/8 CPU: 1 PID: 8 Comm: kworker/u4:0 Tainted: G W 6.1.129-syzkaller-00017-g642656a36791 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Workqueue: writeback wb_workfn (flush-7:0) Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x151/0x1b7 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [inline] print_report+0x158/0x4e0 mm/kasan/report.c:427 kasan_report+0x13c/0x170 mm/kasan/report.c:531 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351 __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 __list_del_entry include/linux/list.h:134 [inline] list_del_init include/linux/list.h:206 [inline] f2fs_inode_synced+0x100/0x2e0 fs/f2fs/super.c:1553 f2fs_update_inode+0x72/0x1c40 fs/f2fs/inode.c:588 f2fs_update_inode_page+0x135/0x170 fs/f2fs/inode.c:706 f2fs_write_inode+0x416/0x790 fs/f2fs/inode.c:734 write_inode fs/fs-writeback.c:1460 [inline] __writeback_single_inode+0x4cf/0xb80 fs/fs-writeback.c:1677 writeback_sb_inodes+0xb32/0x1910 fs/fs-writeback.c:1903 __writeback_inodes_wb+0x118/0x3f0 fs/fs-writeback.c:1974 wb_writeback+0x3da/0xa00 fs/fs-writeback.c:2081 wb_check_background_flush fs/fs-writeback.c:2151 [inline] wb_do_writeback fs/fs-writeback.c:2239 [inline] wb_workfn+0xbba/0x1030 fs/fs-writeback.c:2266 process_one_work+0x73d/0xcb0 kernel/workqueue.c:2299 worker_thread+0xa60/0x1260 kernel/workqueue.c:2446 kthread+0x26d/0x300 kernel/kthread.c:386 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 Allocated by task 298: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_alloc_info+0x1f/0x30 mm/kasan/generic.c:505 __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:333 kasan_slab_alloc include/linux/kasan.h:202 [inline] slab_post_alloc_hook+0x53/0x2c0 mm/slab.h:768 slab_alloc_node mm/slub.c:3421 [inline] slab_alloc mm/slub.c:3431 [inline] __kmem_cache_alloc_lru mm/slub.c:3438 [inline] kmem_cache_alloc_lru+0x102/0x270 mm/slub.c:3454 alloc_inode_sb include/linux/fs.h:3255 [inline] f2fs_alloc_inode+0x2d/0x350 fs/f2fs/super.c:1437 alloc_inode fs/inode.c:261 [inline] iget_locked+0x18c/0x7e0 fs/inode.c:1373 f2fs_iget+0x55/0x4ca0 fs/f2fs/inode.c:486 f2fs_lookup+0x3c1/0xb50 fs/f2fs/namei.c:484 __lookup_slow+0x2b9/0x3e0 fs/namei.c:1689 lookup_slow+0x5a/0x80 fs/namei.c:1706 walk_component+0x2e7/0x410 fs/namei.c:1997 lookup_last fs/namei.c:2454 [inline] path_lookupat+0x16d/0x450 fs/namei.c:2478 filename_lookup+0x251/0x600 fs/namei.c:2507 vfs_statx+0x107/0x4b0 fs/stat.c:229 vfs_fstatat fs/stat.c:267 [inline] vfs_lstat include/linux/fs.h:3434 [inline] __do_sys_newlstat fs/stat.c:423 [inline] __se_sys_newlstat+0xda/0x7c0 fs/stat.c:417 __x64_sys_newlstat+0x5b/0x70 fs/stat.c:417 x64_sys_call+0x52/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:7 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3b/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 Freed by task 0: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:516 ____kasan_slab_free+0x131/0x180 mm/kasan/common.c:241 __kasan_slab_free+0x11/0x20 mm/kasan/common.c:249 kasan_slab_free include/linux/kasan.h:178 [inline] slab_free_hook mm/slub.c:1745 [inline] slab_free_freelist_hook mm/slub.c:1771 [inline] slab_free mm/slub.c:3686 [inline] kmem_cache_free+0x ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar el pánico en f2fs_evict_inode Como syzbot [1] informó a continuación: R10: 0000000000000100 R11: 0000000000000206 R12: 00007ffe17473450 R13: 00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520 ---[ fin de seguimiento 000000000000000 ]--- ====================================================================== ERROR: KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 Read of size 8 at addr ffff88812d962278 by task syz-executor/564 CPU: 1 PID: 564 Comm: syz-executor Tainted: G W 6.1.129-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace: __dump_stack+0x21/0x24 lib/dump_stack.c:88 dump_stack_lvl+0xee/0x158 lib/dump_stack.c:106 print_address_description+0x71/0x210 mm/kasan/report.c:316 print_report+0x4a/0x60 mm/kasan/report.c:427 kasan_report+0x122/0x150 mm/kasan/report.c:531 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351 __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 __list_del_entry include/linux/list.h:134 [inline] list_del_init include/linux/list.h:206 [inline] f2fs_inode_synced+0xf7/0x2e0 fs/f2fs/super.c:1531 f2fs_update_inode+0x74/0x1c40 fs/f2fs/inode.c:585 f2fs_update_inode_page+0x137/0x170 fs/f2fs/inode.c:703 f2fs_write_inode+0x4ec/0x770 fs/f2fs/inode.c:731 write_inode fs/fs-writeback.c:1460 [inline] __writeback_single_inode+0x4a0/0xab0 fs/fs-writeback.c:1677 writeback_single_inode+0x221/0x8b0 fs/fs-writeback.c:1733 sync_inode_metadata+0xb6/0x110 fs/fs-writeback.c:2789 f2fs_sync_inode_meta+0x16d/0x2a0 fs/f2fs/checkpoint.c:1159 block_operations fs/f2fs/checkpoint.c:1269 [inline] f2fs_write_checkpoint+0xca3/0x2100 fs/f2fs/checkpoint.c:1658 kill_f2fs_super+0x231/0x390 fs/f2fs/super.c:4668 deactivate_locked_super+0x98/0x100 fs/super.c:332 deactivate_super+0xaf/0xe0 fs/super.c:363 cleanup_mnt+0x45f/0x4e0 fs/namespace.c:1186 __cleanup_mnt+0x19/0x20 fs/namespace.c:1193 task_work_run+0x1c6/0x230 kernel/task_work.c:203 exit_task_work include/linux/task_work.h:39 [inline] do_exit+0x9fb/0x2410 kernel/exit.c:871 do_group_exit+0x210/0x2d0 kernel/exit.c:1021 __do_sys_exit_group kernel/exit.c:1032 [inline] __se_sys_exit_group kernel/exit.c:1030 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1030 x64_sys_call+0x7b4/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 RIP: 0033:0x7f28b1b8e169 Code: Unable to access opcode bytes at 0x7f28b1b8e13f. RSP: 002b:00007ffe174710a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f28b1c10879 RCX: 00007f28b1b8e169 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 0000000000000002 R08: 00007ffe1746ee47 R09: 00007ffe17472360 R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffe17472360 R13: 00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520 Allocated by task 569: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_alloc_info+0x25/0x30 mm/kasan/generic.c:505 __kasan_slab_alloc+0x72/0x80 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook+0x4f/0x2c0 mm/slab.h:737 slab_alloc_node mm/slub.c:3398 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc_lru+0x104/0x220 mm/slub.c:3429 alloc_inode_sb include/linux/fs.h:3245 [inline] f2fs_alloc_inode+0x2d/0x340 fs/f2fs/super.c:1419 alloc_inode fs/inode.c:261 [inline] iget_locked+0x186/0x880 fs/inode.c:1373 f2fs_iget+0x55/0x4c60 fs/f2fs/inode.c:483 f2fs_lookup+0x366/0xab0 fs/f2fs/namei.c:487 __lookup_slow+0x2a3/0x3d0 fs/namei.c:1690 lookup_slow+0x57/0x70 fs/namei.c:1707 walk_component+0x2e6/0x410 fs/namei ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/eeh: Hacer que el dispositivo del controlador EEH sea seguro para la conexión en caliente. Existían múltiples condiciones de ejecución entre el controlador PCIe de conexión en caliente y el controlador EEH, lo que provocaba diversos errores del kernel de la misma naturaleza general: . También se observa un segundo tipo de error cuando el bus subyacente desaparece durante la recuperación del dispositivo. Refactorice el módulo EEH para que sea seguro para la reexploración y la extracción de PCI. También corrija algunos problemas menores de formato y legibilidad.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pptp: garantizar la longitud mínima de skb en pptp_xmit() Se corrigió el commit aabc6596ffb3 ("net: ppp: agregar verificación de límite para datos skb en ppp_sync_txmung") ppp_sync_txmunge() Necesitamos una solución similar en pptp_xmit(); de lo contrario, podríamos leer datos no inicializados como lo informó syzbot. ERROR: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x893/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: cs42l43: La entrada de propiedad debe ser una matriz con terminación nula. El nodo de software no especifica un número de entradas de propiedad, por lo que la matriz debe terminar en nulo. Si no está terminada, esto puede provocar un fallo en el controlador del amplificador cs35l56, ya que el análisis del nodo se desvía del final de la matriz hacia una memoria desconocida.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/core: Salida anticipada en caso de fallo de perf_mmap(). Cuando perf_mmap() no asigna un búfer, sigue invocando la devolución de llamada event_mapped() del evento relacionado. En X86, esto podría aumentar el contador de referencias perf_rdpmc_allowed. Sin embargo, esto no se puede revertir, ya que perf_mmap_close() nunca se llama en este caso, lo que provoca otra fuga del recuento de referencias. Para evitarlo, se debe regresar anticipadamente en caso de fallo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: benet: se corrige un ERROR al crear VF. benet se bloquea tan pronto como se crean los VF SRIOV: ¡ERROR del kernel en mm/vmalloc.c:3457! Oops: código de operación no válido: 0000 [#1] SMP KASAN NOPTI CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: cargado No contaminado 6.16.0+ #1 PREEMPT(voluntario) [...] RIP: 0010:vunmap+0x5f/0x70 [...] Rastreo de llamadas: __iommu_dma_free+0xe8/0x1c0 be_cmd_set_mac_list+0x3fe/0x640 [be2net] be_cmd_set_mac+0xaf/0x110 [be2net] be_vf_eth_addr_config+0x19f/0x330 [be2net] be_vf_setup+0x4f7/0x990 [be2net] be_pci_sriov_configure+0x3a1/0x470 [be2net] sriov_numvfs_store+0x20b/0x380 kernfs_fop_write_iter+0x354/0x530 vfs_write+0x9b9/0xf60 ksys_write+0xf3/0x1d0 do_syscall_64+0x8c/0x3d0 be_cmd_set_mac_list() calls dma_free_coherent() bajo un spin_lock_bh. Para solucionarlo, libere el bloqueo solo después de liberarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sunrpc: corrección del manejo de las alertas tls del lado del servidor Scott Mayhew descubrió un exploit de seguridad en NFS sobre TLS en tls_alert_recv() debido a su suposición de que puede leer datos del kvec del iterador msg. La implementación de kTLS divide el payload del registro no de datos de TLS entre el búfer de mensajes de control (que incluye el tipo como la alerta TLS o el cambio de cifrado TLS) y el resto del payload (por ejemplo, el nivel/descripción de la alerta TLS) que va al búfer de payload msg. Este parche propone volver a trabajar cómo se configuran y utilizan los mensajes de control por sock_recvmsg(). Si no se configura ninguna estructura de mensaje de control, la capa kTLS leerá y procesará los tipos de registros de datos TLS. Tan pronto como encuentre un mensaje de control TLS, devolverá un error. En ese punto, NFS puede configurar un búfer de mensajes respaldado por kvec y leer el mensaje de control como una alerta TLS. El iterador Msg puede avanzar el puntero kvec como parte del proceso de copia, por lo tanto, debemos revertir el iterador antes de llamar a tls_alert_recv.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sunrpc: arregla el manejo del lado del cliente de las alertas tls Se descubrió un exploit de seguridad en NFS sobre TLS en tls_alert_recv debido a su suposición de que hay datos válidos en el kvec del iterador de msghdr. En cambio, este parche propone volver a trabajar en cómo se configuran y utilizan los mensajes de control por sock_recvmsg(). Si no se configura ninguna estructura de mensaje de control, la capa kTLS leerá y procesará los tipos de registros de datos TLS. Tan pronto como encuentre un mensaje de control TLS, devolverá un error. En ese punto, NFS puede configurar un búfer de control respaldado por kvec y leer el mensaje de control como una alerta TLS. Scott encontró que un iterador msg puede avanzar el puntero kvec como parte del proceso de copia, por lo tanto, necesitamos revertir el iterador antes de llamar a tls_alert_recv.