Vulnerabilidades

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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: geneve: Se corrige el problema de uso después de la liberación en geneve_find_dev(). syzkaller reportó un problema de uso después de la liberación en geneve_find_dev() [0] sin reproducción. geneve_configure() vincula la estructura geneve_dev.next con net_generic(net, geneve_net_id)->geneve_list. La red aquí podría diferir de dev_net(dev) si se configura IFLA_NET_NS_PID, IFLA_NET_NS_FD o IFLA_TARGET_NETNSID. Al desmantelar dev_net(dev), geneve_exit_batch_rtnl() finalmente llama a unregister_netdevice_queue() para cada dispositivo en la red, y posteriormente se libera el dispositivo. Sin embargo, su geneve_dev.next aún está vinculado a la red del socket UDP del backend. Entonces, se producirá un "use-after-free" al crear otro "geneve dev" en la red. En su lugar, llamaremos a "geneve_dellink()" en "geneve_destroy_tunnels()". [0]: ERROR: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline] BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441 CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600 Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: gadget: f_midi: f_midi_complete para llamar a queue_work. Al usar USB MIDI, se intenta adquirir un bloqueo dos veces mediante una llamada reentrante a f_midi_transmit, lo que provoca un bloqueo. Se soluciona usando queue_work() para programar la función f_midi_transmit() interna mediante una cola de trabajo de alta prioridad desde el controlador de finalización.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: stream-ipc: Comprobación de nulidad de cstream en sof_ipc_msg_data(). La nulidad de sps->cstream debe comprobarse de forma similar a como se realiza en la función sof_set_stream_data_offset(). Asumir que no es NULL si sps->stream es NULL es incorrecto y puede provocar la desreferenciación del puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/gt: El uso de spin_lock_irqsave() en un contexto interrumpible. Las funciones spin_lock/unlock() utilizadas en contextos de interrupción podrían provocar un interbloqueo, como se observó en el problema n.° 13399 de GitLab, que ocurre cuando la interrupción entra mientras se mantiene un bloqueo. Intente solucionar el problema guardando el estado de las irq antes de adquirir el bloqueo de giro. v2: añadir llamadas de guardado/restauración de estado de las irq a todos los bloqueos/desbloqueos en la ejecución de signal_irq_work() (Maciej). v3: usar con spin_lock_irqsave() en guc_lrc_desc_unpin() en lugar de otras llamadas de bloqueo/desbloqueo y añadir las etiquetas "Fixes" y "Cc" (Tvrtko); cambiar el título y el mensaje de confirmación (seleccionado del commit c088387ddd6482b40f21ccf23db1125e8fa4af7e).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: corrige el fallo cuando se deshabilita un espacio de nombres. El contador por CPU del espacio de nombres protege la E/S pendiente y solo podemos deshabilitar de forma segura el espacio de nombres una vez que el contador cae a cero. De lo contrario, terminamos con un bloqueo al ejecutar blktests/nvme/058 (por ejemplo, para el transporte de bucle): [2352.930426] [T53909] Ups: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI [2352.930431] [T53909] KASAN: null-ptr-deref en el rango [0x0000000000000028-0x000000000000002f] [2352.930434] [T53909] CPU: 3 UID: 0 PID: 53909 Comm: kworker/u16:5 Tainted: GW 6.13.0-rc6 #232 [ 2352.930438] [ T53909] Contaminado: [W]=WARN [ 2352.930440] [ T53909] Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 01/04/2014 [ 2352.930443] [ T53909] Cola de trabajo: nvmet-wq nvme_loop_execute_work [nvme_loop] [ 2352.930449] [ T53909] RIP: 0010:blkcg_set_ioprio+0x44/0x180 ya que la cola ya está desactivada al llamar a submit_bio(); Entonces, necesitamos inicializar el contador por CPU en nvmet_ns_enable() y esperar hasta que caiga a cero en nvmet_ns_disable() para evitar tener E/S pendiente después de que se haya deshabilitado el espacio de nombres.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Arregla el bloqueo suave en arena_map_free en un kernel de página de 64k En un kernel aarch64 con CONFIG_PAGE_SIZE_64KB=y, las pruebas arena_htab causan un fallo de segmentación y un bloqueo suave. No se observa el mismo fallo con páginas de 4k en aarch64. Resulta que arena_map_free() está llamando a apply_to_existing_page_range() con la dirección devuelta por bpf_arena_get_kern_vm_start(). Si esta dirección no está alineada con la página, el código termina llamando a apply_to_pte_range() con esa dirección no alineada, lo que causa un bloqueo suave. Arréglelo redondeando GUARD_SZ a PAGE_SIZE << 1 para que la división por 2 en bpf_arena_get_kern_vm_start() devuelva un valor alineado con la página.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: Add rx_skb of kfree_skb to raw_tp_null_args[]. Yan Zhai reported a BPF prog could trigger a null-ptr-deref [0] in trace_kfree_skb if the prog does not check if rx_sk is NULL. Commit c53795d48ee8 ("net: add rx_sk to trace_kfree_skb") added rx_sk to trace_kfree_skb, but rx_sk is optional and could be NULL. Let's add kfree_skb to raw_tp_null_args[] to let the BPF verifier validate such a prog and prevent the issue. Now we fail to load such a prog: libbpf: prog 'drop': -- BEGIN PROG LOAD LOG -- 0: R1=ctx() R10=fp0 ; int BPF_PROG(drop, struct sk_buff *skb, void *location, @ kfree_skb_sk_null.bpf.c:21 0: (79) r3 = *(u64 *)(r1 +24) func 'kfree_skb' arg3 has btf_id 5253 type STRUCT 'sock' 1: R1=ctx() R3_w=trusted_ptr_or_null_sock(id=1) ; bpf_printk("sk: %d, %d\n", sk, sk->__sk_common.skc_family); @ kfree_skb_sk_null.bpf.c:24 1: (69) r4 = *(u16 *)(r3 +16) R3 invalid mem access 'trusted_ptr_or_null_' processed 2 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 -- END PROG LOAD LOG -- Note this fix requires commit 838a10bd2ebf ("bpf: Augment raw_tp arguments with PTR_MAYBE_NULL"). [0]: BUG: kernel NULL pointer dereference, address: 0000000000000010 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 0 P4D 0 PREEMPT SMP RIP: 0010:bpf_prog_5e21a6db8fcff1aa_drop+0x10/0x2d Call Trace: ? __die+0x1f/0x60 ? page_fault_oops+0x148/0x420 ? search_bpf_extables+0x5b/0x70 ? fixup_exception+0x27/0x2c0 ? exc_page_fault+0x75/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_prog_5e21a6db8fcff1aa_drop+0x10/0x2d bpf_trace_run4+0x68/0xd0 ? unix_stream_connect+0x1f4/0x6f0 sk_skb_reason_drop+0x90/0x120 unix_stream_connect+0x1f4/0x6f0 __sys_connect+0x7f/0xb0 __x64_sys_connect+0x14/0x20 do_syscall_64+0x47/0xc30 entry_SYSCALL_64_after_hwframe+0x4b/0x53

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfp: bpf: Agregar verificación para nfp_app_ctrl_msg_alloc() Agregar verificación para el valor de retorno de nfp_app_ctrl_msg_alloc() en nfp_bpf_cmsg_alloc() para evitar la desreferencia del puntero nulo.