Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kvm: LAPIC: Restaurar protección para evitar el acceso ilegal al registro APIC. Según el SDM, "cualquier acceso que toque los bytes 4 al 15 de un registro APIC puede causar un comportamiento indefinido y no debe ejecutarse ". Peor aún, dicho acceso en kvm_lapic_reg_read puede resultar en una fuga del contenido de la pila del kernel. Antes de confirmar 01402cf81051 ("kvm: LAPIC: anotar registros APIC válidos"), dicho acceso se prohibía explícitamente. Restaura la guardia que se eliminó en esa confirmación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/memory-failure: asegúrese de esperar la reescritura de la página en Memory_failure. Nuestro syzkaller activa el "BUG_ON(!list_empty(&inode->i_wb_list))" en clear_inode: kernel BUG en fs /inodo.c:519! Error interno: Oops - BUG: 0 [#1] Módulos SMP vinculados en: Proceso syz-executor.0 (pid: 249, límite de pila = 0x00000000a12409d7) CPU: 1 PID: 249 Comm: syz-executor.0 No contaminado 4.19. 95 Nombre de hardware: linux,dummy-virt (DT) pstate: 80000005 (Nzcv daif -PAN -UAO) pc: clear_inode+0x280/0x2a8 lr: clear_inode+0x280/0x2a8 Rastreo de llamadas: clear_inode+0x280/0x2a8 ext4_clear_inode+0x38/0xe8 ext4_free_inode+0x130/0xc68 ext4_evict_inode+0xb20/0xcb8 desalojar+0x1a8/0x3c0 iput+0x344/0x460 do_unlinkat+0x260/0x410 __arm64_sys_unlinkat+0x6c/0xc0 el0_svc_common+0xdc /0x3b0 el0_svc_handler+0xf8/0x160 el0_svc+0x10/0x218 Pánico del kernel: no se sincroniza : Excepción fatal Un volcado de memoria de este problema muestra que alguien llamó a __munlock_pagevec para borrar la página LRU sin lock_page: do_mmap -> mmap_region -> do_munmap -> munlock_vma_pages_range -> __munlock_pagevec. Como resultado, Memory_failure llamará a identify_page_state sin wait_on_page_writeback. Y después de truncate_error_page, borre el mapeo de esta página. end_page_writeback no llamará a sb_clear_inode_writeback para borrar inode->i_wb_list. ¡Eso activará BUG_ON en clear_inode! Solucionarlo marcando también PageWriteback para ayudar a determinar si debemos omitir wait_on_page_writeback.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: ieee802154: corrige el deref null en analizar dev addr. Se corrige un error lógico que podría resultar en un deref null si el usuario configura el modo incorrectamente para el tipo de dirección dado.

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 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 :)