Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv4: Controlar el intento de eliminar una ruta multipath cuando fib_info contiene una referencia nh Gwangun Jung informó un acceso fuera de los límites en fib_nh_match: fib_nh_match+0xf98/0x1130 linux-6.0-rc7/net/ipv4/fib_semantics.c:961 fib_table_delete+0x5f3/0xa40 linux-6.0-rc7/net/ipv4/fib_trie.c:1753 inet_rtm_delroute+0x2b3/0x380 linux-6.0-rc7/net/ipv4/fib_frontend.c:874 Los objetos de siguiente salto separados son mutuamente excluyentes con la especificación multipath heredada. Arreglar fib_nh_match para que regrese si la configuración de la ruta que se va a eliminar contiene una especificación de rutas múltiples mientras fib_info usa un objeto nexthop.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Se soluciona la fuga de recuento de referencias del dispositivo PCI en has_external_pci(). for_each_pci_dev() se implementa mediante pci_get_device(). El comentario de pci_get_device() dice que aumentará el recuento de referencias para el pci_dev devuelto y también disminuirá el recuento de referencias para el pci_dev de entrada @from si no es NULL. Si interrumpimos el bucle for_each_pci_dev() con pdev no NULL, debemos llamar a pci_dev_put() para disminuir el recuento de referencias. Agregue el pci_dev_put() faltante antes de 'return true' para evitar la fuga del recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: arregla la ejecución cuando se desborda la pila de vmap Actualmente, al detectar un desbordamiento de la pila de vmap, riscv primero cambia a la llamada pila de sombra, luego usa esta pila de sombra para llamar a get_overflow_stack() para obtener la pila de desbordamiento. Sin embargo, aquí hay una ejecución si dos o más harts usan la misma pila de sombra al mismo tiempo. Para resolver esta ejecución, introducimos la variable atómica spin_shadow_stack, que se intercambiará entre su propia dirección y 0 de forma atómica, cuando la variable está configurada, significa que se está usando shadow_stack; cuando la variable se borra, significa que no se está usando shadow_stack. [Palmer: Agrega AQ al intercambio y también algunos comentarios].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Se corrige la pérdida de recuento de referencias del dispositivo PCI en dmar_dev_scope_init(). for_each_pci_dev() se implementa mediante pci_get_device(). El comentario de pci_get_device() dice que aumentará el recuento de referencias para el pci_dev devuelto y también disminuirá el recuento de referencias para el pci_dev de entrada @from si no es NULL. Si interrumpimos el bucle for_each_pci_dev() con pdev no NULL, debemos llamar a pci_dev_put() para disminuir el recuento de referencias. Agregue el pci_dev_put() faltante para la ruta de error para evitar la pérdida del recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme: se corrige la protección SRCU de la lista nvme_ns_head El recorrido por la lista de hermanos nvme_ns_head está protegido por el srcu del cabezal en nvme_ns_head_submit_bio() pero no por nvme_mpath_revalidate_paths(). La eliminación de espacios de nombres de la lista también fallo al sincronizar el srcu. Por lo tanto, el trabajo de escaneo simultáneo puede causar use-after-free. Mantenga el bloqueo del srcu del cabezal en nvme_mpath_revalidate_paths() y sincronice con el srcu, no con el RCU global, en nvme_ns_remove(). Se observó el siguiente pánico al realizar conexiones NVMe/RDMA con multipath nativo en el kernel Rocky Linux 8.6 (parece que el kernel ascendente tiene la misma condición de ejecución). El desensamblaje muestra que la instrucción que fallo es cmp 0x50(%rdx),%rcx; capacidad de cómputo != get_capacity(ns->disk). La dirección 0x50 está desreferenciada porque ns->disk es NULL. El disco NULL parece ser el resultado de un trabajo de escaneo simultáneo que libera el espacio de nombres (observe la línea de registro en el medio del pánico). [37314.206036] ERROR: no se puede manejar la desreferencia del puntero NULL del núcleo en 0000000000000050 [37314.206036] nvme0n3: se detectó un cambio de capacidad de 0 a 11811160064 [37314.299753] PGD 0 P4D 0 [37314.299756] Oops: 0000 [#1] SMP PTI [37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: cargado Tainted: GWX --------- - - 4.18.0-372.32.1.el8test86.x86_64 #1 [37314.299762] Nombre del hardware: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 23/05/2018 [37314.299763] Cola de trabajo: nvme-wq nvme_scan_work [nvme_core] [37314.299783] RIP: 0010:nvme_mpath_revalidate_paths+0x26/0xb0 [nvme_core] [37314.299790] Código: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 <48> 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3 [37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202 [37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000 [37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800 [37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff [37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 000000000000000 [37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000 [37315.548286] FS: 0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000 [37315.645111] CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 [37315.713871] CR2: 000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0 [37315.799267] Seguimiento de llamadas: [37315.828515] nvme_update_ns_info+0x1ac/0x250 [núcleo_nvme] [37315.892075] nvme_validate_or_alloc_ns+0x2ff/0xa00 [núcleo_nvme] [37315.961871] ? __blk_mq_free_request+0x6b/0x90 [37316.015021] nvme_scan_work+0x151/0x240 [núcleo_nvme] [37316.073371] process_one_work+0x1a7/0x360 [37316.121318] ? crear_trabajador+0x1a0/0x1a0 [37316.168227] subproceso_trabajador+0x30/0x390 [37316.212024] ? crear_trabajador+0x1a0/0x1a0 [37316.258939] kthread+0x10a/0x120 [37316.297557] ? Módulos vinculados en: nvme_rdma nvme_tcp(X) nvme_fabrics nvme_core netconsole iscsi_tcp libiscsi_tcp dm_queue_length dm_service_time nf_conntrack_netlink br_netfilter bridge stp llc superposición nft_chain_nat ipt_MASQUERADE nf_nat xt_addrtype xt_CT nft_counter xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment xt_multiport nft_compat nf_tables libcrc32c nfnetlink dm_multipath tg3 rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm intel_rapl_msr iTCO_wdt iTCO_vendor_support dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm irqbypass crct10dif_pclmul crc32_pclmul mlx5_ib ghash_clmulni_intel ib_uverbs rapl intel_cstate intel_uncore ib_core ipmi_si joydev mei_me---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: Sincronizar las asignaciones de kernel de la tabla de páginas efi antes de cambiar La tabla de páginas efi se crea inicialmente como una copia de la tabla de páginas del kernel. Con VMAP_STACK habilitado, las pilas del kernel se asignan en el área vmalloc: si la pila se asigna en un nuevo PGD (uno que no estaba presente en el momento de la creación de la tabla de páginas efi o no se sincronizó en un error vmalloc anterior), el kernel tomará una trampa al cambiar a la tabla de páginas efi cuando se accede a la pila del kernel vmalloc, lo que resulta en un pánico del kernel. Solucione eso actualizando las asignaciones de kernel efi antes de cambiar a la tabla de páginas efi.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: sja1105: evitar acceso fuera de los límites en sja1105_init_l2_policing() La familia SJA1105 tiene 45 entradas de tabla de control de L2 (SJA1105_MAX_L2_POLICING_COUNT) y SJA1110 tiene 110 (SJA1110_MAX_L2_POLICING_COUNT). Mantener la estructura de la tabla pero tener en cuenta la diferencia en el recuento de puertos (5 en SJA1105 frente a 10 en SJA1110) no explica completamente la diferencia. En cambio, SJA1110 también tiene controladores de ingreso de L2 para tráfico de multidifusión. Si un paquete se clasifica como de multidifusión, será procesado por el índice de controlador 99 + SRCPORT. La función sja1105_init_l2_policing() inicializa todos los controladores de L2 de modo que no interfieran con la recepción normal de paquetes de forma predeterminada. Para tener un código común entre SJA1105 y SJA1110, se calcula el índice del controlador de multidifusión para el puerto porque es un índice que está fuera de los límites para SJA1105 pero dentro de los límites para SJA1110, y se realiza una comprobación de los límites. El código no hace lo correcto al determinar qué hacer con el controlador de multidifusión del puerto 0 en SJA1105 (ds->num_ports = 5). El índice "mcast" será igual a 45, que también es igual a table->ops->max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). Por lo tanto, pasa por la comprobación. Pero al mismo tiempo, SJA1105 no tiene controladores de multidifusión. Por lo tanto, el código programa el campo SHARINDX de un elemento fuera de los límites en la tabla de control L2 de la configuración estática. La comparación entre las entradas del índice 45 y 45 debería haber determinado que el código no accediera a este índice de control en SJA1105, ya que su memoria ni siquiera estaba asignada. Con suficiente mala suerte, la escritura fuera de los límites podría incluso sobrescribir otros datos válidos del kernel, pero en este caso, el problema se detectó mediante KASAN. Registro del núcleo: sja1105 spi5.0: Chip conmutador sondeado: SJA1105Q ===================================================================== ERROR: KASAN: slab fuera de los límites en sja1105_setup+0x1cbc/0x2340 Escritura de tamaño 8 en la dirección ffffff880bd57708 por la tarea kworker/u8:0/8 ... Cola de trabajo: events_unbound deferred_probe_work_func Rastreo de llamadas: ... sja1105_setup+0x1cbc/0x2340 dsa_register_switch+0x1284/0x18d0 sja1105_probe+0x748/0x840 ... Asignado por la tarea 8: ... sja1105_setup+0x1bcc/0x2340 dsa_register_switch+0x1284/0x18d0 sja1105_probe+0x748/0x840 ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/shmem-helper: eliminar una ubicación errada en la ruta de error drm_gem_shmem_mmap() no posee esta referencia, lo que provoca que el objeto GEM se libere prematuramente y lleve a un use after free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: Se soluciona el fallo al volver a conectar controladores falsos de CSR Parece que los clones falsos de CSR 5.0 pueden provocar que el notificador de suspensión se registre dos veces, lo que provoca el siguiente pánico del kernel: [ 71.986122] Seguimiento de llamadas: [ 71.986124] [ 71.986125] blocking_notifier_chain_register+0x33/0x60 [ 71.986130] hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da] [ 71.986154] btusb_probe+0x979/0xd85 [btusb es: e1e0605a4f4c01984a4b9c8ac58c3666ae287477] [ 71.986159] ? __pm_runtime_set_status+0x1a9/0x300 [ 71.986162] ? ktime_get_mono_fast_ns+0x3e/0x90 [ 71.986167] interfaz_sonda_usb+0xe3/0x2b0 [ 71.986171] realmente_sonda+0xdb/0x380 [ 71.986174] ? pm_runtime_barrier+0x54/0x90 [ 71.986177] __driver_probe_device+0x78/0x170 [ 71.986180] __driver_probe_device+0x1f/0x90 [ 71.986183] __device_attach_driver+0x89/0x110 [ 71.986186] ? driver_allows_async_probing+0x70/0x70 [ 71.986189] bus_para_cada_unidad+0x8c/0xe0 [ 71.986192] __dispositivo_adjunto+0xb2/0x1e0 [ 71.986195] bus_sondeo_dispositivo+0x92/0xb0 [ 71.986198] dispositivo_agregado+0x422/0x9a0 [ 71.986201] ? usb_probe_device+0x3a/0x110 [ 71.986213] realmente_probe+0xdb/0x380 [ 71.986216] ? pm_runtime_barrier+0x54/0x90 [ 71.986219] __driver_probe_device+0x78/0x170 [ 71.986221] driver_probe_device+0x1f/0x90 [ 71.986224] __device_attach_driver+0x89/0x110 [ 71.986227] ? driver_allows_async_probing+0x70/0x70 [ 71.986230] bus_para_cada_unidad+0x8c/0xe0 [ 71.986232] __device_attach+0xb2/0x1e0 [ 71.986235] bus_probe_device+0x92/0xb0 [ 71.986237] device_add+0x422/0x9a0 [ 71.986239] ? _dev_info+0x7d/0x98 [ 71.986242] ? subproceso de rescate+0x3b0/0x3b0 [ 71.986264] kthread+0xdb/0x110 [ 71.986266] ? kthread_complete_and_exit+0x20/0x20 [ 71.986268] ret_from_fork+0x1f/0x30 [ 71.986273] [ 71.986274] ---[ fin de seguimiento 000000000000000 ]--- [ 71.986284] btusb: la sonda de 2-1.6:1.0 falló con el error -17

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: Se corrige un null-ptr-deref en io_tctx_exit_cb() Syzkaller informa un error de desreferencia NULL de la siguiente manera: ERROR: KASAN: null-ptr-deref en io_tctx_exit_cb+0x53/0xd3 Lectura de tamaño 4 en la dirección 0000000000000138 por la tarea file1/1955 CPU: 1 PID: 1955 Comm: file1 No contaminado 6.1.0-rc7-00103-gef4d3ea40565 #75 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Seguimiento de llamadas: nivel_pila_volcado+0xcd/0x134 ? io_tctx_salir_cb+0x53/0xd3 informe_kasan+0xbb/0x1f0 ? io_tctx_salir_cb+0x53/0xd3 rango_comprobación_kasan+0x140/0x190 io_tctx_salir_cb+0x53/0xd3 ejecución_trabajo_tarea+0x164/0x250 ? cancelación_trabajo_tarea+0x30/0x30 obtener_señal+0x1c3/0x2440 ? degradación_bloqueo+0x6e0/0x6e0 ? degradación_bloqueo+0x6e0/0x6e0 ? señales_salida+0x8b0/0x8b0 ? desbloqueo_lectura_sin_datos+0x3b/0x70 ? obtener_sigframe_size+0x10/0x10 ? bloquear_hardirqs_on+0x79/0x100 ? poner_nombre+0xfe/0x140 ? do_execveat_common.isra.0+0x238/0x710 exit_to_user_mode_prepare+0x15f/0x250 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x42/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0023:0x0 Código: No se puede acceder a los bytes del código de operación en 0xffffffffffffffd6. RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000b RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000000 RDI: 000000000000000 RBP: 000000000000000 R08: 0000000000000000 R09: 00000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Pánico del kernel: no se sincroniza: panic_on_warn establecido ... Esto sucede porque la adición de task_work desde io_ring_exit_work() no está sincronizada con la cancelación de todos los elementos de trabajo, por ejemplo, de exec. La ejecución de los dos está ordenada de manera que ambos son ejecutados por la propia tarea, pero si io_tctx_exit_cb() está en cola mientras cancelamos todos los elementos de trabajo de exec Y se ejecuta cuando la tarea sale al espacio de usuario en lugar de en el bucle principal en io_uring_cancel_generic(), entonces podemos encontrar current->io_uring == NULL y alcanzar el bloqueo anterior. Es seguro agregar esta verificación NULL aquí, porque la ejecución de las dos rutas las realiza la propia tarea. [axboe: agregue un comentario de código y también coloque una explicación en el mensaje de confirmación]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: slcan: fix freed work crash La prueba LTP pty03 está provocando un fallo en slcan: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 01/04/2014 Cola de trabajo: 0x0 (eventos) RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) Código: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 RAX: 000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 FS: 000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 Seguimiento de llamadas: worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436) kthread (/home/rich/kernel/linux/kernel/kthread.c:376) ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312) Aparentemente, el tx_work de slcan se libera mientras se programa. Mientras que slcan_netdev_close() (lado netdev) llama a flush_work(&sl->tx_work), slcan_close() (lado tty) no lo hace. Entonces, cuando el netdev nunca se configura, pero el tty está lleno de bytes y se lo obliga a activar la escritura, el trabajo se programa, pero nunca se vacía. Por lo tanto, agregue un flush_work() adicional a slcan_close() para asegurarse de que el trabajo se vacía en todas las circunstancias. el commit de correcciones a continuación movió flush_work() de slcan_close() a slcan_netdev_close(). ¿Cuál fue la razón detrás de esto? ¿Quizás podamos eliminar el que está en slcan_netdev_close()? Veo el mismo patrón en can327. Entonces, tal vez necesite la misma corrección.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mana: Corregir ejecución en la variable per-CQ napi work_done Después de llamar a napi_complete_done(), el bit NAPIF_STATE_SCHED puede borrarse, y otra CPU puede iniciar el hilo napi y acceder a la variable per-CQ, cq->work_done. Si el otro hilo (por ejemplo, desde busy_poll) lo establece en un valor >= budget, este hilo seguirá ejecutándose cuando debería detenerse, y provocará corrupción de memoria y pánico. Para solucionar este problema, guarde la variable per-CQ work_done en una variable local antes de napi_complete_done(), para que no se corrompa por un posible hilo concurrente después de napi_complete_done(). Además, agregue un bit de bandera para anunciar al firmware NIC: la ejecución de la variable NAPI work_done está fija, por lo que el controlador puede soportar de forma fiable funciones como busy_poll.