Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: evita la especulación de código de operación. sqe->opcode se utiliza para diferentes tablas, asegúrese de que lo desinfectemos contra especulaciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drop_monitor: fix incorrect initialization order Syzkaller reports the following bug: BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: /-1, .owner_cpu: 0 CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x119/0x179 lib/dump_stack.c:118 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159 reset_per_cpu_data+0xe6/0x240 [drop_monitor] net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x157/0x190 net/socket.c:663 ____sys_sendmsg+0x712/0x870 net/socket.c:2378 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7 RIP: 0033:0x7f3f9815aee9 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9 RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007 RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768 Si drop_monitor se compila como un módulo del kernel, syzkaller podría tener tiempo de enviar un mensaje NET_DM_CMD_START de netlink durante la carga del módulo. Esto llamará a la función net_dm_monitor_start(), que utiliza un spinlock aún no inicializado. Para solucionar esto, prioricemos la inicialización de recursos al registro de una familia genérica de netlink. Encontrado por InfoTeCS en nombre del Centro de Verificación de Linux (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: descartar secpath al mismo tiempo que descartamos dst Xiumei informó haber alcanzado el WARN en xfrm6_tunnel_net_exit mientras ejecutaba pruebas que se reducen a: - crear un par de netns - ejecutar una prueba TCP básica sobre ipcomp6 - eliminar el par de netns El xfrm_state encontrado en spi_byaddr no se eliminó en el momento en que eliminamos los netns, porque aún tenemos una referencia en él. Esta referencia persistente proviene de un secpath (que contiene una referencia en xfrm_state), que aún está adjunto a un skb. Este skb no se filtra, termina en sk_receive_queue y luego se libera mediante skb_attempt_defer_free. El problema ocurre cuando posponemos la liberación de un skb (insertarlo en la lista defer_list de una CPU) y no limpiamos esa lista antes de eliminar netns. En ese caso, aún tenemos una referencia en xfrm_state inesperada en este momento. Ya eliminamos el dst del skb en la ruta de recepción TCP cuando ya no es necesario, así que también eliminamos el secpath. En este punto, tcp_filter ya ha llamado a los ganchos LSM que podrían requerir el secpath, por lo que ya no debería ser necesario. Sin embargo, en algunos de esos lugares, la extensión MPTCP se acaba de adjuntar al skb, por lo que no podemos simplemente eliminar todas las extensiones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gtp: Supresión de la corrupción de listas en gtp_net_exit_batch_rtnl(). Brad Spengler reportó la corrupción de list_del() en gtp_net_exit_batch_rtnl(). [0] El commit eb28fd76c0a0 ("gtp: Destruir dispositivo junto con el desmantelamiento de netns del socket UDP") añadió el bucle for_each_netdev() en gtp_net_exit_batch_rtnl() para destruir dispositivos en cada netns, como se hace en los túneles geneve e IP. Sin embargo, esto podría activar ->dellink() dos veces para el mismo dispositivo durante ->exit_batch_rtnl(). Digamos que tenemos dos netns A y B y un dispositivo gtp B que reside en netns B pero cuyo socket UDP está en netns A. 1. cleanup_net() procesa netns A y luego B. 2. gtp_net_exit_batch_rtnl() encuentra el dispositivo B mientras itera gn->gtp_dev_list de netns A y llama a ->dellink(). [el dispositivo B aún no está desvinculado de netns B ya que no se ha llamado a unregister_netdevice_many().] 3. gtp_net_exit_batch_rtnl() encuentra el dispositivo B mientras itera for_each_netdev() de netns B y llama a ->dellink(). gtp_dellink() limpia la tabla hash del dispositivo, desvincula el dev de gn->gtp_dev_list y llama a unregister_netdevice_queue(). Básicamente, llamar a gtp_dellink() varias veces no tiene problema a menos que CONFIG_DEBUG_LIST esté habilitado. Eliminemos for_each_netdev() en gtp_net_exit_batch_rtnl() y deleguemos la destrucción a default_device_exit_batch() como se hace en bareudp. [0]: corrupción en list_del, ffff8880aaa62c00->next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04) kernel BUG at lib/list_debug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1 Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:[] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc <0f> 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60 RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283 RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054 RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000 RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32 R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4 R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08 RBX: kasan shadow of 0x0 RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554 RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71 RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object] RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ] R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ] R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ] R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object] FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0 Stack: 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00 ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360d Call Trace: [] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28 [] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28 [] list_del include/linux/list.h:262 [inl ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/code-patching: Se corrige el impacto de KASAN al no marcar el área de parcheo de texto como VM_ALLOC Erhard informó el siguiente impacto de KASAN al iniciar su PowerMac G4 con un kernel 6.13-rc6 habilitado para KASAN: ERROR: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 Write of size 8 at addr f1000000 by task chronyd/1293 CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2 Tainted: [W]=WARN Hardware name: PowerMac3,6 7455 0x80010303 PowerMac Call Trace: [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable) [c24375b0] [c0504998] print_report+0xdc/0x504 [c2437610] [c050475c] kasan_report+0xf8/0x108 [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8 [c24376c0] [c004c014] patch_instructions+0x15c/0x16c [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478 [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14 [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4 [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890 [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420 [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c --- interrupt: c00 at 0x5a1274 NIP: 005a1274 LR: 006a3b3c CTR: 005296c8 REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4) MSR: 0200f932 CR: 24004422 XER: 00000000 GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932 GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57 GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002 GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001 NIP [005a1274] 0x5a1274 LR [006a3b3c] 0x6a3b3c --- interrupt: c00 The buggy address belongs to the virtual mapping at [f1000000, f1002000) created by: text_area_cpu_up+0x20/0x190 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30 flags: 0x80000000(zone=2) raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001 raw: 00000000 page dumped because: kasan: bad access detected Memory state around the buggy address: f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== f8 corresponds to KASAN_VMALLOC_INVALID, lo que significa que el área no está inicializada, por lo tanto, no se supone que se use todavía. La infraestructura de parches de texto de Powerpc asigna un área de memoria virtual usando get_vm_area() y la marca como VM_ALLOC. Pero esa marca está destinada a usarse para vmalloc() y la memoria asignada por vmalloc() no se supone que se use antes de una llamada a __vmalloc_node_range() que nunca se llama para esa área. Esto pasó desapercibido hasta el commit e4137f08816b ("mm, kasan, kmsan: instrument copy_from/to_kernel_nofault"). El área asignada por text_area_cpu_up() no es memoria vmalloc; se asigna directamente cuando map_kernel_page() la necesita. No hay ninguna marca de máquina virtual que corresponda a dicho uso, así que simplemente no se debe pasar ninguna. De esta forma, el área no se verá afectada y estará disponible de inmediato.

Vulnerabilidad de generación de mensaje de error que contiene información confidencial en Hillstone Next Generation FireWall de Hillstone Networks. Este problema afecta a Hillstone Next Generation FireWall: desde 5.5R8P1 hasta 5.5R8P23.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sockmap, vsock: Para sockets conectables, solo se permite que estén conectados. Sockmap espera que todos los vsocks tengan un transporte asignado, lo cual se expresa en vsock_proto::psock_update_sk_prot(). Sin embargo, existe un caso extremo en el que un socket no conectado (conectable) puede perder su transporte previamente asignado. Esto se gestiona con una comprobación de NULL en la ruta de recepción vsock/BPF. Otro detalle de diseño es que los vsocks que escuchan no deben tener ningún transporte asignado. Esto implica que no son compatibles con sockmap. Sin embargo, esto se complica por el hecho de que un socket, antes de cambiar a TCP_LISTEN, puede haber tenido algún transporte asignado durante un intento fallido de connect(). Por lo tanto, podemos terminar con un vsock escuchando en un sockmap, que explota rápidamente: KASAN: null-ptr-deref en el rango [0x0000000000000120-0x0000000000000127] CPU: 7 UID: 0 PID: 56 Comm: kworker/7:0 No contaminado 6.14.0-rc1+ Cola de trabajo: vsock-loopback vsock_loopback_work RIP: 0010:vsock_read_skb+0x4b/0x90 Rastreo de llamadas: sk_psock_verdict_data_ready+0xa4/0x2e0 virtio_transport_recv_pkt+0x1ca8/0x2acc vsock_loopback_work+0x27d/0x3f0 Para los sockets conectables, en lugar de depender únicamente del estado de vsk->transport, indique a sockmap que solo permita los que representan conexiones establecidas. Esto coincide con el comportamiento de AF_INET y AF_UNIX.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/ism: añadir función de liberación para struct device. Según device_release() en /drivers/base/core.c, un dispositivo sin función de liberación es un dispositivo dañado y debe repararse. El código actual libera el dispositivo directamente tras llamar a device_add() sin esperar a que otras partes del kernel liberen sus referencias. Por lo tanto, una referencia a un dispositivo de estructura podría seguir manteniéndose, por ejemplo, mediante sysfs, lo que podría provocar problemas de uso después de la liberación si no se configura una función de liberación adecuada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: cls_api: se corrige el error de gestión que causa la desreferencia de NULL. tcf_exts_miss_cookie_base_alloc() llama a xa_alloc_cyclic(), que puede devolver 1 si la asignación se realizó correctamente tras el encapsulado. Esto se trató como un error, con el valor 1 devuelto al llamador tcf_exts_init_ex(), que establece exts->actions en NULL y devuelve 1 al llamador fl_change(). fl_change() trata err == 1 como correcto, llamando a tcf_exts_validate_ex(), que llama a tcf_action_init() con exts->actions como argumento, donde se desreferencia. Ejemplo de seguimiento: ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000000 CPU: 114 PID: 16151 Comm: handler114 Kdump: cargado No contaminado 5.14.0-503.16.1.el9_5.x86_64 #1 RIP: 0010:tcf_action_init+0x1f8/0x2c0 Seguimiento de llamadas: tcf_action_init+0x1f8/0x2c0 tcf_exts_validate_ex+0x175/0x190 fl_change+0x537/0x1120 [cls_flower]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/zswap: se corrige una inconsistencia al fallar zswap_store_page(). El commit b7c0ccdfbafd ("mm: zswap: admite folios grandes en zswap_store()") omite el cobro de las entradas zswap cuando no se logra el cobro de todo el folio. Sin embargo, cuando se realizan cobros de algunas páginas base, pero no se logra el cobro de todo el folio, la operación de cobro se revierte. Al liberar las entradas zswap de esas páginas, zswap_entry_free() descarga las entradas zswap que no se habían cargado previamente, lo que provoca que el cobro de zswap se vuelva inconsistente. Esta inconsistencia activa dos advertencias con los siguientes pasos: # En una máquina con 64 GiB de RAM y 36 GiB de zswap $ stress-ng --bigheap 2 # esperar hasta que OOM-killer elimine stress-ng $ sudo reboot Las dos advertencias son: en mm/memcontrol.c:163, función obj_cgroup_release(): WARN_ON_ONCE(nr_bytes & (PAGE_SIZE - 1)); en mm/page_counter.c:60, función page_counter_cancel(): if (WARN_ONCE(new < 0, "page_counter underflow: %ld nr_pages=%lu\n", new, nr_pages)) zswap_stored_pages también se vuelve inconsistente de la misma manera. Como sugirió Kanchana, incremente zswap_stored_pages y cargue las entradas zswap dentro de zswap_store_page() cuando tenga éxito. De esta forma, zswap_entry_free() decrementará el contador y descargará las entradas cuando no pueda intercambiar todo el folio con zswap. Si bien esto podría optimizarse agrupando la carga de objcg e incrementando el contador, centrémonos en corregir el error esta vez y dejemos la optimización para más adelante, tras una evaluación. Tras resolver la inconsistencia, las advertencias desaparecen. [42.hyeyoo@gmail.com: refactorizar zswap_store_page()] Enlace: https://lkml.kernel.org/r/20250131082037.2426-1-42.hyeyoo@gmail.com

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: evitar mantener freeze_mutex durante la operación mmap. Usamos map->freeze_mutex para evitar ejecuciones entre map_freeze() y el mapeo de memoria del contenido del mapa BPF con permisos de escritura. Esta forma ingenua de hacerlo implica mantener freeze_mutex durante todas las manipulaciones mm y VMA, lo cual es completamente innecesario. Esto también puede provocar interbloqueos, como informa syzbot en [0]. Por lo tanto, se mantiene freeze_mutex solo durante las comprobaciones de escritura, se aumenta (proactivamente) el contador de "escritura activa" del mapa, se desbloquea el mutex y se continúa con la lógica mmap. Solo si algo falla durante la lógica mmap, se deshace el incremento del contador de "escritura activa". [0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ibmvnic: No hacer referencia a skb después de enviar a VIOS. Anteriormente, tras vaciar correctamente el búfer de transmisión a VIOS, la estadística tx_bytes se incrementaba según la longitud de skb. No es posible acceder a la memoria de skb después de enviar el búfer a VIOS, ya que, en cualquier momento posterior al envío, VIOS puede activar una interrupción para liberar esta memoria. Es posible que se produzca una carrera entre la lectura de skb->len y la liberación de skb (especialmente durante LPM) y esto dará como resultado un uso después de la liberación: ======================================================================== ERROR KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic] Read of size 4 at addr c00000024eb48a70 by task hxecom/14495 <...> Call Trace: [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable) [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0 [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8 [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0 [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic] [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358 <...> Freed by task 0: kasan_save_stack+0x34/0x68 kasan_save_track+0x2c/0x50 kasan_save_free_info+0x64/0x108 __kasan_mempool_poison_object+0x148/0x2d4 napi_skb_cache_put+0x5c/0x194 net_tx_action+0x154/0x5b8 handle_softirqs+0x20c/0x60c do_softirq_own_stack+0x6c/0x88 <...> The buggy address belongs to the object at c00000024eb48a00 which belongs to the cache skbuff_head_cache of size 224 =======================================================================