Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net:sfc: corrige irq no liberado en modo irq heredado. El controlador SFC se puede configurar mediante modparam para que funcione usando interrupciones MSI-X, MSI o IRQ heredadas. En el último, la interrupción no se liberó correctamente al eliminar el módulo. No se liberó porque el indicador irqs_hooked no se estableció durante la inicialización en el caso de utilizar IRQ heredado. Ejemplo de seguimiento (recortado) durante la eliminación del módulo sin esta solución: remove_proc_entry: eliminando el directorio no vacío 'irq/125', filtrando al menos '0000:3b:00.1' ADVERTENCIA: CPU: 39 PID: 3658 en fs/proc/generic .c:715 remove_proc_entry+0x15c/0x170 ...recortado... Seguimiento de llamadas: unregister_irq_proc+0xe3/0x100 free_desc+0x29/0x70 irq_free_descs+0x47/0x70 mp_unmap_irq+0x58/0x60 acpi_unregister_gsi_ioapic+0x2a/0x 40 acpi_pci_irq_disable+0x78/0xb0 pci_disable_device +0xd1/0x100 efx_pci_remove+0xa1/0x1e0 [sfc] pci_device_remove+0x38/0xa0 __device_release_driver+0x177/0x230 driver_detach+0xcb/0x110 bus_remove_driver+0x58/0xd0 pci_unregister_driver+0x2a/0 xb0 efx_exit_module+0x24/0xf40 [sfc] __do_sys_delete_module.constprop.0 +0x171/0x280 ? exit_to_user_mode_prepare+0x83/0x1d0 do_syscall_64+0x3d/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f9f9385800b ...recortado...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: isdn: mISDN: netjet: Soluciona fallo en nj_probe: 'nj_setup' en netjet.c puede fallar con -EIO y en este caso 'card->irq' está inicializado y es más grande que cero. Una llamada posterior a 'nj_release' liberará el irq que no ha sido solicitado. Corrija este error eliminando la asignación anterior a 'card->irq' y simplemente mantenga la asignación antes de 'request_irq'. El registro de KASAN lo revela: [3.354615] ADVERTENCIA: CPU: 0 PID: 1 en kernel/irq/manage.c:1826 free_irq+0x100/0x480 [3.355112] Módulos vinculados en: [3.355310] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1-00144-g25a1298726e #13 [ 3.355816 ] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04 /01/2014 [ 3.356552 ] RIP: 0010:free_irq+0x100/0x480 [ 3.356820 ] Código: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18 4d 85 f6 75 e3 e8 f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5 ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80 [ 3.358012 ] RSP: 17b48 EFLAGS: 00010082 [ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX: 0000000000000000 [ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI: 00000000ffffff ff [ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09: 0000000000000000 [ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d0 4 R12: 0000000000000000 [ 3.360195 ] R13 : ffff888107dc6000 R14: ffff888107dc6928 R15: ffff888104dc80a8 [ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000) 00000000000 [ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.361538 ] CR2: 00000000000000000 CR3: 000000000582e000 CR4: 00000000000006f0 [ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3.362175 ] DR3: 000000000000000 0 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 3.362175 ] Seguimiento de llamadas: [ 3.362175 ] nj_release+0x51/0x1e0 [ 3.362175 ] nj_probe+0x450/0x950 [ 3,362175 ] ? pci_device_remove+0x110/0x110 [ 3.362175 ] local_pci_probe+0x45/0xa0 [ 3.362175 ] pci_device_probe+0x12b/0x1d0 [ 3.362175 ] really_probe+0x2a9/0x610 [ 3.362175 ]driver_probe_device+0x90/0x1d0 [3.362175]? mutex_lock_nested+0x1b/0x20 [3.362175] device_driver_attach+0x68/0x70 [3.362175] __driver_attach+0x124/0x1b0 [3.362175]? device_driver_attach+0x70/0x70 [3.362175] bus_for_each_dev+0xbb/0x110 [3.362175]? rdinit_setup+0x45/0x45 [ 3.362175 ] driver_attach+0x27/0x30 [ 3.362175 ] bus_add_driver+0x1eb/0x2a0 [ 3.362175 ] driver_register+0xa9/0x180 [ 3.362175 ] x82/0x90 [3.362175]? w6692_init+0x38/0x38 [3.362175] nj_init+0x36/0x38 [3.362175] do_one_initcall+0x7f/0x3d0 [3.362175]? rdinit_setup+0x45/0x45 [3.362175]? rcu_read_lock_sched_held+0x4f/0x80 [3.362175] kernel_init_freeable+0x2aa/0x301 [3.362175]? rest_init+0x2c0/0x2c0 [3.362175] kernel_init+0x18/0x190 [3.362175]? rest_init+0x2c0/0x2c0 [3.362175]? rest_init+0x2c0/0x2c0 [3.362175] ret_from_fork+0x1f/0x30 [3.362175] Pánico del kernel - no sincronizado: panic_on_warn establecido... [3.362175] CPU: 0 PID: 1 Comm: swapper/0 No contaminado 5.13.0-rc1-00144 -g25a1298726e #13 [ 3.362175 ] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 01/04/2014 [ 3.362175 ] Seguimiento de llamadas: [ 3.362175 ] dump_stack+0xba/0xf5 [3.362175]? free_irq+0x100/0x480 [3.362175] pánico+0x15a/0x3f2 [3.362175]? __advertir+0xf2/0x150 [3.362175]? free_irq+0x100/0x480 [3.362175] __warn+0x108/0x150 [3.362175]? free_irq+0x100/0x480 [ 3.362175 ] report_bug+0x119/0x1c0 [ 3.362175 ] handle_bug+0x3b/0x80 [ 3.362175 ] exc_invalid_op+0x18/0x70 [ 3.362175 ] x12/0x20 [3.362175] RIP: 0010:free_irq+0x100 --- truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/nfc/rawsock.c: corrige un error de verificación de permisos. La función rawsock_create() llama a una función privilegiada sk_alloc(), que requiere una verificación ns-aware para verificar net-> user_ns, es decir, ns_capable(). Sin embargo, el código original verifica init_user_ns usando able(). Entonces reemplazamos el capaz() con ns_capable().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: core: valida el ID del canal al procesar la finalización del comando MHI lee el ID del canal del elemento del anillo de eventos enviado por el dispositivo, que puede tener cualquier valor entre 0 y 255. Para evitar accesos fuera de los límites, agregue una verificación del número máximo de canales admitidos por el controlador y aquellos canales que aún no están configurados para omitir el procesamiento de ese elemento del anillo de eventos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: núcleo del controlador: bus auxiliar: corrige la pérdida de memoria cuando falla driver_register(). Si driver_register() regresa con error, necesitamos liberar la memoria asignada para auxdrv->driver.name antes de regresar de __auxiliary_driver_register()

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