Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gfs2: corrige use-after-free en gfs2_glock_shrink_scan. El indicador GLF_LRU se marca en lru_lock en gfs2_glock_remove_from_lru() para eliminar el glock de la lista lru en __gfs2_glock_put(). En la ruta de escaneo de reducción, la misma bandera se borra en lru_lock pero debido a cond_resched_lock(&lru_lock) en gfs2_dispose_glock_lru(), se puede avanzar en el lado de venta sin eliminar la glock de la lista de lru. Mantenga GLF_LRU en la ventana de ejecución abierta por cond_resched_lock(&lru_lock) para garantizar un comportamiento correcto en ambos lados; borre GLF_LRU después de list_del en lru_lock.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ipv4: corrige la pérdida de memoria en ip_mc_add1_src. BUG: pérdida de memoria objeto sin referencia 0xffff888101bc4c00 (tamaño 32): comm "syz-executor527", pid 360, jiffies 4294807421 (edad 19.329s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 01 00 00 00 00 00 00 00 ac 14 14 bb 00 00 02 00 ................ backtrace: [<00000000f17c5244>] kmalloc include/linux/slab.h:558 [en línea] [<00000000f17c5244>] kzalloc include/ linux/slab.h:688 [en línea] [<00000000f17c5244>] ip_mc_add1_src net/ipv4/igmp.c:1971 [en línea] [<00000000f17c5244>] ip_mc_add_src+0x95f/0xdb0 net/ipv4/igmp.c:2095 <000000001cb99709 >] ip_mc_source+0x84c/0xea0 net/ipv4/igmp.c:2416 [<0000000052cf19ed>] do_ip_setsockopt net/ipv4/ip_sockglue.c:1294 [en línea] [<0000000052cf19ed>] 0net/ipv4/ip_sockglue. c:1423 [<00000000477edfbc>] raw_setsockopt+0x13d/0x170 net/ipv4/raw.c:857 [<00000000e75ca9bb>] __sys_setsockopt+0x158/0x270 net/socket.c:2117 [<00000000bdb993 a8>] __do_sys_setsockopt net/socket.c :2128 [en línea] [<00000000bdb993a8>] __se_sys_setsockopt net/socket.c:2125 [en línea] [<00000000bdb993a8>] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2125 [<000000006a 1ffdbd>] do_syscall_64+0x40/0x80 arch/ x86/entry/common.c:47 [<00000000b11467c4>] Entry_SYSCALL_64_after_hwframe+0x44/0xae En la confirmación 24803f38a5c0 ("igmp: no eliminar la información de la lista de fuentes de igmp cuando se establece el enlace"), se eliminó ip_mc_clear_src() en ip_mc_destroy_dev() , porque también fue llamado en igmpv3_clear_delrec(). Gráfico de llamada aproximado: inetdev_destroy -> ip_mc_destroy_dev -> igmpv3_clear_delrec -> ip_mc_clear_src -> RCU_INIT_POINTER(dev->ip_ptr, NULL) Sin embargo, ip_mc_clear_src() llamado en igmpv3_clear_delrec() no libera in_dev->mc_list->sources. Y RCU_INIT_POINTER() asigna NULL a dev->ip_ptr. Como resultado, in_dev no se puede obtener a través de inetdev_by_index() y luego in_dev->mc_list->sources no se puede liberar mediante ip_mc_del1_src() en sock_close. La secuencia de llamada aproximada es así: sock_close -> __sock_release -> inet_release -> ip_mc_drop_socket -> inetdev_by_index -> ip_mc_leave_src -> ip_mc_del_src -> ip_mc_del1_src Entonces todavía necesitamos llamar a ip_mc_clear_src() en ip_mc_destroy_dev() para liberar in_dev->mc_list ->fuentes .

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net:usb: corrige posible use after free en smsc75xx_bind. La confirmación 46a8b29c6306 ("net:usb: corrige la pérdida de memoria en smsc75xx_bind") no logra limpiar el trabajo programado en smsc75xx_reset -> smsc75xx_set_multicast, lo que genera use after free si el trabajo está programado para comenzar después de la desasignación. Además, este parche también elimina un puntero colgante: dev->data[0]. Este parche llama a cancel_work_sync para cancelar el trabajo programado y establecer el puntero colgante en NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: qrtr: arreglar OOB Lectura en qrtr_endpoint_post. Syzbot reportó slab-out-of-bounds Lectura en qrtr_endpoint_post. El problema estaba en el tipo de _tamaño_ incorrecto: if (len != ALIGN(size, 4) + hdrlen) goto err; Si el tamaño de qrtr_hdr es 4294967293 (0xfffffffd), el resultado de ALIGN(size, 4) será 0. En caso de len == hdrlen y size == 4294967293 en el encabezado, esta verificación no fallará y skb_put_data(skb, data + hdrlen, tamaño); leerá fuera de los límites de los datos, que son bloques asignados hdrlen.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ethtool: strset: corrección del cálculo de la longitud del mensaje. No se tiene en cuenta el nido externo para ETHTOOL_A_STRSET_STRINGSETS. Esto puede provocar que ETHTOOL_MSG_STRSET_GET produzca una advertencia como: la longitud calculada de el payload del mensaje (684) no es suficiente ADVERTENCIA: CPU: 0 PID: 30967 en net/ethtool/netlink.c:369 ethnl_default_doit+0x87a/0xa20 y un símbolo. Como suele ocurrir con este tipo de advertencias, se deben cumplir tres condiciones para que se active la advertencia: - no debe haber ningún tamaño de skb redondeado hacia arriba (por ejemplo, tamaño_respuesta de 684); - el conjunto de cadenas debe ser por dispositivo (para que se complete el encabezado); - el nombre del dispositivo debe tener al menos 12 caracteres. Con todo, con el espacio de usuario actual, parece que leer indicadores privados es el único lugar donde esto podría suceder. O con syzbot :)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mptcp: corrige una búsqueda suave en subflow_error_report(). Maxim informó una búsqueda suave en subflow_error_report(): vigilancia: ERROR: bloqueo suave - ¡CPU#0 bloqueada durante 22 segundos! [swapper/0:0] RIP: 0010:native_queued_spin_lock_slowpath RSP: 0018:ffffa859c0003bc0 EFLAGS: 00000202 RAX: 0000000000000101 RBX: 0000000000000001 RCX: 000000000 0000000 RDX: ffff9195c2772d88 RSI: 0000000000000000 RDI: ffff9195c2772d88 RBP: ffff9195c2772d00 R08: 00000000000067b0 R09: c6e31da9eb1e44f4 :ffff9195ef379700 R11: ffff9195edb50710 R12: ffff9195c2772d88 R13: ffff9195f500e3d0 R14: ffff9195ef379700 R15: ffff9195ef379700 FS: 0000000000000000(0000) 1961f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c000407000 CR3: 0000000002988000 00000000000006f0 Seguimiento de llamadas: _raw_spin_lock_bh subflow_error_report mptcp_subflow_data_available __mptcp_move_skbs_from_subflow mptcp_data_ready tcp_data_queue tcp_rcv_establecido tcp_v4_do_rcv tcp_v4_rcv liver_rcu ip_local_deliver_finish __netif_receive_skb_one_core netif_receive_skb rtl8139_poll 8139too __napi_poll net_rx_action __do_softirq __irq_exit_rcu common_interrupt La función de llamada, mptcp_subflow_data_available(), se puede invocar desde diferentes contextos: - enchufe ssk lock - bloqueo de socket ssk + mptcp_data_lock - bloqueo de socket ssk + mptcp_data_lock + bloqueo de socket msk. Dado que subflow_error_report() intenta adquirir mptcp_data_lock, las dos últimas cadenas de llamadas provocarán una búsqueda suave. Este cambio soluciona el problema de mover la llamada de informe de errores a funciones externas, donde se conoce la lista de bloqueos retenidos y solo podemos adquirir el que necesitamos.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sch_cake: Corrección de límites al analizar las opciones TCP y el encabezado. El analizador de opciones TCP en cake qdisc (cake_get_tcpopt y cake_tcph_may_drop) podía leer un byte fuera de los límites. Cuando la longitud es 1, el flujo de ejecución entra en el bucle, lee un byte del código de operación y, si el código de operación no es TCPOPT_EOL ni TCPOPT_NOP, lee un byte más, que excede la longitud de 1. Esta solución está inspirada en la confirmación. 9609dad263f8 ("ipv4: tcp_input: corrige la pila fuera de los límites al analizar las opciones de TCP"). Cambios en v2: Se agregó validación de doff en cake_get_tcphdr para evitar analizar basura como encabezado TCP. Aunque no era estrictamente un acceso fuera de los límites (se asignó memoria), se podían leer valores basura donde CAKE esperaba el encabezado TCP si doff era menor que 5.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mptcp: corrección de límites al analizar opciones TCP. El analizador de opciones TCP en mptcp (mptcp_get_options) podría leer un byte fuera de los límites. Cuando la longitud es 1, el flujo de ejecución entra en el bucle, lee un byte del código de operación y, si el código de operación no es TCPOPT_EOL ni TCPOPT_NOP, lee un byte más, que excede la longitud de 1. Esta solución está inspirada en la confirmación. 9609dad263f8 ("ipv4: tcp_input: corrige la pila fuera de los límites al analizar las opciones de TCP").

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: synproxy: corrección de límites al analizar opciones TCP. El analizador de opciones TCP en synproxy (synproxy_parse_options) podría leer un byte fuera de los límites. Cuando la longitud es 1, el flujo de ejecución entra en el bucle, lee un byte del código de operación y, si el código de operación no es TCPOPT_EOL ni TCPOPT_NOP, lee un byte más, que excede la longitud de 1. Esta solución está inspirada en la confirmación. 9609dad263f8 ("ipv4: tcp_input: corrige la pila fuera de los límites al analizar las opciones de TCP"). Cambios en v2: se agregó un retorno anticipado cuando la longitud <0 para evitar llamar a skb_header_pointer con una longitud negativa.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: Reparar la recuperación de página para la horquilla del par inactiva. Al agregar un flujo de horquilla, se crea una cola de envío del lado del firmware para el dispositivo de red del par, que reclama algunas páginas de memoria del host para su buffer de anillo interno. Si el dispositivo peer net se elimina/desvincula antes de eliminar el flujo de horquilla, entonces la cola de envío no se destruye, lo que genera un seguimiento de la pila en la eliminación del dispositivo pci: [ 748.005230] mlx5_core 0000:08:00.2: wait_func:1094:(pid 12985): Tiempo de espera de MANAGE_PAGES(0x108). Provocará una fuga de un recurso de comando [748.005231] mlx5_core 0000:08:00.2: reclaim_pages:514:(pid 12985): error al recuperar páginas: err -110 [748.001835] mlx5_core 0000:08:00.2: mlx5_reclaim_root_pages:653:(pid 12985): error al recuperar páginas (-110) para el ID de función 0x0 [748.002171] ------------[ cortar aquí ]------------ [ 748.001177] páginas FW el contador es 4 después de reclamar todas las páginas [748.001186] ADVERTENCIA: CPU: 1 PID: 12985 en drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:685 mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [+0.002771] Módulos vinculados en: cls_flower mlx5_ib mlx5_core ptp pps_core act_mirred sch_ingress openvswitch nsh xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay fuse [última descarga: pps_core] [ 748.007225] CPU: 1 PID: 12985 Comm: tee Not tainted 5.12.0+ #1 [ 748.001376] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 [748.002315] RIP: 0010:mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [748.001679] Código: 28 00 00 00 0f 85 22 01 00 00 48 81 c4 b0 00 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 c7 c7 40 cc 19 a1 e8 9f 71 0e e2 <0f> 0b e9 30 ff ff ff 48 c7 c7 a0 cc 19 a1 e8 8c 71 0e e2 0f 0b e9 [ 748.003781] RSP: 0018:ffff88815220faf8 GS: 00010286 [748.001149] RAX: 0000000000000000 RBX: ffff8881b4900280 RCX: 0000000000000000 [ 748.001445] RDX: 0000000000000027 RSI: 0000000000000004 RDI: a441f51 [ 748.001614] RBP: 00000000000032b9 R08: 0000000000000001 R09: ffffed1054a15ee8 [ 748.001446] R10: ffff8882a50af73b R11: ee7 R12: ffffbfff07c1e30 [ 748.001447] R13: dffffc0000000000 R14: ffff8881b492cba8 R15: 0000000000000000 [ 748.001429] FS: 00007f58bd08b580(0000) GS:ffff8882a5080000(0000) 000000000000 [ 748.001695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 748.001309] CR2: 000055a026351740 CR3: 00000001d3b48006 CR4 : 0000000000370ea0 [ 748.001506] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 748.001483] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [748.001654] Seguimiento de llamadas: [748.000576]? mlx5_satisfy_startup_pages+0x290/0x290 [mlx5_core] [748.001416]? mlx5_cmd_teardown_hca+0xa2/0xd0 [mlx5_core] [748.001354]? mlx5_cmd_init_hca+0x280/0x280 [mlx5_core] [ 748.001203] mlx5_function_teardown+0x30/0x60 [mlx5_core] [ 748.001275] mlx5_uninit_one+0xa7/0xc0 [mlx5_core] [ 748.001200] uno+0x5f/0xc0 [mlx5_core] [ 748.001075] pci_device_remove+0x9f/0x1d0 [ 748.000833] device_release_driver_internal+0x1e0/0x490 [ 748.001207] unbind_store+0x19f/0x200 [ 748.000942] ? sysfs_file_ops+0x170/0x170 [ 748.001000] kernfs_fop_write_iter+0x2bc/0x450 [ 748.000970] new_sync_write+0x373/0x610 [ 748.001124] ? new_sync_read+0x600/0x600 [748.001057]? lock_acquire+0x4d6/0x700 [748.000908]? lockdep_hardirqs_on_prepare+0x400/0x400 [748.001126]? fd_install+0x1c9/0x4d0 [ 748.000951] vfs_write+0x4d0/0x800 [ 748.000804] ksys_write+0xf9/0x1d0 [ 748.000868] ? __x64_sys_read+0xb0/0xb0 [748.000811]? filp_open+0x50/0x50 [748.000919]? syscall_enter_from_user_mode+0x1d/0x50 [ 748.001223] do_syscall_64+0x3f/0x80 [ 748.000892] Entry_SYSCALL_64_after_hwframe+0x44/0xae [ 748.00 ---truncado---

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: udp: corrige la ejecución entre close() y udp_abort(). Kaustubh informó y diagnosticó un pánico en udp_lib_lookup(). La causa principal es que udp_abort() compite con close(). Ambas funciones de ejecución adquieren el bloqueo del socket, pero udp{v6}_destroy_sock() lo libera antes de realizar acciones destructivas. No podemos extender fácilmente el alcance del bloqueo del socket para evitar la ejecución; en su lugar, usamos el indicador SOCK_DEAD para evitar que udp_abort realice alguna acción cuando ocurre la ejecución crítica. Diagnosticado y probado por: Kaustubh Pandey

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net:rds: corrige pérdida de memoria en rds_recvmsg. Syzbot informó pérdida de memoria en rds. El problema estaba en el recuento no puesto en caso de error. int rds_recvmsg(struct socket *sock, struct msghdr *msg, size_t size, int msg_flags) { ... if (!rds_next_incoming(rs, &inc)) { ... } Después de esto "if" inc refcount incrementado y if (rds_cmsg_recv (inc, mensaje, rs)) { ret = -EFAULT; salir; } ... fuera: devolver ret; } en caso de que rds_cmsg_recv() falle, el recuento no disminuirá. Y es fácil ver en el registro de ftrace que rds_inc_addref() no tiene el par rds_inc_put() en rds_recvmsg() después de rds_cmsg_recv() 1) | rds_recvmsg() { 1) 3.721 us| rds_inc_addref(); 1) 3.853 us| rds_message_inc_copy_to_user(); 1) + 10.395 us| rds_cmsg_recv(); 1) + 34.260 us| }