Vulnerabilidades

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Corrección de interbloqueo al liberar almacenamiento de cgroup. El siguiente commit bc235cdb423a ("bpf: Prevenir interbloqueo desde bpf_task_storage_[get|delete] recursivo") introdujo por primera vez la prevención de interbloqueo para programas fentry/fexit que se conectaban a los ayudantes bpf_task_storage. Este commit también empleó la lógica de map free path en su versión v6. Más tarde, bpf_cgrp_storage se introdujo por primera vez en c4bcfb38a95e ("bpf: Implementar almacenamiento cgroup disponible para programas bpf no adjuntos a cgroup") que enfrenta el mismo problema que bpf_task_storage, en lugar de su contador de ocupación, se pasó NULL a bpf_local_storage_map_free() que abrió una ventana para causar un bloqueo: (acquiring local_storage->lock) _raw_spin_lock_irqsave+0x3d/0x50 bpf_local_storage_update+0xd1/0x460 bpf_cgrp_storage_get+0x109/0x130 bpf_prog_a4d4a370ba857314_cgrp_ptr+0x139/0x170 ? __bpf_prog_enter_recur+0x16/0x80 bpf_trampoline_6442485186+0x43/0xa4 cgroup_storage_ptr+0x9/0x20 (manteniendo el bloqueo de almacenamiento local) bpf_selem_unlink_storage_nolock.constprop.0+0x135/0x160 bpf_selem_unlink_storage+0x6f/0x110 bpf_local_storage_map_free+0xa2/0x110 bpf_map_free_deferred+0x5b/0x90 process_one_work+0x17c/0x390 subproceso de trabajo+0x251/0x360 kthread+0xd2/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 Programas: - A: SEC("fentry/cgroup_storage_ptr") - cgid (BPF_MAP_TYPE_HASH) Registra el ID del grupo de control al que pertenece la tarea actual en este mapa hash, utilizando la dirección del grupo de control como clave del mapa. - cgrpa (BPF_MAP_TYPE_CGRP_STORAGE) Si la tarea actual es un kworker, busca el mapa hash anterior utilizando el parámetro de función @owner como clave para obtener su ID de grupo de control correspondiente, que luego se utiliza para obtener un puntero confiable al grupo de control mediante bpf_cgroup_from_id(). Este puntero confiable se puede pasar a bpf_cgrp_storage_get() para finalmente activar el problema de interbloqueo. - B: SEC("tp_btf/sys_enter") - cgrpb (BPF_MAP_TYPE_CGRP_STORAGE). El único propósito de este programa es llenar el mapa hash del Programa A llamando a bpf_cgrp_storage_get() para tantas tareas de espacio de usuario como sea posible. Pasos para reproducir: - Ejecutar A; - while (true) { Ejecutar B; Destruir B; }. Solucione este problema pasando su contador de ocupación al procedimiento libre para que pueda incrementarse correctamente antes del bloqueo de almacenamiento/smap.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige la doble ejecución de contabilidad cuando btrfs_run_delalloc_range() falla [ERROR] Al ejecutar btrfs con un tamaño de bloque (4K) menor que el tamaño de página (64K, aarch64), hay una gran posibilidad de que se bloquee el kernel en generic/750, con los siguientes mensajes: (antes de los seguimientos de llamadas, se agregan 3 mensajes de depuración adicionales) Advertencia de BTRFS (dispositivo dm-3): lectura y escritura para tamaño de sector 4096 con tamaño de página 65536 es experimental Información de BTRFS (dispositivo dm-3): comprobando árbol UUID hrtimer: la interrupción tomó 5451385 ns Error de BTRFS (dispositivo dm-3): cow_file_range falló, root=4957 inode=257 start=1605632 len=69632: -28 Error de BTRFS (dispositivo dm-3): run_delalloc_nocow falló, raíz=4957 inodo=257 inicio=1605632 len=69632: -28 Error de BTRFS (dispositivo dm-3): no se pudo ejecutar el rango delalloc, raíz=4957 ino=257 folio=1572864 submit_bitmap=8-15 inicio=1605632 len=69632: -28 ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 2 PID: 3020984 at ordered-data.c:360 can_finish_ordered_extent+0x370/0x3b8 [btrfs] CPU: 2 UID: 0 PID: 3020984 Comm: kworker/u24:1 Tainted: G OE 6.13.0-rc1-custom+ #89 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : can_finish_ordered_extent+0x370/0x3b8 [btrfs] lr : can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] Call trace: can_finish_ordered_extent+0x370/0x3b8 [btrfs] (P) can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] (L) btrfs_mark_ordered_io_finished+0x130/0x2b8 [btrfs] extent_writepage+0x10c/0x3b8 [btrfs] extent_write_cache_pages+0x21c/0x4e8 [btrfs] btrfs_writepages+0x94/0x160 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x74/0xa0 start_delalloc_inodes+0x17c/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x17c/0x288 [btrfs] shrink_delalloc+0x11c/0x280 [btrfs] flush_space+0x288/0x328 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x228/0x680 worker_thread+0x1bc/0x360 kthread+0x100/0x118 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1605632 OE len=16384 to_dec=16384 left=0 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1622016 OE len=12288 to_dec=12288 left=0 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1634304 OE len=8192 to_dec=4096 left=0 CPU: 1 UID: 0 PID: 3286940 Comm: kworker/u24:3 Tainted: G W OE 6.13.0-rc1-custom+ #89 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: btrfs_work_helper [btrfs] (btrfs-endio-write) pstate: 404000c5 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : process_one_work+0x110/0x680 lr : worker_thread+0x1bc/0x360 Call trace: process_one_work+0x110/0x680 (P) worker_thread+0x1bc/0x360 (L) worker_thread+0x1bc/0x360 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: f84086a1 f9000fe1 53041c21 b9003361 (f9400661) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs SMP: failed to stop secondary CPUs 2-3 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: 0x275bb9540000 from 0xffff800080000000 PHYS_OFFSET: 0xffff8fbba0000000 CPU features: 0x100,00000070,00801250,8201720b [CAUSE] The above warning is triggered immediately after the delalloc range failure, this happens in the following sequence: - Range [1568K, 1636K) is dirty 1536K 1568K 1600K 1636K 1664K | |/////////|////////| | Where 1536K, 1600K and 1664K are page boundaries (64K page size) - Enter extent_writepage() for page 1536K - Enter run_delalloc_nocow() with locke ---truncado---