Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: Se corrige la pérdida de memoria en el cierre diferido. xfstests en smb21 informa kmemleak como se muestra a continuación: objeto sin referencia 0xffff8881767d6200 (tamaño 64): comm "xfs_io", pid 1284, jiffies 4294777434 (edad 20,789 s) volcado hexadecimal (primeros 32 bytes): 80 5a d0 11 81 88 ff ff 78 8a aa 63 81 88 ff ff .Z......x..c.... 00 71 99 76 81 88 ff ff 00 00 00 00 00 00 00 00 .qv........... backtrace: [<00000000ad04e6ea>] cifs_close+0x92/0x2c0 [<0000000028b93c82>] __fput+0xff/0x3f0 [<00000000d8116851>] task_work_run+0x85/0xc0 [<0000000027e14f9e>] do_exit+0x5e5/0x1240 [<00000000fb492b95>] do_group_exit+0x58/0xe0 [<00000000129a32d9>] __x64_sys_exit_group+0x28/0x30 [<00000000e3f7d8e9>] do_syscall_64+0x35/0x80 [<00000000102e8a0b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Cuando cancelamos el trabajo de cierre diferido, también debemos limpiar la estructura cifs_deferred_close.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing/eprobes: Que las sondas de eventos sean consistentes con kprobes y uprobes. Actualmente, si se intenta usar el símbolo "@" con una sonda de eventos (eprobes), se producirá un fallo por desreferencia de puntero nulo. Tanto kprobes como uprobes pueden referenciar datos distintos a los registros principales, como la dirección inmediata, los símbolos y el nombre de la tarea actual. Que eprobes haga lo mismo. Para "comm", si se usa "comm" y el evento al que se adjunta no tiene el campo "comm", se debe usar "$comm" que tiene kprobes. Esto es consistente con el funcionamiento de los histogramas y filtros.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: apparmor: Se corrige la fuga de memoria en aa_simple_write_to_buffer(). Cuando copy_from_user falla, kvfree libera la memoria. Sin embargo, la estructura de administración y el blob de datos se asignan de forma independiente, por lo que solo kvfree(data) causa un problema de fuga de memoria. Utilice aa_put_loaddata(data) para solucionar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tee: agregar verificación de desbordamiento en register_shm_helper(). Con longitudes especiales suministradas por el espacio de usuario, register_shm_helper() tiene un desbordamiento de entero al calcular la cantidad de páginas cubiertas por una región de memoria del espacio de usuario suministrada. Esto hace que internal_get_user_pages_fast(), una función auxiliar de pin_user_pages_fast(), realice una desreferencia de puntero NULL: No se puede manejar la desreferencia de puntero NULL del núcleo en la dirección virtual 0000000000000010 Módulos vinculados: CPU: 1 PID: 173 Comm: optee_example_a No contaminado 5.19.0 #11 Nombre del hardware: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pc : internal_get_user_pages_fast+0x474/0xa80 Rastreo de llamadas: internal_get_user_pages_fast+0x474/0xa80 pin_user_pages_fast+0x24/0x4c register_shm_helper+0x194/0x330 tee_shm_register_user_buf+0x78/0x120 tee_ioctl+0xd0/0x11a0 __arm64_sys_ioctl+0xa8/0xec invoke_syscall+0x48/0x114 Solucione esto agregando una llamada explícita a access_ok() en tee_shm_register_user_buf() para detectar de manera temprana una dirección de espacio de usuario no válida.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: felix: suprimir los no cambios en el protocolo de etiquetado La forma en que funciona dsa_tree_change_tag_proto() es que cuando dsa_tree_notify() falla, no sabe si la operación falló a mitad de camino en un árbol de múltiples conmutadores o falló para un árbol de un solo conmutador. Entonces, aunque los controladores necesitan fallar limpiamente en ds->ops->change_tag_protocol(), DSA seguirá llamando a dsa_tree_notify() nuevamente, para restaurar el antiguo protocolo de etiqueta para los conmutadores potenciales en el árbol donde el cambio sí tuvo éxito (antes de fallar para otros). Esto significa para el controlador felix que si informamos de un error en felix_change_tag_protocol(), recibiremos otra llamada donde proto_ops == old_proto_ops. Si procedemos a actuar en consecuencia, podemos hacer cosas inesperadas. Por ejemplo, llamaremos a dsa_tag_8021q_register() dos veces seguidas, sin ejecutar dsa_tag_8021q_unregister() entre ambas. Luego, llamaremos a dsa_tag_8021q_unregister() mediante old_proto_ops->teardown, lo cual (si logra ejecutarse, tras analizar las estructuras de datos dañadas) dejará los puertos inoperativos. El error se puede reproducir fácilmente si forzamos un error en modo tag_8021q; esto provoca un fallo del kernel. echo ocelot-8021q > /sys/class/net/eno2/dsa/tagging echo edsa > /sys/class/net/eno2/dsa/tagging # -EPROTONOSUPPORT No se puede controlar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000014 Rastreo de llamadas: vcap_entry_get+0x24/0x124 ocelot_vcap_filter_del+0x198/0x270 felix_tag_8021q_vlan_del+0xd4/0x21c dsa_switch_tag_8021q_vlan_del+0x168/0x2cc dsa_switch_event+0x68/0x1170 dsa_tree_notify+0x14/0x34 dsa_port_tag_8021q_vlan_del+0x84/0x110 dsa_tag_8021q_unregister+0x15c/0x1c0 felix_tag_8021q_teardown+0x16c/0x180 felix_change_tag_protocol+0x1bc/0x230 dsa_switch_event+0x14c/0x1170 dsa_tree_change_tag_proto+0x118/0x1c0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio-blk: Evita el Use-After-Free al suspender/reanudar. hctx->user_data está configurado como vq en virtblk_init_hctx(). Sin embargo, vq se libera al suspender y se reasigna al reanudar. Por lo tanto, hctx->user_data no es válido después de reanudar y provocará el acceso después de la liberación, lo que provocará un fallo del kernel similar al siguiente: [ 22.428391] Seguimiento de llamadas: [ 22.428899] [ 22.429339] virtqueue_add_split+0x3eb/0x620 [ 22.430035] ? __blk_mq_alloc_requests+0x17f/0x2d0 [ 22.430789] ? kvm_clock_get_cycles+0x14/0x30 [ 22.431496] virtqueue_add_sgs+0xad/0xd0 [ 22.432108] virtblk_add_req+0xe8/0x150 [ 22.432692] virtio_queue_rqs+0xeb/0x210 [ 22.433330] blk_mq_flush_plug_list+0x1b8/0x280 [ 22.434059] __blk_flush_plug+0xe1/0x140 [ 22.434853] blk_finish_plug+0x20/0x40 [ 22.435512] read_pages+0x20a/0x2e0 [ 22.436063] ? folio_add_lru+0x62/0xa0 [ 22.436652] page_cache_ra_unbounded+0x112/0x160 [ 22.437365] filemap_get_pages+0xe1/0x5b0 [ 22.437964] ? context_to_sid+0x70/0x100 [ 22.438580] ? sidtab_context_to_sid+0x32/0x400 [ 22.439979] filemap_read+0xcd/0x3d0 [ 22.440917] xfs_file_buffered_read+0x4a/0xc0 [ 22.441984] xfs_file_read_iter+0x65/0xd0 [ 22.442970] __kernel_read+0x160/0x2e0 [ 22.443921] bprm_execve+0x21b/0x640 [ 22.444809] do_execveat_common.isra.0+0x1a8/0x220 [ 22.446008] __x64_sys_execve+0x2d/0x40 [ 22.446920] do_syscall_64+0x37/0x90 [ 22.447773] entry_SYSCALL_64_after_hwframe+0x63/0xcd Este parche corrige este problema obteniendo vq de vblk y elimina virtblk_init_hctx().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: mover la limpieza del subflujo en mptcp_destroy_common() Si la creación del socket mptcp falla debido a un programa eBPF CGROUP_INET_SOCK_CREATE, el protocolo MPTCP termina filtrando todos los subflujos: la limpieza relacionada ocurre en __mptcp_destroy_sock() que no se invoca en dicha ruta de código. Aborda el problema moviendo la limpieza de los sockets del subflujo en el ayudante mptcp_destroy_common(), que se invoca en cada ruta de limpieza de msk. Además, deshazte del paso intermedio list_splice_init, que es una reliquia innecesaria del pasado. El problema está presente desde antes de el commit de la causa raíz informada, pero cualquier intento de retroportar la solución antes de ese hash requerirá una reescritura completa.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: no poner en cola datos en subflujos cerrados Dipanjan informó de un splat de syzbot en el momento del cierre: ADVERTENCIA: CPU: 1 PID: 10818 en net/ipv4/af_inet.c:153 inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153 Módulos vinculados en: uio_ivshmem(OE) uio(E) CPU: 1 PID: 10818 Comm: kworker/1:16 Tainted: G OE 5.19.0-rc6-g2eae0556bb9d #2 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Cola de trabajo: eventos mptcp_worker RIP: 0010:inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153 Código: 21 02 00 00 41 8b 9c 24 28 02 00 00 e9 07 ff ff ff e8 34 4d 91 f9 89 ee 4c 89 e7 e8 4a 47 60 ff e9 a6 fc ff ff e8 20 4d 91 f9 <0f> 0b e9 84 fe ff ff e8 14 4d 91 f9 0f 0b e9 d4 fd ff ff e8 08 4d RSP: 0018:ffffc9001b35fa78 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000002879d0 RCX: ffff8881326f3b00 RDX: 00000000000000000 RSI: ffff8881326f3b00 RDI: 0000000000000002 RBP: ffff888179662674 R08: ffffffff87e983a0 R09: 0000000000000000 R10: 00000000000000005 R11: 00000000000004ea R12: ffff888179662400 R13: ffff888179662428 R14: 0000000000000001 R15: ffff88817e38e258 FS: 0000000000000000(0000) GS:ffff8881f5f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020007bc0 CR3: 0000000179592000 CR4: 0000000000150ee0 Rastreo de llamadas: __sk_destruct+0x4f/0x8e0 net/core/sock.c:2067 sk_destruct+0xbd/0xe0 net/core/sock.c:2112 __sk_free+0xef/0x3d0 net/core/sock.c:2123 sk_free+0x78/0xa0 net/core/sock.c:2134 sock_put include/net/sock.h:1927 [inline] __mptcp_close_ssk+0x50f/0x780 net/mptcp/protocol.c:2351 __mptcp_destroy_sock+0x332/0x760 net/mptcp/protocol.c:2828 mptcp_worker+0x5d2/0xc90 net/mptcp/protocol.c:2586 process_one_work+0x9cc/0x1650 kernel/workqueue.c:2289 worker_thread+0x623/0x1070 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 La causa raíz del problema es que una (re)transmisión a nivel de mptcp puede competir con mptcp_close() y el programador de paquetes comprueba el estado del subflujo antes de adquirir el bloqueo del socket: podemos intentar (re)transmitir en un ssk ya cerrado. Corrija el problema comprobando de nuevo el estado del socket del subflujo bajo la protección de bloqueo del socket del subflujo. Además, añada la comprobación que falta para el caso de respaldo a TCP.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: BPF: Arreglar posible desreferencia de puntero incorrecta en bpf_sys_bpf() La función auxiliar bpf_sys_bpf() permite que un programa eBPF cargue otro programa eBPF desde dentro del kernel. En este caso, el puntero de unión de argumentos bpf_attr (así como los punteros insns y license dentro) es una dirección de kernel en lugar de una dirección de espacio de usuario (que es el caso de una llamada al sistema bpf() habitual). Para hacer que el proceso de copia de memoria en la llamada al sistema funcione en ambos casos, se introdujo bpfptr_t para envolver el puntero y distinguir su origen. Específicamente, al copiar contenido de memoria desde un bpfptr_t, se realiza un copy_from_user() en el caso de una dirección de espacio de usuario y se realiza un memcpy() para una dirección de kernel. Esto puede conducir a problemas porque el puntero en el kernel nunca se comprueba para su validez. El problema ocurre cuando un programa de llamada al sistema eBPF intenta llamar a bpf_sys_bpf() para cargar un programa, pero proporciona un puntero insns incorrecto (por ejemplo, 0xdeadbeef) en la unión bpf_attr. El asistente llama a __sys_bpf(), que a su vez llama a bpf_prog_load() para cargar el programa. bpf_prog_load() se encarga de copiar las instrucciones eBPF a la memoria recién asignada al programa; crea un bpfptr_t de kernel para insns e invoca copy_from_bpfptr(). Internamente, todas las operaciones bpfptr_t están respaldadas por las operaciones sockptr_t correspondientes, que ejecutan memcpy() directamente en los punteros de kernel para las operaciones copy_from/strncpy_from. Por lo tanto, el código siempre desreferencia el puntero incorrecto para generar un fallo de página imposible de controlar y, en consecuencia, un error. Sin embargo, esto no debería suceder porque en ese momento el programa eBPF ya está verificado y no debería causar un error de memoria. Ejemplo de seguimiento de KASAN: [ 25.685056][ T228] ======================================================================= [ 25.685680][ T228] ERROR: KASAN: acceso a memoria de usuario en copy_from_bpfptr+0x21/0x30 [ 25.686210][ T228] Lectura de tamaño 80 en la dirección 00000000deadbeef por la tarea poc/228 [ 25.686732][ T228] [ 25.686893][ T228] CPU: 3 PID: 228 Comm: poc No contaminado 5.19.0-rc7 #7 [ 25.687375][ T228] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS d55cb5a 01/04/2014 [ 25.687991][ T228] Seguimiento de llamadas: [ 25.688223][ T228] [ 25.688429][ T228] dump_stack_lvl+0x73/0x9e [ 25.688747][ T228] print_report+0xea/0x200 [ 25.689061][ T228] ? copy_from_bpfptr+0x21/0x30 [ 25.689401][ T228] ? _printk+0x54/0x6e [ 25.689693][ T228] ? _raw_spin_lock_irqsave+0x70/0xd0 [ 25.690071][ T228] ? copy_from_bpfptr+0x21/0x30 [ 25.690412][ T228] kasan_report+0xb5/0xe0 [ 25.690716][ T228] ? copy_from_bpfptr+0x21/0x30 [ 25.691059][ T228] kasan_check_range+0x2bd/0x2e0 [ 25.691405][ T228] ? copy_from_bpfptr+0x21/0x30 [ 25.691734][ T228] memcpy+0x25/0x60 [ 25.692000][ T228] copy_from_bpfptr+0x21/0x30 [ 25.692328][ T228] bpf_prog_load+0x604/0x9e0 [ 25.692653][ T228] ? cap_capable+0xb4/0xe0 [ 25.692956][ T228] ? security_capable+0x4f/0x70 [ 25.693324][ T228] __sys_bpf+0x3af/0x580 [ 25.693635][ T228] bpf_sys_bpf+0x45/0x240 [ 25.693937][ T228] bpf_prog_f0ec79a5a3caca46_bpf_func1+0xa2/0xbd [ 25.694394][ T228] bpf_prog_run_pin_on_cpu+0x2f/0xb0 [ 25.694756][ T228] bpf_prog_test_run_syscall+0x146/0x1c0 [ 25.695144][ T228] bpf_prog_test_run+0x172/0x190 [ 25.695487][ T228] __sys_bpf+0x2c5/0x580 [ 25.695776][ T228] __x64_sys_bpf+0x3a/0x50 [ 25.696084][ T228] do_syscall_64+0x60/0x90 [ 25.696393][ T228] ? fpregs_assert_state_consistent+0x50/0x60 [ 25.696815][ T228] ? exit_to_user_mode_prepare+0x36/0xa0 [ 25.697202][ T228] ? syscall_exit_to_user_mode+0x20/0x40 [ 25.697586][ T228] ? do_syscall_64+0x6e/0x90 [ 25.697899][ T228] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 25.698312][ T228] RIP: 0033:0x7f6d543fb759 [ 25.698624][ T228] Code: 08 5b 89 e8 5d c3 66 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/ttm: Se corrige el error de deref de resolución ficticia NULL ptr. Verifique el valor de bo->resource antes de acceder al recurso mem_type. v2: Se corrige la advertencia de descripción de confirmación sin envolver [ 40.191227][ T184] Fallo de protección general, probablemente para la dirección no canónica 0xdffffc0000000002: 0000 [#1] SMP KASAN PTI [ 40.192995][ T184] KASAN: null-ptr-deref en el rango [0x0000000000000010-0x0000000000000017] [ 40.194411][ T184] CPU: 1 PID: 184 Comm: systemd-udevd No contaminado 5.19.0-rc4-00721-gb297c22b7070 #1 [ 40.196063][ T184] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 01/04/2014 [ 40.199605][ T184] RIP: 0010:ttm_bo_validate+0x1b3/0x240 [ttm] [ 40.200754][ T184] Código: e8 72 c5 ff ff 83 f8 b8 74 d4 85 c0 75 54 49 8b 9e 58 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 10 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 04 3c 03 7e 44 8b 53 10 31 c0 85 d2 0f 85 58 [ 40.203685][ T184] RSP: 0018:ffffc900006df0c8 EFLAGS: 00010202 [ 40.204630][ T184] RAX: dffffc0000000000 RBX: 00000000000000000 RCX: 1ffff1102f4bb71b [ 40.205864][ T184] RDX: 00000000000000002 RSI: ffffc900006df208 I+D+i: 0000000000000010 [ 40.207102][ T184] RBP: 1ffff920000dbe1a R08: ffffc900006df208 R09: 0000000000000000 [ 40.208394][ T184] R10: ffff88817a5f0000 R11: 0000000000000001 R12: ffffc900006df110 [ 40.209692][ T184] R13: ffffc900006df0f0 R14: ffff88817a5db800 R15: ffffc900006df208 [ 40.210862][ T184] FS: 00007f6b1d16e8c0(0000) GS:ffff88839d700000(0000) knlGS:0000000000000000 [ 40.212250][ T184] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 40.213275][ T184] CR2: 000055a1001d4ff0 CR3: 00000001700f4000 CR4: 00000000000006e0 [ 40.214469][ T184] Rastreo de llamadas: [ 40.214974][ T184] [ 40.215438][ T184] ? ttm_bo_bounce_temp_buffer+0x140/0x140 [ttm] [ 40.216572][ T184] ? mutex_spin_on_owner+0x240/0x240 [ 40.217456][ T184] ? drm_vma_offset_add+0xaa/0x100 [drm] [ 40.218457][ T184] ttm_bo_init_reserved+0x3d6/0x540 [ttm] [ 40.219410][ T184] ? shmem_get_inode+0x744/0x980 [ 40.220231][ T184] ttm_bo_init_validate+0xb1/0x200 [ttm] [ 40.221172][ T184] ? bo_driver_evict_flags+0x340/0x340 [drm_vram_helper] [ 40.222530][ T184] ? ttm_bo_init_reserved+0x540/0x540 [ttm] [ 40.223643][ T184] ? __do_sys_finit_module+0x11a/0x1c0 [ 40.224654][ T184] ? __shmem_file_setup+0x102/0x280 [ 40.234764][ T184] drm_gem_vram_create+0x305/0x480 [drm_vram_helper] [ 40.235766][ T184] ? bo_driver_evict_flags+0x340/0x340 [drm_vram_helper] [ 40.236846][ T184] ? __kasan_slab_free+0x108/0x180 [ 40.237650][ T184] drm_gem_vram_fill_create_dumb+0x134/0x340 [drm_vram_helper] [ 40.238864][ T184] ? local_pci_probe+0xdf/0x180 [ 40.239674][ T184] ? drmm_vram_helper_init+0x400/0x400 [drm_vram_helper] [ 40.240826][ T184] drm_client_framebuffer_create+0x19c/0x400 [drm] [ 40.241955][ T184] ? drm_client_buffer_delete+0x200/0x200 [drm] [ 40.243001][ T184] ? drm_client_pick_crtcs+0x554/0xb80 [drm] [ 40.244030][ T184] drm_fb_helper_generic_probe+0x23f/0x940 [drm_kms_helper] [ 40.245226][ T184] ? __cond_resched+0x1c/0xc0 [ 40.245987][ T184] ? drm_fb_helper_memory_range_to_clip+0x180/0x180 [drm_kms_helper] [ 40.247316][ T184] ? mutex_unlock+0x80/0x100 [ 40.248005][ T184] ? __mutex_unlock_slowpath+0x2c0/0x2c0 [ 40.249083][ T184] drm_fb_helper_single_fb_probe+0x907/0xf00 [drm_kms_helper] [ 40.250314][ T184] ? drm_fb_helper_check_var+0x1180/0x1180 [drm_kms_helper] [ 40.251540][ T184] ? __cond_resched+0x1c/0xc0 [ 40.252321][ T184] ? mutex_lock+0x9f/0x100 [ 40.253062][ T184] __drm_fb_helper_initial_config_and_unlock+0xb9/0x2c0 [drm_kms_helper] [ 40.254394][ T184] drm_fbdev_client_hotplug+0x56f/0x840 [drm_kms_helper] [ 40.255477][ T184] drm_fbdev_generic_setup+0x165/0x3c0 [drm_kms_helper] [ 40.256607][ T184] bochs_pci_probe+0x6b7/0x900 [bochs] [ ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: anular el control de reubicación si falla el commit de la transacción en prepare_to_relocate(). En btrfs_relocate_block_group(), se asigna el rc. Luego, btrfs_relocate_block_group() llama a relocate_block_group() prepare_to_relocate() set_reloc_control() que asigna rc a la variable fs_info->reloc_ctl. Cuando prepare_to_relocate() retorna, llama a btrfs_commit_transaction() btrfs_start_dirty_block_groups() btrfs_alloc_path() kmem_cache_zalloc() que puede fallar, por ejemplo (o podrían ocurrir otros errores). Cuando ocurre el fallo, btrfs_relocate_block_group() detecta el error y libera rc y no establece fs_info->reloc_ctl en NULL. Posteriormente, en btrfs_init_reloc_root(), se recupera rc de fs_info->reloc_ctl y se utiliza, lo que podría causar un error de Use-After-Free. Este posible error se puede activar llamando a btrfs_ioctl_balance() antes de llamar a btrfs_ioctl_defrag(). Para corregir este posible error, en prepare_to_relocate(), compruebe si btrfs_commit_transaction() falla. Si falla, se llama a unset_reloc_control() para establecer fs_info->reloc_ctl en NULL. El registro de errores en nuestras pruebas de inyección de fallas se muestra a continuación: [ 58.751070] ERROR: KASAN: use-after-free en btrfs_init_reloc_root+0x7ca/0x920 [btrfs] ... [ 58.753577] Seguimiento de llamadas: ... [ 58.755800] kasan_report+0x45/0x60 [ 58.756066] btrfs_init_reloc_root+0x7ca/0x920 [btrfs] [ 58.757304] record_root_in_trans+0x792/0xa10 [btrfs] [ 58.757748] btrfs_record_root_in_trans+0x463/0x4f0 [btrfs] [ 58.758231] start_transaction+0x896/0x2950 [btrfs] [ 58.758661] btrfs_defrag_root+0x250/0xc00 [btrfs] [ 58.759083] btrfs_ioctl_defrag+0x467/0xa00 [btrfs] [ 58.759513] btrfs_ioctl+0x3c95/0x114e0 [btrfs] ... [ 58.768510] Asignado por la tarea 23683: [ 58.768777] ____kasan_kmalloc+0xb5/0xf0 [ 58.769069] __kmalloc+0x227/0x3d0 [ 58.769325] alloc_reloc_control+0x10a/0x3d0 [btrfs] [ 58.769755] btrfs_relocate_block_group+0x7aa/0x1e20 [btrfs] [ 58.770228] btrfs_relocate_chunk+0xf1/0x760 [btrfs] [ 58.770655] __btrfs_balance+0x1326/0x1f10 [btrfs] [ 58.771071] btrfs_balance+0x3150/0x3d30 [btrfs] [ 58.771472] btrfs_ioctl_balance+0xd84/0x1410 [btrfs] [ 58.771902] btrfs_ioctl+0x4caa/0x114e0 [btrfs] ... [ 58.773337] Liberado por la tarea 23683: ... [ 58.774815] kfree+0xda/0x2b0 [ 58.775038] free_reloc_control+0x1d6/0x220 [btrfs] [ 58.775465] btrfs_relocate_block_group+0x115c/0x1e20 [btrfs] [ 58.775944] btrfs_relocate_chunk+0xf1/0x760 [btrfs] [ 58.776369] __btrfs_balance+0x1326/0x1f10 [btrfs] [ 58.776784] btrfs_balance+0x3150/0x3d30 [btrfs] [ 58.777185] btrfs_ioctl_balance+0xd84/0x1410 [btrfs] [ 58.777621] btrfs_ioctl+0x4caa/0x114e0 [btrfs] ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: atlantic: corrección del error de índice fuera de rango de aq_vec. La última instrucción de actualización del bucle for excede el rango de la matriz, por lo que no se verifica la desreferencia de self->aq_vec[i], lo que genera el error de índice fuera de rango. También se corrigió este tipo de estilo de codificación en otro bucle for. [ 97.937604] UBSAN: índice de matriz fuera de los límites en drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48 [ 97.937607] el índice 8 está fuera de rango para el tipo 'aq_vec_s *[8]' [ 97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 No contaminado 5.19.0+ #2 [ 97.937610] Nombre del hardware: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 12/06/2022 [ 97.937611] Cola de trabajo: events_unbound async_run_entry_fn [ 97.937616] Seguimiento de llamadas: [ 97.937617] [ 97.937619] dump_stack_lvl+0x49/0x63 [ 97.937624] dump_stack+0x10/0x16 [ 97.937626] ubsan_epilogue+0x9/0x3f [ 97.937627] __ubsan_handle_out_of_bounds.cold+0x44/0x49 [ 97.937629] ? __scm_send+0x348/0x440 [ 97.937632] ? aq_vec_stop+0x72/0x80 [atlántico] [ 97.937639] aq_nic_stop+0x1b6/0x1c0 [atlántico] [ 97.937644] aq_suspend_common+0x88/0x90 [atlántico] [ 97.937648] aq_pm_suspend_poweroff+0xe/0x20 [atlántico] [ 97.937653] pci_pm_suspend+0x7e/0x1a0 [ 97.937655] ? pci_pm_suspend_noirq+0x2b0/0x2b0 [ 97.937657] dpm_run_callback+0x54/0x190 [ 97.937660] __device_suspend+0x14c/0x4d0 [ 97.937661] async_suspend+0x23/0x70 [ 97.937663] async_run_entry_fn+0x33/0x120 [ 97.937664] process_one_work+0x21f/0x3f0 [ 97.937666] work_thread+0x4a/0x3c0 [ 97.937668] ? process_one_work+0x3f0/0x3f0 [ 97.937669] kthread+0xf0/0x120 [ 97.937671] ? kthread_complete_and_exit+0x20/0x20 [ 97.937672] ret_from_fork+0x22/0x30 [ 97.937676] v2. Se corrigió la "advertencia: variable 'aq_vec' establecida pero no utilizada". v3. Se simplificó un bucle for.