Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de fuga de lista de inodos durante el recorrido de backref en resolve_indirect_refs() Durante el recorrido de backref, en resolve_indirect_refs(), si obtenemos un error saltamos a la etiqueta 'out' y llamamos a ulist_free() en la ulist 'parents', que libera todos los elementos en la ulist - sin embargo, eso no libera ninguna lista de inodos que pueda estar adjunta a elementos, a través del campo 'aux' de un nodo ulist, por lo que terminamos filtrando listas si tenemos alguna adjunta a los unodes. Arregle esto llamando a free_leaf_list() en lugar de ulist_free() cuando salimos de resolve_indirect_refs(). La función estática free_leaf_list() se mueve hacia arriba para que esto sea posible y se simplifica ligeramente eliminando código innecesario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: L2CAP: corrección de use-after-free en l2cap_conn_del(). Cuando se invoca l2cap_recv_frame() para recibir datos y el CID es L2CAP_CID_A2MP, si el canal no existe, se crea uno. Sin embargo, una vez creado el canal, no se realiza la operación de retención. En este caso, el valor del recuento de referencias del canal es 1. Como resultado, tras la activación de hci_error_reset(), l2cap_conn_del() invoca la función de cierre de A2MP para liberar el canal. Entonces, l2cap_chan_unlock(chan) activará el problema de UAF. El proceso es el siguiente: Recibir datos: l2cap_data_channel() a2mp_channel_create() --->la referencia del canal es 2 l2cap_chan_put() --->la referencia del canal es 1 Evento desencadenador: hci_error_reset() hci_dev_do_close() ... l2cap_disconn_cfm() l2cap_conn_del() l2cap_chan_hold() --->la referencia del canal es 2 l2cap_chan_del() --->la referencia del canal es 1 a2mp_chan_close_cb() --->la referencia del canal es 0, liberar el canal l2cap_chan_unlock() --->UAF del canal El seguimiento de llamadas detallado es el siguiente: ERROR: KASAN: use-after-free en __mutex_unlock_slowpath+0xa6/0x5e0 Lectura de tamaño 8 en la dirección ffff8880160664b8 por la tarea kworker/u11:1/7593 Cola de trabajo: hci0 Rastreo de llamadas hci_error_reset: dump_stack_lvl+0xcd/0x134 print_report.cold+0x2ba/0x719 kasan_report+0xb1/0x1e0 kasan_check_range+0x140/0x190 __mutex_unlock_slowpath+0xa6/0x5e0 l2cap_conn_del+0x404/0x7b0 l2cap_disconn_cfm+0x8c/0xc0 hci_conn_hash_flush+0x11f/0x260 hci_dev_close_sync+0x5f5/0x11f0 hci_dev_do_close+0x2d/0x70 hci_error_reset+0x9e/0x140 process_one_work+0x98a/0x1620 worker_thread+0x665/0x1080 kthread+0x2e4/0x3a0 ret_from_fork+0x1f/0x30 Allocated by task 7593: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0xa9/0xd0 l2cap_chan_create+0x40/0x930 amp_mgr_create+0x96/0x990 a2mp_channel_create+0x7d/0x150 l2cap_recv_frame+0x51b8/0x9a70 l2cap_recv_acldata+0xaa3/0xc00 hci_rx_work+0x702/0x1220 process_one_work+0x98a/0x1620 worker_thread+0x665/0x1080 kthread+0x2e4/0x3a0 ret_from_fork+0x1f/0x30 Freed by task 7593: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_set_free_info+0x20/0x30 ____kasan_slab_free+0x167/0x1c0 slab_free_freelist_hook+0x89/0x1c0 kfree+0xe2/0x580 l2cap_chan_put+0x22a/0x2d0 l2cap_conn_del+0x3fc/0x7b0 l2cap_disconn_cfm+0x8c/0xc0 hci_conn_hash_flush+0x11f/0x260 hci_dev_close_sync+0x5f5/0x11f0 hci_dev_do_close+0x2d/0x70 hci_error_reset+0x9e/0x140 process_one_work+0x98a/0x1620 worker_thread+0x665/0x1080 kthread+0x2e4/0x3a0 ret_from_fork+0x1f/0x30 Last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0xbe/0xd0 call_rcu+0x99/0x740 netlink_release+0xe6a/0x1cf0 __sock_release+0xcd/0x280 sock_close+0x18/0x20 __fput+0x27c/0xa90 task_work_run+0xdd/0x1a0 exit_to_user_mode_prepare+0x23c/0x250 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x42/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Second to last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0xbe/0xd0 call_rcu+0x99/0x740 netlink_release+0xe6a/0x1cf0 __sock_release+0xcd/0x280 sock_close+0x18/0x20 __fput+0x27c/0xa90 task_work_run+0xdd/0x1a0 exit_to_user_mode_prepare+0x23c/0x250 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x42/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd

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]