Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: corrige el manejo de errores de scsi_host_alloc(). Después de que el dispositivo se inicializa mediante device_initialize(), o su nombre se establece mediante dev_set_name(), el dispositivo debe liberarse mediante put_device (). De lo contrario, se filtrará el nombre del dispositivo porque se asigna dinámicamente en dev_set_name(). Solucione la fuga reemplazando kfree() con put_device(). Dado que scsi_host_dev_release() maneja adecuadamente la eliminación de IDA y kthread, elimine también estas mayúsculas y minúsculas especiales del manejo de errores.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFS: corrija una posible desreferencia NULL en nfs_get_client() Ninguna de las personas que llaman espera retornos NULL de nfs_get_client(), por lo que este código generará un error ¡Oops! Es mejor devolver un puntero de error. Supongo que se trata de un código inactivo, así que espero que nadie se vea afectado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/mlx5: Corrección al inicializar el búfer de fragmentos CQ. Se puede llamar a la función init_cq_frag_buf() para inicializar el búfer de fragmentos CQ actual cq->buf, o el cq->resize_buf temporal que es rellenado durante la operación de cambio de tamaño de CQ. Sin embargo, la confirmación infractora comenzó a usar la función get_cqe() para obtener los CQE, el problema con este cambio es que get_cqe() siempre devuelve CQE desde cq->buf, lo que nos lleva a inicializar el búfer incorrecto y, en caso de ampliarlo, En el CQ intentamos acceder a elementos más allá del tamaño del cq->buf actual y finalmente entramos en pánico en el kernel. [excepción RIP: init_cq_frag_buf+103] [ffff9f799ddcbcd8] mlx5_ib_resize_cq en fffffffc0835d60 [mlx5_ib] [ffff9f799ddcbdb0] ib_resize_cq en fffffffc05270df [ib_core] [ffff9f799ddcbdc0] _rdma_setup_qp en ffffffffc0a6a712 [llt] [ffff9f799ddcbe10] llt_rdma_cc_event_action en ffffffffc0a6b411 [llt] [ffff9f799ddcbe98] llt_rdma_client_conn_thread en ffffffffc0a6bb75 [llt] [ffff9f799ddcbec8] kthread en ffffffffa66c5da1 [ffff9f799ddcbf50] ret_from_fork_nospec_begin en ffffffffa6d95ddd Arréglelo obteniendo el CQE necesario llamando a mlx5_frag_buf_get_wqe() que toma el búfer de origen correcto como parámetro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: Garantizar la vivacidad de la VM anidada. Ingrese el mensaje de punto de seguimiento de falla. Utilice la maquinaria __string() proporcionada por el subsistema de seguimiento para hacer una copia de los literales de cadena consumidos por los puntos de seguimiento "nested VM-Enter failed". Es necesaria una copia completa para garantizar que el punto de seguimiento no pueda vivir más que los datos o la memoria que consume y para evitar la memoria obsoleta. Debido a que el punto de seguimiento en sí está definido por kvm, si kvm-intel y/o kvm-amd se construyen como módulos, la memoria que contiene los literales de cadena definidos por los módulos del proveedor se liberará cuando se descargue el módulo, mientras que el punto de seguimiento y sus datos en el búfer circular permanecerá hasta que se descargue kvm (o "indefinidamente" si kvm está integrado). Este error ha existido desde que se agregó el punto de seguimiento, pero recientemente quedó expuesto mediante una nueva verificación en el seguimiento para detectar exactamente este tipo de error. fmt: '%s%s ' current_buffer: ' vmx_dirty_log_t-140127 [003] .... kvm_nested_vmenter_failed: ' ADVERTENCIA: CPU: 3 PID: 140134 en kernel/trace/trace.c:3759 trace_check_vprintf+0x3be/0x3e0 CPU: 3 PID: 140134 Comm: less No contaminado 5.13.0-rc1-ce2e73ce600a-req #184 Nombre de hardware: ASUS Q87M-E/Q87M-E, BIOS 1102 03/03/2014 RIP: 0010:trace_check_vprintf+0x3be/0x3e0 Código: < 0f> 0b 44 8b 4c 24 1c e9 a9 fe ff ff c6 44 02 ff 00 49 8b 97 b0 20 RSP: 0018:ffffa895cc37bcb0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: cc37bd08 RCX: 0000000000000027 RDX: 0000000000000027 RSI: 00000000ffffdfff RDI: ffff9766cfad74f8 RBP : ffffffffc0a041d4 R08: ffff9766cfad74f0 R09: ffffa895cc37bad8 R10: 0000000000000001 R11: 00000000000000001 R12: ffffffffc0a041d4 R13: ffffffffc0f4dba8 R 14: 0000000000000000 R15: ffff976409f2c000 FS: 00007f92fa200740(0000) GS:ffff9766cfac0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 00 CR0: 0000000080050033 CR2: 0000559bd11b0000 CR3: 000000019fbaa002 CR4: 00000000001726e0 Seguimiento de llamadas: trace_event_printf+0x5e/0x80 3a/0x60 [kvm] print_trace_line+0x1dd/0x4e0 s_show+0x45/0x150 seq_read_iter+0x2d5/0x4c0 seq_read+0x106/0x150 vfs_read+ 0x98/0x180 ksys_read+0x5f/0xe0 do_syscall_64+0x40/0xb0 entrada_SYSCALL_64_after_hwframe+0x44/0xae

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.