Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: añadir comprobación de nombre no válido en btf_name_valid_section() Si la longitud de la cadena de nombre es 1 y el valor de name[0] es un byte NULL, se produce una vulnerabilidad OOB en btf_name_valid_section() y el valor de retorno es verdadero, por lo que el nombre no válido pasa la comprobación. Para resolver esto, debe comprobar si la primera posición es un byte NULL y si el primer carácter es imprimible.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: proteger la configuración de XDP con un mutex La principal amenaza a la consistencia de los datos en ice_xdp() es un posible reinicio asincrónico de PF. Puede ser activado por un usuario o por el controlador de tiempo de espera de TX. El código de configuración de XDP y de restablecimiento de PF accede a los mismos recursos en las siguientes secciones: * ice_vsi_close() en ice_prepare_for_reset() - ya bloqueado en RTNL * ice_vsi_rebuild() para PF VSI - no protegido * ice_vsi_open() - ya bloqueado en RTNL Con un momento desafortunado, dichos accesos pueden resultar en un bloqueo como el siguiente: [ +1.999878] ice 0000:b1:00.0: Modelo de memoria XDP registrado MEM_TYPE_XSK_BUFF_POOL en el anillo Rx 14 [ +2.002992] ice 0000:b1:00.0: Modelo de memoria XDP registrado MEM_TYPE_XSK_BUFF_POOL en el anillo Rx 18 [15 de marzo 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: la cola de transmisión 14 agotó el tiempo de espera 80692736 ms [ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001 [ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout nivel de recuperación 1, txqueue 14 [ +0.394718] ice 0000:b1:00.0: restablecimiento de PTP exitoso [ +0.006184] ERROR: puntero NULL del núcleo desreferencia, dirección: 0000000000000098 [ +0.000045] #PF: acceso de lectura de supervisor en modo kernel [ +0.000023] #PF: error_code(0x0000) - página no presente [ +0.000023] PGD 0 P4D 0 [ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI [ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 No contaminado 6.8.0-rc7 #1 [ +0.000031] Nombre del hardware: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 26/08/2021 [ +0.000036] Cola de trabajo: hielo ice_service_task [hielo] [ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [hielo] [...] [ +0.000013] Rastreo de llamadas: [ +0.000016] [ +0.000014] ? __die+0x1f/0x70 [ +0.000029] ? page_fault_oops+0x171/0x4f0 [ +0.000029] ? schedule+0x3b/0xd0 [ +0.000027] ? exc_page_fault+0x7b/0x180 [ +0.000022] ? asm_exc_page_fault+0x22/0x30 [ +0.000031] ? hielo_limpio_tx_ring+0xa/0xd0 [hielo] [ +0.000194] hielo_libre_tx_ring+0xe/0x60 [hielo] [ +0.000186] hielo_destruir_xdp_rings+0x157/0x310 [hielo] [ +0.000151] hielo_vsi_decfg+0x53/0xe0 [hielo] [ +0.000180] hielo_vsi_rebuild+0x239/0x540 [hielo] [ +0.000186] hielo_vsi_rebuild_by_type+0x76/0x180 [hielo] [ +0.000145] hielo_rebuild+0x18c/0x840 [hielo] [ +0.000145] ? retraso_tsc+0x4a/0xc0 [ +0.000022] ? retraso_tsc+0x92/0xc0 [ +0.000020] hielo_do_reset+0x140/0x180 [hielo] [ +0.000886] hielo_servicio_tarea+0x404/0x1030 [hielo] [ +0.000824] proceso_una_obra+0x171/0x340 [ +0.000685] subproceso_trabajador+0x277/0x3a0 [ +0.000675] ? preempt_count_add+0x6a/0xa0 [ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50 [ +0.000679] ? La forma anterior de manejar esto mediante la devolución de -EBUSY no es viable, particularmente cuando se destruye el socket AF_XDP, porque el núcleo procede con la eliminación de todos modos. Hay mucho código entre esas llamadas y no hay necesidad de crear una gran sección crítica que las cubra todas, al igual que no hay necesidad de proteger ice_vsi_rebuild() con rtnl_lock(). Agregue el mutex xdp_state_lock para proteger ice_vsi_rebuild() y ice_xdp(). Dejar secciones desprotegidas en el medio daría como resultado dos estados que deben considerarse: 1. cuando el VSI está cerrado, pero aún no se reconstruye 2. cuando VSI ya se está reconstruyendo, pero aún no está abierto El último caso en realidad ya se maneja a través del caso !netif_running(), solo necesitamos ajustar un poco la verificación de indicadores. El primero no es tan trivial, porque entre ice_vsi_close() y ice_vsi_rebuild(), ocurre mucha interacción de hardware, esto puede hacer que agregar/eliminar anillos salga con un error. Afortunadamente, la reconstrucción de VSI está pendiente y puede aplicar una nueva configuración para nosotros de manera administrada. ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: mover netif_queue_set_napi a secciones protegidas por rtnl Actualmente, netif_queue_set_napi() se llama desde ice_vsi_rebuild() que no está bloqueado por rtnl cuando se llama desde el reinicio. Esto crea la necesidad de tomar rtnl_lock solo para una única función y complica la sincronización con .ndo_bpf. Al mismo tiempo, no hay necesidad real de completar la información de napi a cola en este punto exacto. Complete la información de napi a cola al abrir la VSI y límpiela cuando se cierre la VSI. Esas rutinas ya están bloqueadas por rtnl. Además, reescriba la asignación de napi a cola de una manera que evite la inclusión de colas XDP, ya que esto conduce a escrituras fuera de los límites, como la siguiente. [ +0.000004] ERROR: KASAN: slab-out-of-bounds en netif_queue_set_napi+0x1c2/0x1e0 [ +0.000012] Escritura de tamaño 8 en la dirección ffff889881727c80 por la tarea bash/7047 [ +0.000006] CPU: 24 PID: 7047 Comm: bash No contaminado 6.10.0-rc2+ #2 [ +0.000004] Nombre del hardware: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 26/08/2021 [ +0.000003] Seguimiento de llamadas: [ +0.000003] [ +0.000002] nivel_pila_volcado+0x60/0x80 [ +0.000007] informe_impresión+0xce/0x630 [ +0.000007] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ +0.000007] ? __virt_addr_valid+0x1c9/0x2c0 [ +0.000005] ? netif_queue_set_napi+0x1c2/0x1e0 [ +0.000003] informe_kasan+0xe9/0x120 [ +0.000004] ? netif_queue_set_napi+0x1c2/0x1e0 [ +0.000004] netif_queue_set_napi+0x1c2/0x1e0 [ +0.000005] ice_vsi_close+0x161/0x670 [hielo] [ +0.000114] ice_dis_vsi+0x22f/0x270 [hielo] [ +0.000095] ice_pf_dis_all_vsi.constprop.0+0xae/0x1c0 [hielo] [ +0.000086] ice_preparar_para_restablecer+0x299/0x750 [hielo] [ +0.000087] pci_dev_guardar_y_deshabilitar+0x82/0xd0 [ +0.000006] pci_reset_function+0x12d/0x230 [ +0.000004] reset_store+0xa0/0x100 [ +0.000006] ? __pfx_reset_store+0x10/0x10 [ +0.000002] ? __pfx_mutex_lock+0x10/0x10 [ +0.000004] ? __check_object_size+0x4c1/0x640 [ +0.000007] kernfs_fop_write_iter+0x30b/0x4a0 [ +0.000006] vfs_write+0x5d6/0xdf0 [ +0.000005] ? kasan_save_track+0x13/0x60 [ +0.000003] ? kasan_save_free_info+0x37/0x60 [ +0.000006] ksys_write+0xfa/0x1d0 [ +0.000003] ? __pfx_ksys_write+0x10/0x10 [ +0.000002] ? __x64_sys_fcntl+0x121/0x180 [ +0.000004] ? _raw_spin_lock+0x87/0xe0 [ +0.000005] hacer_syscall_64+0x80/0x170 [ +0.000007] ? _raw_spin_lock+0x87/0xe0 [ +0.000004] ? __pfx__raw_spin_lock+0x10/0x10 [ +0.000003] ? cerrar_archivo_fd_bloqueado+0x167/0x230 [ +0.000005] ? salir_syscall_al_modo_usuario+0x7d/0x220 [ +0.000005] ? __x64_sys_dup2+0x6e/0x2e0 [ +0.000002] ? syscall_salir_al_modo_usuario+0x7d/0x220 [ +0.000004] ? do_syscall_64+0x8c/0x170 [ +0.000003] ? __count_memcg_events+0x113/0x380 [ +0.000005] ? handle_mm_fault+0x136/0x820 [ +0.000005] ? do_user_addr_fault+0x444/0xa80 [ +0.000004] ? clear_bhb_loop+0x25/0x80 [ +0.000004] ? borrar_bucle_bhb+0x25/0x80 [ +0.000002] entrada_SYSCALL_64_después_de_hwframe+0x76/0x7e [ +0.000005] RIP: 0033:0x7f2033593154

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: Se corrige la falta de of_node_put() para LED. La llamada de of_get_child_by_name() hará que se incremente el recuento de referencias para los LED. Si tiene éxito, debería llamar a of_node_put() para disminuirlo y solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (hp-wmi-sensors) Verificar si existen datos de eventos de WMI El BIOS puede elegir no devolver datos de eventos en respuesta a un evento de WMI, por lo que el objeto ACPI que se pasa al controlador de notificaciones de WMI puede ser NULL. Verifique si existe tal situación e ignore el evento en ese caso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: intel: Agregar comprobación del valor devuelto por devm_kasprintf() intel_spi_populate_chip() usa devm_kasprintf() para establecer pdata->name. Esto puede devolver un puntero NULL en caso de error, pero este valor devuelto no se comprueba.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no realizar BUG_ON() cuando hay 0 referencias en btrfs_lookup_extent_info() En lugar de realizar un BUG_ON(), maneje el error devolviendo -EUCLEAN, cancelando la transacción y registrando un mensaje de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: manejo correcto de errores de btrfs_dec_ref() En walk_up_proc() ejecutamos BUG_ON(ret) desde btrfs_dec_ref(). Esto es incorrecto, aquí tenemos un manejo correcto de errores, devolvemos el error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: reemplazar BUG_ON() con manejo de errores en update_ref_for_cow() En lugar de un BUG_ON(), simplemente devuelva un error, registre un mensaje de error y cancele la transacción en caso de que encontremos un búfer de extensión que pertenezca al árbol de reubicación que no tenga el indicador backref completo establecido. Esto es inesperado y nunca debería suceder (salvo por errores o una posible mala memoria).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mwifiex: No devolver priv sin usar en mwifiex_get_priv_by_id() mwifiex_get_priv_by_id() devuelve el puntero priv correspondiente a bss_num y bss_type, pero sin comprobar si el priv está realmente en uso actualmente. Los punteros priv sin usar no tienen un wiphy adjunto a ellos, lo que puede provocar desreferencias de puntero NULL más abajo en la pila de llamadas. Solucione esto devolviendo solo punteros priv usados que tengan priv->bss_mode establecido en algo distinto de NL80211_IFTYPE_UNSPECIFIED. Dicha desreferencia de puntero NULL ocurrió cuando un Accesspoint fue iniciado con wpa_supplicant -i mlan0 con esta configuración: network={ ssid="somessid" mode=2 frequency=2412 key_mgmt=WPA-PSK WPA-PSK-SHA256 proto=RSN group=CCMP pairwise=CCMP psk="12345678" } Al esperar a que se establezca el AP, interrumpiendo wpa_supplicant con y reiniciándolo esto sucede: | No se puede manejar la desreferencia de puntero NULL del kernel en la dirección virtual 0000000000000140 | Información de aborto de memoria: | ESR = 0x0000000096000004 | EC = 0x25: DABT (EL actual), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: error de traducción de nivel 0 | Información de cancelación de datos: | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 | CM = 0, WnR = 0, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | pgtable del usuario: páginas de 4k, VA de 48 bits, pgdp=0000000046d96000 | [0000000000000140] pgd=000000000000000, p4d=0000000000000000 | Error interno: Oops: 0000000096000004 [#1] PREEMPT SMP | Módulos vinculados en: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio +mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs +imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6 | CPU: 0 PID: 8 Comm: kworker/0:1 No contaminado 6.9.0-00007-g937242013fce-dirty #18 | Nombre del hardware: somemachine (DT) | Cola de trabajo: eventos sdio_irq_work | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex] | lr : mwifiex_get_cfp+0x34/0x15c [mwifiex] | sp : ffff8000818b3a70 | x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004 | x26: 000000000000002c x25: 00000000000001511 x24: 00000000002e86bc9 | x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000 | x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000 | x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517 | x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c0100000ffb1 | x11: 0100000000000000 x10: 02e8ff43002c0100 x9: 0000ffb100100157 | x8: ffff000003d20000 x7: 00000000000002f1 x6: 00000000ffffe124 | x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000 | x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000 | Rastreo de llamadas: | mwifiex_get_cfp+0xd8/0x15c [mwifiex] | mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex] | mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex] | mwifiex_process_sta_event+0x298/0xf0c [mwifiex] | mwifiex_process_event+0x110/0x238 [mwifiex] | mwifiex_main_process+0x428/0xa44 [mwifiex] | mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio] | proceso_sdio_pending_irqs+0x64/0x1b8 | sdio_irq_work+0x4c/0x7c | proceso_one_work+0x148/0x2a0 | subproceso_trabajador+0x2fc/0x40c | kthread+0x110/0x114 | ret_from_fork+0x10/0x20 | Código: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000) | ---[ fin del seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (adc128d818) Se corrigen los desbordamientos de línea observados al escribir los atributos de límite DIV_ROUND_CLOSEST() después de que kstrtol() genere un desbordamiento de línea si el usuario proporciona un número negativo grande, como -9223372036854775808. Se soluciona reordenando las operaciones clamp_val() y DIV_ROUND_CLOSEST().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pci/hotplug/pnv_php: Se soluciona el fallo del controlador hotplug en Powernv El controlador hotplug para powerpc (pci/hotplug/pnv_php.c) provoca un fallo del kernel cuando intentamos desconectar/deshabilitar en caliente el conmutador/puente PCIe del PHB. El fallo se produce porque, aunque la estructura de datos MSI se ha liberado durante la ruta de deshabilitación/desconexión en caliente y se le ha asignado NULL, aún durante la anulación del registro el código estaba intentando de nuevo deshabilitar explícitamente el MSI, lo que provoca la desreferencia del puntero NULL y el fallo del kernel. El parche corrige la comprobación durante la ruta de anulación del registro para evitar invocar pci_disable_msi/msix() ya que su estructura de datos ya está liberada.