Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: ngene: corrige un error fuera de los límites en ngene_command_config_free_buf(). Corrige un error de hace 11 años en ngene_command_config_free_buf() mientras se solucionan las siguientes advertencias detectadas con -Warray-bounds: arch/alpha/include/asm/string.h:22:16: advertencia: el desplazamiento '__builtin_memcpy' [12, 16] del objeto en 'com' está fuera de los límites del subobjeto referenciado 'config' con tipo 'carácter sin firmar ' en el desplazamiento 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: advertencia: el desplazamiento '__builtin_memcpy' [12, 16] del objeto en 'com' está fuera de los límites de subobjeto referenciado 'config' con tipo 'unsigned char' en el desplazamiento 10 [-Warray-bounds] El problema es que el código original está intentando copiar 6 bytes de datos en un miembro de tamaño de un byte _config_ de la estructura incorrecta FW_CONFIGURE_BUFFERS, en una sola llamada a memcpy(). Esto provoca una advertencia legítima del compilador porque memcpy() sobrepasa la longitud de &com.cmd.ConfigureBuffers.config. Parece que la estructura correcta es FW_CONFIGURE_FREE_BUFFERS, porque contiene 6 miembros más además del encabezado _hdr_. Además, el nombre de la función ngene_command_config_free_buf() sugiere que la intención real es ConfigureFreeBuffers, en lugar de ConfigureBuffers (que tiene lugar en la función ngene_command_config_buf(), arriba). Solucione este problema encerrando esos 6 miembros de la estructura FW_CONFIGURE_FREE_BUFFERS en una nueva configuración de estructura y use &com.cmd.ConfigureFreeBuffers.config como dirección de destino, en lugar de &com.cmd.ConfigureBuffers.config, al llamar a memcpy(). Esto también ayuda con los esfuerzos continuos para habilitar globalmente -Warray-bounds y acercarnos a poder ajustar las rutinas FORTIFY_SOURCE en memcpy().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ACPI: corrige la desreferencia del puntero NULL. La confirmación 71f642833284 ("ACPI: utils: corrige el recuento de referencias en for_each_acpi_dev_match()") comenzó a hacer "acpi_dev_put()" en un puntero que posiblemente era NULL. Eso falla estrepitosamente, porque esa función auxiliar en línea no está configurada para manejar ese caso. Simplemente haga que acpi_dev_put() acepte silenciosamente un puntero NULL, en lugar de llamar a put_device() con un desplazamiento no válido de ese puntero NULL.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gpio: wcd934x: corrección de error de desplazamiento fuera de los límites. La máscara de bits para los pines 0 a 4 es BIT(0) a BIT(4); sin embargo, terminamos con BIT( n - 1) lo cual no es correcto, y esto fue detectado por la siguiente verificación USB UBSAN: shift-out-of-bounds in drivers/gpio/gpio-wcd934x.c:34:14

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: core: corrige la desreferencia de punto nulo en fmt_single_name(). Verifique el valor de retorno de devm_kstrdup() en caso de dereferencia de punto nulo.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: RDMA: Verificar puerto al crear regla de flujo. Validar valor de puerto proporcionado por el usuario y con ello eliminar la validación que ya no necesita el controlador. La verificación que falta en el controlador mlx5_ib podría provocar los siguientes errores. Seguimiento de llamadas: _create_flow_rule+0x2d4/0xf28 [mlx5_ib] mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib] ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x1 50 [ib_uverbs] ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs] ib_uverbs_ioctl+0x158 /0x1d0 [ib_uverbs] do_vfs_ioctl+0xd0/0xaf0 ksys_ioctl+0x84/0xb4 __arm64_sys_ioctl+0x28/0xc4 el0_svc_common.constprop.3+0xa4/0x254 el0_svc_handler+0x84/0xa0 0x10/0x26c Código: b9401260 f9615681 51000400 8b001c20 (f9403c1a)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/ipoib: Corrección de advertencia causada por la destrucción de redes no iniciales. Después de la confirmación 5ce2dced8e95 ("RDMA/ipoib: Establecer rtnl_link_ops para interfaces ipoib"), si el dispositivo IPoIB se mueve a redes no iniciales, destruir esas redes permite que el dispositivo desaparezca en lugar de moverlo nuevamente a las redes iniciales. Esto sucede porque default_device_exit() omite las interfaces debido a que tiene rtnl_link_ops configurado. Pasos para reproducir: ip netns agregar foo ip link set mlx5_ib0 netns foo ip netns eliminar foo ADVERTENCIA: CPU: 1 PID: 704 en net/core/dev.c:11435 netdev_exit+0x3f/0x50 Módulos vinculados en: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ip v4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun d fuse CPU: 1 PID: 704 Comm: kworker/u64:3 Contaminado: GSW 5.13.0-rc1+ #1 Nombre de hardware: Dell Inc. PowerEdge R6 30/02C2CP, BIOS 2.1.5 11/04/2016 Cola de trabajo: netns cleanup_net RIP: 0010:netdev_exit+0x3f/0x50 Código: 48 8b bb 30 01 00 00 e8 ef 81 b1 ff 48 81 fb c0 3a 54 a1 74 13 48 8b 83 90 00 00 00 48 81 c3 90 00 00 00 48 39 d8 75 02 5b c3 <0f> 0b 5b c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 1f 44 00 RSP: 0018:ffffb297079d7e08 : 00010206 RAX: ffff8eb542c00040 RBX: ffff8eb541333150 RCX : 000000008010000d RDX: 000000008010000e RSI: 000000008010000d RDI: ffff8eb440042c00 RBP: ffffb297079d7e48 R08: 0000000000000001 R09: ff9fdeac00 R10: ffff8eb5003be000 R11: 0000000000000001 R12: ffffffffa1545620 R13: ffffffffa1545628 R14: 00000000000000000 R15: ffffffffa1543b20 FS: 0000000000(0000) GS:ffff8ed37fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005601b5f4c2e8 CR3: 0000001fc8c10002 CR4: 00000000003706e0 0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ops_exit _list.isra.9 +0x36/0x70 cleanup_net+0x234/0x390 Process_one_work+0x1cb/0x360 ? Process_one_work+0x360/0x360 worker_thread+0x30/0x370 ? Process_one_work+0x360/0x360 kthread+0x116/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x22/0x30 Para evitar la advertencia anterior y más adelante el pánico del kernel que podría ocurrir al cerrar debido a una desreferencia del puntero NULL, asegúrese de configurar el indicador netns_refund que fue introducido por la confirmación 3a5ca857079e ("can: dev: Mueva el dispositivo nuevamente a init netns al poseer netns eliminar") para restaurar correctamente las interfaces IPoIB a las netns iniciales.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: corrige varios fallos de dispositivos en cableado de 10 gbps usb_assign_descriptors() se llama con 5 parámetros, los últimos 4 de los cuales son usb_descriptor_header para: velocidad completa (USB1.1 - 12Mbps [ incluyendo USB1.0 de baja velocidad a 1,5 Mbps), alta velocidad (USB2.0 - 480 Mbps), súper velocidad (USB3.0 - 5 Gbps), súper velocidad plus (USB3.1 - 10 Gbps). Las diferencias entre los descriptores de velocidad completa/alta/supervelocidad suelen ser sustanciales (debido a cambios en el tamaño máximo del bloque USB de 64 a 512 a 1024 bytes y otras diferencias en las especificaciones), mientras que la diferencia entre los descriptores de 5 y 10 Gbps puede ser tan casi nada (en muchos casos, la misma afinación es simplemente suficiente). Sin embargo, si un controlador de dispositivo llama a usb_assign_descriptors() con un descriptor NULL para super-speed-plus y luego se usa en una configuración máxima de 10 gbps, el kernel fallará con una desreferencia de puntero null, cuando un puerto de dispositivo con capacidad de 10 gbps + cable + puerto de host Aparece la combinación. (Esto no sucedería si la velocidad máxima del dispositivo estuviera configurada en 5 gbps, pero, por supuesto, está predeterminada al máximo y no hay ninguna razón real para limitarla artificialmente). La solución es simplemente usar el descriptor de 5 gbps como el descriptor de 10 gbps, si no se proporcionó un descriptor de 10 gbps. Obviamente, esto no solucionará el problema si el descriptor de 5 gbps también es NULL, pero estos casos no se pueden resolver de manera tan trivial (y es poco probable que dichos dispositivos se utilicen con puertos USB3 de alguna manera).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: tcpm: cancela vdm y state machine hrtimer cuando se cancela el registro del puerto tcpm. Un hrtimer pendiente puede caducar después de que se destruya el kthread_worker del puerto tcpm; consulte el siguiente volcado del kernel cuando se descarga el módulo , solucionelo cancelando los 2 temporizadores. [ 111.517018] No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffff8000118cb880 [ 111.518786] blk_update_request: error de E/S, dev sda, sector 60061185 op 0x0:(LEER) indicadores 0x0 phys_seg 1 prio clase 0 [ 111.526594] Información de cancelación de memoria: [111.526597 ] ESR = 0x96000047 [ 111.526600] EC = 0x25: DABT (EL actual), IL = 32 bits [ 111.526604] SET = 0, FnV = 0 [ 111.526607] EA = 0, S1PTW = 0 [ 111.526610] Información de cancelación de datos: [ 111. 526612 ] ISV = 0, ISS = 0x00000047 [ 111.526615] CM = 0, WnR = 1 [ 111.526619] tabla de intercambio: páginas de 4k, VA de 48 bits, pgdp=0000000041d75000 [ 111.526623 [ffff8000118cb] 880] pgd=10000001bffff003, p4d=10000001bffff003, pudín =10000001bfffe003, pmd=10000001bfffa003, pte=0000000000000000 [111.526642] Error interno: Ups: 96000047 [#1] SMP PREEMPLEO [111.526647] Módulos vinculados en: dwc3_imx8mp dwc3 phy_fsl_imx8mq_usb [última descarga: tcpci] [111.526663] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc4-00927-gebbe9dbd802c-dirty #36 [111.526670] Nombre del hardware: placa NXP i.MX8MPlus EVK (DT) [111.526674] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO BTYPE=--) [ 111.526681] pc : queued_spin_lock_slowpath+0x1a0/0x390 [ 111.526695] lr : _raw_spin_lock_irqsave+0x88/0xb4 [ 111.526703] sp : ffff800010003e20 [ 111.526 706] x29: ffff800010003e20 x28: ffff00017f380180 [111.537156] buffer_io_error: 6 devoluciones de llamada suprimidas [111.537162 ] Error de E/S del búfer en dev sda1, bloque lógico 60040704, lectura de página asíncrona [111.539932] x27: ffff00017f3801c0 [111.539938] x26: ffff800010ba2490 x25: 0000000000000000 x24: 00000000000001 [111.543025] blk_update_request: error de E/S, dev sda, sector 60061186 op 0x0:(LEER) banderas 0x0 phys_seg 7 prio clase 0 [ 111.548304] [ 111.548306] x23: 00000000000000c0 x22: ffff0000c2a9f184 x21: ffff00017f380180 [ 111.551 374] Error de E/S del búfer en dev sda1, bloque lógico 60040705, lectura de página asíncrona [111.554499] [111.554503] x20: ffff0000c5f14210 x19: 00000000000000c0 x18: 0000000000000000 [111.557391] Error de E/S del búfer en dev sda1, bloque lógico 60040706, lectura de página asíncrona [111. 561218] [ 111.561222] x17: 0000000000000000 x16: 0000000000000000 x15: 00000000000000000 [ 111.564205] Búfer Error de E/S en dev sda1, bloque lógico 60040707, lectura de página asíncrona [111.570887] x14: 00000000000000f5 x13: 00000000000000001 x12: 0000000000000040 [111.570902] x11: ff0000c05ac6d8 [111.583420] Error de E/S del búfer en dev sda1, bloque lógico 60040708, asíncrono lectura de página [111.588978] x10: 0000000000000000 x9: 0000000000040000 [111.588988] x8: 0000000000000000 [111.597173] Error de E/S del búfer en dev sda1, bloque lógico 6004 0709, lectura de página asíncrona [111.605766] x7: ffff00017f384880 x6: ffff8000118cb880 [111.605777] x5: ffff00017f384880 [111.611094] Error de E/S del búfer en dev sda1, bloque lógico 60040710, lectura de página asíncrona [111.617086] x4: 0000000000000000 x3: ffff0000c2a9f184 [111.617096] 2: ffff8000118cb880 [111.622242] Error de E/S del búfer en dev sda1, bloque lógico 60040711 , lectura de página asíncrona [111.626927] x1: ffff8000118cb880 x0: ffff00017f384888 [111.626938] Seguimiento de llamadas: [111.626942] queued_spin_lock_slowpath+0x1a0/0x390 [111.795809] _queue_work+0x30/0xc0 [ 111.799828] state_machine_timer_handler+0x20/0x30 [ 111.804624] __hrtimer_run_queues+0x140/ 0x1e0 [ 111.808990] hrtimer_interrupt+0xec/0x2c0 [ 111.813004] arch_timer_handler_phys+0x38/0x50 [ 111.817456] handle_percpu_devid_irq+0x88/0x150 [ 111.821991] main_irq+0x80/0xe0 [ 111.826093] gic_handle_irq+0x ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: ep0: corrige excepción de puntero NULL. No hay validación del índice desde dwc3_wIndex_to_dep() y podríamos estar haciendo referencia a un ep inexistente y desencadenar una excepción de puntero NULL. En ciertas configuraciones, podríamos usar menos eps y el índice podría indicar erróneamente un índice ep mayor que el existente. Al agregar esta validación del parche, podemos informar un índice incorrecto a la persona que llama. En nuestro caso de uso, estamos usando un dispositivo compuesto en un kernel más antiguo, pero el nivel superior también podría usar esta solución. Desafortunadamente, no puedo describir el hardware para que otros reproduzcan el problema ya que es una implementación propietaria. [82.958261] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000000a4 [82.966891] Información de cancelación de memoria: [82.969663] ESR = 0x96000006 [82.972703] Clase de excepción = DABT (EL actual), IL = 32 bits [ 82.9 78603] CONFIGURAR = 0, FnV = 0 [82.981642] EA = 0, S1PTW = 0 [82.984765] Información de cancelación de datos: [82.987631] ISV = 0, ISS = 0x00000006 [82.991449] CM = 0, WnR = 0 [82.994409] tabla de usuario 4k: páginas, 39 VA de bits, pgdp = 00000000c6210ccc [ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000 [ 83.00 9685] Error interno: Oops: 96000006 [#1] SMP PREEMPTO [83.026433] Proceso irq/62-dwc3 (pid : 303, límite de pila = 0x000000003985154c) [83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 No contaminado 4.19.124 #1 [83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 49628] ordenador personal: dwc3_ep0_handle_feature+0x414/0x43c [ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94 ... [ 83.141788] Rastreo de llamadas: [ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c [ 83.148 823] dwc3_ep0_interrupt+0x3b4/0xc94 [83.181546] ---[ final de seguimiento aac6b5267d84c32f ]---

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: usb: repara varios gadgets null ptr deref en cableado de 10gbps. Esto evita una desreferencia de puntero null en f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm} simplemente reutilizando la configuración de 5 gbps para 10 gbps.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: cdnsp: soluciona el problema de interbloqueo en cdnsp_thread_irq_handler. El parche corrige el siguiente problema crítico causado por el interbloqueo que se detectó durante las pruebas Clase NCM: smp: csd: se detectó un bloqueo CSD que no responde ( #1) en CPU#0 smp: csd: el bloqueo CSD (#1) no responde. .... RIP: 0010:native_queued_spin_lock_slowpath+0x61/0x1d0 RSP: 0018:ffffbc494011cde0 EFLAGS: 00000002 RAX: 0000000000000101 RBX: ffff9ee8116b4a68 RCX: 0000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ee8116b4658 RBP: ffffbc494011cde0 R08: 0000000000000001 R09: 00000000000000000 R 10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658 R13: ffff9ee8116b4670 R14: 00000000000000246 R15: ffff9ee8116b4658 CS: 0010 DS: 0 ES: 0000 CR0: 0000000080050033 CR2: 00007f7bcc41a830 CR3: 000000007a612003 CR4: 00000000001706e0 Seguimiento de llamadas: do_raw_spin_lock+0xc0/0xd0 _raw_spin_lock_irqsave + 0x95/0xa0 cdnsp_gadget_ep_queue.cold+0x88/0x107 [cdnsp_udc_pci] usb_ep_queue+0x35/0x110 eth_start_xmit+0x220/0x3d0 [u_ether] ncm_tx_timeout+0x34/0x40 [usb_f_ncm] ? ncm_free_inst+0x50/0x50 [usb_f_ncm] __hrtimer_run_queues+0xac/0x440 hrtimer_run_softirq+0x8c/0xb0 __do_softirq+0xcf/0x428 asm_call_irq_on_stack+0x12/0x20 +0x61/0x70 irq_exit_rcu+0xc1/0xd0 sysvec_apic_timer_interrupt+0x52/0xb0 asm_sysvec_apic_timer_interrupt+0x12 /0x20 RIP: 0010:do_raw_spin_trylock+0x18/0x40 RSP: 0018:ffffbc494138bda8 EFLAGS: 00000246 RAX: 00000000000000000 RBX: ffff9ee8116b4658 RCX: 0000000000000 000 RDX: 0000000000000001 RSI: 00000000000000000 RDI: ffff9ee8116b4658 RBP: ffffbc494138bda8 R08: 00000000000000001 R09: 0000000000000000 R10: ffff9ee8116b4670 R11 : 0000000000000000 R12: ffff9ee8116b4658 R13: ffff9ee8116b4670 R14: ffff9ee7b5c73d80 R15: ffff9ee8116b4000 _raw_spin_lock+0x3d/0x70 ? cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci] cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci] ? cdnsp_remove_request+0x1f0/0x1f0 [cdnsp_udc_pci] ? cdnsp_thread_irq_handler+0x5/0xa0 [cdnsp_udc_pci] ? irq_thread+0xa0/0x1c0 irq_thread_fn+0x28/0x60 irq_thread+0x105/0x1c0 ? __kthread_parkme+0x42/0x90 ? irq_forced_thread_fn+0x90/0x90? wake_threads_waitq+0x30/0x30? irq_thread_check_affinity+0xe0/0xe0 kthread+0x12a/0x160 ? kthread_park+0x90/0x90 ret_from_fork+0x22/0x30 La causa principal del problema es la instrucción spin_lock/spin_unlock en lugar de spin_lock_irqsave/spin_lock_irqrestore en la función cdnsp_thread_irq_handler.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: gadget: Bail from dwc3_gadget_exit() si dwc->gadget es NULL. Existe un posible escenario en el que dwc3_gadget_init() puede fallar: durante durante el host -> modo periférico Cambie a dwc3_set_mode() y un controlador de dispositivo pendiente no se vincula. Luego, si el DRD sufre otro cambio de modo desde periférico->host, el dwc3_gadget_exit() resultante intentará hacer referencia a un puntero dwc->gadget no válido y colgante, así como llamar a dma_free_coherent() en punteros DMA no asignados. El escenario exacto se puede reproducir de la siguiente manera: - Iniciar DWC3 en modo periférico - Configurar el gadget ConfigFS con la instancia FunctionFS (o usar g_ffs) - Ejecutar la aplicación de espacio de usuario FunctionFS (abrir EP, escribir descriptores, etc.) - Vincular el controlador del gadget al UDC de DWC3 - Cambiar DWC3 al modo host => se llama a dwc3_gadget_exit(). usb_del_gadget() colocará la instancia del controlador ConfigFS en gadget_driver_pending_list - Detener la aplicación FunctionFS (cierra los archivos ep) - Cambiar DWC3 al modo periférico => dwc3_gadget_init() falla ya que usb_add_gadget() llama a check_pending_gadget_drivers() e intenta volver a vincular el UDC al El gadget ConfigFS pero falla con -19 (-ENODEV) porque la instancia FFS no está en estado FFS_ACTIVE (el espacio de usuario aún no se ha reabierto ni escrito los descriptores, es decir, desc_ready!=0). - Vuelva a cambiar DWC3 al modo host => se vuelve a llamar a dwc3_gadget_exit(), pero esta vez dwc->gadget no es válido. Aunque se puede argumentar que el espacio de usuario debe asumir la responsabilidad de garantizar que la aplicación FunctionFS esté lista antes de permitir que el controlador compuesto se vincule al UDC, no hacerlo no debería generar pánico por parte del controlador del kernel. Solucione este problema configurando dwc->gadget en NULL en la ruta de falla de dwc3_gadget_init() y agregue una marca a dwc3_gadget_exit() para salir del problema a menos que el puntero del gadget sea válido.