Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-mq: Se corrige kmemleak en blk_mq_init_allocated_queue Hay una kmemleak causada por modprobe null_blk.ko objeto no referenciado 0xffff8881acb1f000 (tamaño 1024): comm "modprobe", pid 836, jiffies 4294971190 (edad 27.068s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S...... backtrace: [<000000004a10c249>] kmalloc_node_trace+0x22/0x60 [<00000000648f7950>] blk_mq_alloc_and_init_hctx+0x289/0x350 [<00000000af06de0e>] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0 [<00000000e00c1872>] blk_mq_init_allocated_queue+0x48c/0x1440 [<00000000d16b4e68>] __blk_mq_alloc_disk+0xc8/0x1c0 [<00000000d10c98c3>] 0xffffffffc450d69d [<00000000b9299f48>] 0xffffffffc4538392 [<0000000061c39ed6>] hacer_una_llamada_inicio+0xd0/0x4f0 [<00000000b389383b>] hacer_módulo_inicio+0x1a4/0x680 [<0000000087cf3542>] cargar_módulo+0x6249/0x7110 [<00000000beba61b8>] __hacer_módulo_finit_sys+0x140/0x200 [<00000000fdcfff51>] hacer_llamada_al_sistema_64+0x35/0x80 [<000000003c0f1f71>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Esto se debe a que q->ma_ops se establece en NULL antes de llamar a blk_release_queue. blk_mq_init_queue_data blk_mq_init_allocated_queue blk_mq_realloc_hw_ctxs para (i = 0; i < set->nr_hw_queues; i++) { old_hctx = xa_load(&q->hctx_table, i); si (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1] si (!old_hctx) break; xa_for_each_start(&q->hctx_table, j, hctx, j) blk_mq_exit_hctx(q, set, hctx, j); [2] if (!q->nr_hw_queues) [3] goto err_hctxs; err_exit: q->mq_ops = NULL; [4] blk_put_queue blk_release_queue if (queue_is_mq(q)) [5] blk_mq_release(q); [1]: blk_mq_alloc_and_init_hctx falló en i != 0. [2]: Los hctxs asignados por [1] se mueven a q->unused_hctx_list y se limpiarán en blk_mq_release. [3]: q->nr_hw_queues es 0. [4]: Establece q->mq_ops en NULL. [5]: queue_is_mq devuelve falso debido a [4]. No se llamará a blk_mq_release. Los hctxs en q->unused_hctx_list tienen fugas. Para solucionarlo, llame a blk_release_queue en la ruta de excepción.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: Reparar posible pérdida de memoria para rq_wb en caso de error de add_disk kmemleak informó pérdidas de memoria en device_add_disk(): kmemleak: 3 nuevas pérdidas de memoria sospechosas objeto no referenciado 0xffff88800f420800 (tamaño 512): comm "modprobe", pid 4275, jiffies 4295639067 (edad 223.512s) volcado hexadecimal (primeros 32 bytes): 04 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00 00 ................ 00 e1 f5 05 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d3662699>] kmalloc_trace+0x26/0x60 [<00000000edc7aadc>] wbt_init+0x50/0x6f0 [<0000000069601d16>] wbt_enable_default+0x157/0x1c0 [<0000000028fc393f>] blk_register_queue+0x2a4/0x420 [<000000007345a042>] device_add_disk+0x6fd/0xe40 [<0000000060e6aab0>] nbd_dev_add+0x828/0xbf0 [nbd] ... Esto se debe a que la memoria asignada en wbt_enable_default() no se libera en la ruta de error device_add_disk(). Normalmente, esta memoria se libera en: del_gendisk() rq_qos_exit() rqos->ops->exit(rqos); wbt_exit(). Por lo tanto, se llama a rq_qos_exit() para liberar la memoria rq_wb para wbt_init(). Sin embargo, en la ruta de error de device_add_disk(), solo se llama a blk_unregister_queue(), lo que provoca una fuga de memoria en rq_wb. Agregue rq_qos_exit() a la ruta de error para corregirlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net, neigh: Fix null-ptr-deref en neigh_table_clear() Cuando se inicializa un módulo IPv6 pero se produce un error en el medio, kenel entra en pánico con: KASAN: null-ptr-deref en el rango [0x0000000000000598-0x000000000000059f] CPU: 1 PID: 361 Comm: insmod Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:__neigh_ifdown.isra.0+0x24b/0x370 RSP: 0018:ffff888012677908 EFLAGS: 00000202 ... Seguimiento de llamadas: neigh_table_clear+0x94/0x2d0 ndisc_cleanup+0x27/0x40 [ipv6] inet6_init+0x21c/0x2cb [ipv6] do_one_initcall+0xd3/0x4d0 do_init_module+0x1ae/0x670 ... Pánico del kernel - no sincroniza: Excepción fatal Cuando falla la inicialización de ipv6, intentará limpiar y llamará a: neigh_table_clear() neigh_ifdown(tbl, NULL) pneigh_queue_purge(&tbl->proxy_queue, dev_net(dev == NULL)) # dev_net(NULL) activa null-ptr-deref. Corríjalo pasando NULL a pneigh_queue_purge() en neigh_ifdown() si dev es NULL, para que el kernel no entre en pánico inmediatamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ibmvnic: Liberar rwi al reiniciarse correctamente. Libera la estructura rwi si el último rwi de la lista se ha procesado correctamente. La lógica del commit 4f408e1fa6e1 ("ibmvnic: reintentar reiniciar si no hay otros reinicios") genera un problema que provoca una pérdida de memoria de 32 bytes cada vez que se procesa el último rwi de la lista.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: L2CAP: Se corrige la pérdida de memoria en vhci_write Syzkaller informa de una pérdida de memoria de la siguiente manera: ===================================== ERROR: pérdida de memoria del objeto no referenciado 0xffff88810d81ac00 (tamaño 240): [...] volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] __alloc_skb+0x1f9/0x270 net/core/skbuff.c:418 [] alloc_skb include/linux/skbuff.h:1257 [en línea] [] bt_skb_alloc include/net/bluetooth/bluetooth.h:469 [en línea] [] vhci_get_user drivers/bluetooth/hci_vhci.c:391 [en línea] [] vhci_write+0x5f/0x230 drivers/bluetooth/hci_vhci.c:511 [] call_write_iter include/linux/fs.h:2192 [en línea] [] new_sync_write fs/read_write.c:491 [en línea] [] vfs_write+0x42d/0x540 fs/read_write.c:578 [] ksys_write+0x9d/0x160 fs/read_write.c:631 [] do_syscall_x64 arch/x86/entry/common.c:50 [en línea] [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd ====================================== El núcleo HCI utiliza hci_rx_work() para procesar la trama, que el controlador HCI pone en cola en la cola hdev->rx_q en hci_recv_frame(). Sin embargo, el problema es que el núcleo HCI puede no liberar el skb después de procesar los paquetes de datos ACL. Para ser más específicos, cuando el fragmento de inicio no contiene la longitud L2CAP, el núcleo HCI simplemente copia el skb en conn->rx_skb y finaliza el procesamiento de la trama en l2cap_recv_acldata(), sin liberar el skb, lo que desencadena la pérdida de memoria mencionada anteriormente. Este parche lo resuelve liberando el skb relativo, después de procesar el caso mencionado en l2cap_recv_acldata().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: piix4: Adaptador de corrección que no se eliminará en piix4_remove() En piix4_probe(), el adaptador piix4 se registrará en: piix4_probe() piix4_add_adapters_sb800() / piix4_add_adapter() i2c_add_adapter() En función del tipo de dispositivo sondeado, se llamará a piix4_add_adapters_sb800() o a un solo piix4_add_adapter(). Para el primer caso, piix4_adapter_count se establece como el número de adaptadores, mientras que para otro caso no se establece y se mantiene predeterminado *cero*. Cuando se elimina piix4, piix4_remove() elimina los adaptadores agregados en piix4_probe(), basándose en el valor de piix4_adapter_count. Dado que el conteo es cero en el caso de un solo adaptador, este no se eliminará y se filtrarán las fuentes asignadas, como el cliente y el dispositivo i2c. Estas fuentes aún pueden ser accedidas por i2c o el bus, lo que puede causar problemas. Un caso que se reproduce fácilmente es que si se registra un nuevo adaptador, i2c obtendrá el adaptador filtrado e intentará llamar a smbus_algorithm, que ya se había liberado: Activado por: rmmod i2c_piix4 y modprobe max31730 ERROR: no se puede controlar el error de página para la dirección: ffffffffc053d860 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 3752 Comm: modprobe Tainted: G Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:i2c_default_probe (drivers/i2c/i2c-core-base.c:2259) i2c_core RSP: 0018:ffff888107477710 EFLAGS: 00000246 ... i2c_detect (controladores/i2c/i2c-core-base.c:2302) i2c_core __process_new_driver (controladores/i2c/i2c-core-base.c:1336) i2c_core bus_for_each_dev (controladores/base/bus.c:301) i2c_for_each_dev (controladores/i2c/i2c-core-base.c:1823) i2c_core i2c_register_driver (controladores/i2c/i2c-core-base.c:1861) i2c_core do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... ---[ fin del seguimiento 0000000000000000 ]--- Solucione este problema configurando correctamente piix4_adapter_count como 1 para el adaptador único de modo que se pueda quitar normalmente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mdio: corrige comportamiento indefinido en el desplazamiento de bits para __mdiobus_register El desplazamiento de un valor de 32 bits con signo en 31 bits no está definido, por lo que se cambia el bit significativo a sin signo. El seguimiento de llamadas de advertencia de UBSAN como se muestra a continuación: UBSAN: desplazamiento fuera de los límites en drivers/net/phy/mdio_bus.c:586:27 El desplazamiento a la izquierda de 1 por 31 lugares no se puede representar en el tipo 'int' Seguimiento de llamadas: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c __mdiobus_register+0x49d/0x4e0 fixed_mdio_bus_init+0xd8/0x12d do_one_initcall+0x76/0x430 kernel_init_freeable+0x3b3/0x422 kernel_init+0x24/0x1e0 ret_from_fork+0x1f/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: Se corrige una posible fuga de espacio de nombres pernet en smc_init(). En smc_init(), se llama a register_pernet_subsys(&smc_net_stat_ops) sin gestionar errores. Si falla, el registro de &smc_net_ops no se revertirá. Y si smc_nl_init() falla, &smc_net_stat_ops no se revertirá. Esto deja operaciones salvajes en la lista enlazada del subsistema y cuando otro módulo intenta llamar a register_pernet_operations() desencadena un error de página: ERROR: no se puede manejar el error de página para la dirección: fffffbfff81b964c RIP: 0010:register_pernet_operations+0x1b9/0x5f0 Rastreo de llamada: register_pernet_subsys+0x29/0x40 ebtables_init+0x58/0x1000 [ebtables] ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: corrección de una advertencia en ip6_route_net_exit_late(). Durante la inicialización de ip6_route_net_init_late(), si no se crea el archivo ipv6_route o rt6_stats, la inicialización se realiza correctamente por defecto. Por lo tanto, no se encuentra el archivo ipv6_route o rt6_stats durante la eliminación en ip6_route_net_exit_late(). Esto provocará una advertencia. La siguiente es la información de la pila: nombre 'rt6_stats' ADVERTENCIA: CPU: 0 PID: 9 en fs/proc/generic.c:712 remove_proc_entry+0x389/0x460 Módulos vinculados: Cola de trabajo: netns cleanup_net RIP: 0010:remove_proc_entry+0x389/0x460 PKRU: 55555554 Seguimiento de llamadas: ops_exit_list+0xb0/0x170 cleanup_net+0x4ea/0xb00 process_one_work+0x9bf/0x1710 workers_thread+0x665/0x1080 kthread+0x2e4/0x3a0 ret_from_fork+0x1f/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: capacidades: reparar posible fuga de memoria en la ruta de error de vfs_getxattr_alloc() En cap_inode_getsecurity(), utilizaremos vfs_getxattr_alloc() para completar la asignación de memoria de tmpbuf, si hemos completado la asignación de memoria de tmpbuf, pero no pudimos llamar a handler->get(...), habrá una fuga de memoria en la siguiente lógica: |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ asignar para tmpbuf */ |-- valor = krealloc(*xattr_value, error + 1, flags) | /* ^^^ asignar memoria */ |-- error = handler->get(handler, ...) | /* ¡error! */ |-- *xattr_value = valor | /* xattr_value es &tmpbuf (¡pérdida de memoria!) */ Intentaremos liberar (tmpbuf) después de que vfs_getxattr_alloc() no pueda solucionarlo. [MP: línea de asunto y ajustes de backtrace]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: kprobe: Se corrige la fuga de memoria en test_gen_kprobe/kretprobe_cmd(). test_gen_kprobe_cmd() solo libera búfer en la ruta de fallo, por lo que el búfer se filtrará cuando no haya fallo. Se traslada kfree(buf) de la ruta de fallo a la ruta común para evitar la fuga de memoria. El mismo motivo y solución se aplican en test_gen_kretprobe_cmd(). Objeto sin referencia 0xffff888143b14000 (size 2048): comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s) hex dump (first 32 bytes): 70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp 72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys backtrace: [<000000006d7b836b>] kmalloc_trace+0x27/0xa0 [<0000000009528b5b>] 0xffffffffa059006f [<000000008408b580>] do_one_initcall+0x87/0x2a0 [<00000000c4980a7e>] do_init_module+0xdf/0x320 [<00000000d775aad0>] load_module+0x3006/0x3390 [<00000000e9a74b80>] __do_sys_finit_module+0x113/0x1b0 [<000000003726480d>] do_syscall_64+0x35/0x80 [<000000003441e93b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftrace: Arreglo de use-after-free para ftrace_ops dinámicos KASAN informó de un use-after-free con operaciones ftrace [1]. Se encontró desde vmcore que perf había registrado dos operaciones con el mismo contenido sucesivamente, ambas dinámicas. Después de anular el registro de la segunda operación, se produjo un use-after-free. En ftrace_shutdown(), cuando se anula el registro de la segunda operación, el comando FTRACE_UPDATE_CALLS no se establece porque hay otra operación habilitada con el mismo contenido. Además, ambas operaciones son dinámicas y la función de devolución de llamada de ftrace es ftrace_ops_list_func, por lo que el comando FTRACE_UPDATE_TRACE_FUNC no se establecerá. Finalmente, el valor de 'command' será 0 y ftrace_shutdown() omitirá la sincronización de rcu. Sin embargo, ftrace puede estar activado. Cuando se libera la operación, otra CPU puede estar accediendo a ella. Agregue la sincronización faltante para solucionar este problema. [1] ERROR: KASAN: use-after-free en __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [en línea] ERROR: KASAN: use-after-free en ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 Lectura de tamaño 8 en la dirección ffff56551965bbc8 por la tarea syz-executor.2/14468 CPU: 1 PID: 14468 Comm: syz-executor.2 No contaminado 5.10.0 #7 Nombre del hardware: linux,dummy-virt (DT) Rastreo de llamadas: dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132 show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [en línea] dump_stack+0x1b4/0x248 lib/dump_stack.c:118 print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387 __kasan_report mm/kasan/report.c:547 [en línea] kasan_report+0x118/0x210 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [en línea] __asan_load8+0x98/0xc0 mm/kasan/generic.c:253 __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [en línea] ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 ftrace_graph_call+0x0/0x4 __might_sleep+0x8/0x100 include/linux/perf_event.h:1170 __might_fault mm/memory.c:5183 [en línea] __might_fault+0x58/0x70 mm/memory.c:5171 do_strncpy_from_user lib/strncpy_from_user.c:41 [en línea] strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139 getname_flags+0xb0/0x31c fs/namei.c:149 getname+0x2c/0x40 fs/namei.c:209 [...] Asignado por la tarea 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [en línea] __kasan_kmalloc mm/kasan/common.c:479 [en línea] __kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493 kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950 kmalloc include/linux/slab.h:563 [en línea] kzalloc include/linux/slab.h:675 [en línea] perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230 perf_event_alloc kernel/events/core.c:11733 [en línea] __do_sys_perf_event_open kernel/events/core.c:11831 [en línea] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 __arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723 [...] Liberado por la tarea 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track+0x24/0x34 mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358 __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437 __kasan_slab_free mm/kasan/common.c:445 [en línea] kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446 slab_free_hook mm/slub.c:1569 [en línea] slab_free_freelist_hook mm/slub.c:1608 [en línea] slab_free mm/slub.c:3179 [en línea] kfree+0x12c/0xc10 mm/slub.c:4176 perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434 perf_event_alloc kernel/events/core.c:11733 [en línea] __do_sys_perf_event_open kernel/events/core.c:11831 [en línea] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 [...]