Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: hsr: eliminar WARN_ONCE() en send_hsr_supervision_frame() Syzkaller informó [1] que apareció una advertencia después de no poder asignar recursos para skb en hsr_init_skb(). Dado que una llamada WARN_ONCE() no ayudará mucho en este caso, podría ser prudente cambiar a netdev_warn_once(). Como mínimo, suprimirá informes de syzkaller como [1]. Por las dudas, utilice netdev_warn_once() en send_prp_supervision_frame() por motivos similares. [1] HSR: No se pudo enviar la trama de supervisión ADVERTENCIA: CPU: 1 PID: 85 en net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294 RIP: 0010:send_hsr_supervision_frame+0x60a/ 0x810 net/hsr/hsr_device.c:294 ... Seguimiento de llamadas: hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700 expire_timers kernel/ time/timer.c:1751 [en línea] __run_timers+0x764/0xb20 kernel/time/timer.c:2022 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035 __do_softirq+0x21a/0x8de kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [en línea] __irq_exit_rcu kernel/softirq.c:632 [en línea] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c :1076 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649 ... Este problema también se encuentra en kernels más antiguos (al menos hasta 5.10).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: realmente se adapta a la ejecución fastopen. El cierre del subflujo Fastopen y PM-trigger puede correr, según lo informado por syzkaller. En mi primer intento de cerrar dicha ejecución, me perdí el hecho de que el estado del subflujo puede cambiar nuevamente antes de que se invoque la devolución de llamada subflow_state_change. Solucione el problema copiando adicionalmente todos los estados a los que se puede acceder directamente desde TCP_FIN_WAIT1.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/iommu: corrige el iommu_group_put() que falta durante la conexión del dominio de la plataforma. Falta la función spapr_tce_platform_iommu_attach_dev() para llamar a iommu_group_put() cuando el dominio ya está configurado. Esta fuga de recuento aparece con BUG_ON() durante la operación de eliminación de DLPAR como: KernelBug: Error del kernel en estado 'Ninguno': ERROR del kernel en arch/powerpc/platforms/pseries/iommu.c:100. Vaya: Excepción en modo kernel, sign: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=8192 NUMA pSeries Nombre de hardware: IBM,9080-HEX POWER10 (sin formato) 0x800200 0xf000006 of:IBM,FW1060. 00 (NH1060_016) hv:phyp pSeries NIP: c0000000000ff4d4 LR: c0000000000ff4cc CTR: 0000000000000000 REGS: c0000013aed5f840 TRAP: 0700 Contaminado: GI (6.8.0-rc3-autotest-g9 9bd3cb0d12e) MSR: 8000000000029033 CR: 44002402 XER: 20040000 CFAR: c000000000a0d170 IRQMASK: 0 ... NIP iommu_reconfig_notifier+0x94/0x200 LR iommu_reconfig_notifier+0x8c/0x200 Seguimiento de llamadas: iommu_reconfig_notifier+0x8c/0x2 00 (no confiable) notifier_call_chain+0xb8/0x19c blocking_notifier_call_chain+ 0x64/0x98 of_reconfig_notify+0x44/0xdc of_detach_node+0x78/0xb0 ofdt_write.part.0+0x86c/0xbb8 proc_reg_write+0xf4/0x150 vfs_write+0xf8/0x488 ksys_write+0x84/0x140 system_call_exception+0x1 38/0x330 system_call_vectored_common+0x15c/0x2ec El parche agrega la llamada faltante a iommu_group_put().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iio: adc: ad4130: datos de inicio de reloj con inicialización cero La estructura clk_init_data no tiene todos sus miembros inicializados, lo que causa problemas al intentar exponer el reloj interno en el pin CLK. Solucione este problema inicializando a cero la estructura clk_init_data.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/kasan: corrige el error de dirección causado por la alineación de la página En kasan_init_region, cuando k_start no está alineado con la página, al comienzo del bucle for, k_cur = k_start y PAGE_MASK es menor que k_start. y luego `va = block + k_cur - k_start` es menor que block, la dirección va no es válida, porque memblock_alloc no asigna el espacio de direcciones de memoria de va al bloque, que no será reservado por memblock_reserve más adelante, se utilizará por otros lugares. Como resultado, se produce una sobrescritura de la memoria. por ejemplo: int __init __weak kasan_init_region(void *start, size_t size) { [...] /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */ block = memblock_alloc(k_end - k_start, PAGE_SIZE); [...] for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) { /* al comienzo del bucle for * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400) * va (dcd96c00) es menor que block(dcd97000), va no es válido */ void *va = block + k_cur - k_start; [...] } [...] } Por lo tanto, la alineación de la página se realiza en k_start antes de memblock_alloc() para garantizar la validez de la dirección VA.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pseries/iommu: corrige la inicialización de iommu durante la adición de DLPAR Cuando se agrega dinámicamente un dispositivo PCI, el kernel falla con una desreferencia del puntero NULL: ERROR: desreferencia del puntero NULL del kernel al leer en 0x00000030 Dirección de instrucción errónea: 0xc0000000006bbe5c Vaya: acceso al kernel del área defectuosa, firma: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Módulos vinculados en: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_rpcg ss nfsv4 dns_resolver nfs lockd gracia fscache netfs xsk_diag vinculación nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod fusible CPU: 17 PID: 2685 Comm: drmgr Not tainted 6.7.0-203405+ #66 Nombre de hardware: IBM,9080-HEX POWER10 (sin formato) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c0000000006bbe5c LR: c000000000a13e68 CTR: c0000000000579f8 REGS: c00000009924f240 TRAP: 0300 No contaminado (6.7.0-203405+) MSR: 80000000000009033 CR: 24002220 XER: 20040006 CF AR: c000000000a13e64 DAR: 0000000000000030DSISR : 40000000 IRQMASK: 0 ... NIP sysfs_add_link_to_group+0x34/0x94 LR iommu_device_link+0x5c/0x118 Rastreo de llamadas: iommu_init_device+0x26c/0x318 (no confiable) iommu_device_link+0x5c/0x118 iommu_init_ dispositivo+0xa8/0x318 iommu_probe_device+0xc0/0x134 iommu_bus_notifier+0x44/ 0x104 notifier_call_chain+0xb8/0x19c blocking_notifier_call_chain+0x64/0x98 bus_notify+0x50/0x7c device_add+0x640/0x918 pci_device_add+0x23c/0x298 of_create_pci_dev+0x400/0x884 of_scan_pci_ dev+0x124/0x1b0 __of_scan_bus+0x78/0x18c pcibios_scan_phb+0x2a4/0x3b0 init_phb_dynamic+0xb8/ 0x110 dlpar_add_slot+0x170/0x3b8 [rpadlpar_io] add_slot_store.part.0+0xb4/0x130 [rpadlpar_io] kobj_attr_store+0x2c/0x48 sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x2 90 vfs_write+0x350/0x4a0 ksys_write+0x84/0x140 system_call_exception+0x124/ 0x330 system_call_vectored_common+0x15c/0x2ec el commit a940904443e4 ("powerpc/iommu: agregue iommu_ops para informar capacidades y permitir dominios de bloqueo") rompió la adición DLPAR de dispositivos PCI. Lo anterior agregó la estructura iommu_device a pci_controller. Durante el arranque del SYSTEM, se descubren dispositivos PCI y esta estructura iommu_device recién agregada se inicializa mediante una llamada a iommu_device_register(). Durante la adición DLPAR de un dispositivo PCI, se asigna una nueva estructura pci_controller pero no se realizan llamadas a la interfaz iommu_device_register(). La solución es registrar también el dispositivo iommu durante la adición de DLPAR. [mpe: Recorte Ups y modifique algunas palabras del registro de cambios]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: interconexión: qcom: sc8180x: Mark CO0 BCM keepalive El CO0 BCM debe estar activo en todo momento; de lo contrario, algún hardware (como el controlador UFS) pierde su conexión con el resto del SoC, lo que provocó un bloqueo de la plataforma, acompañado de un espectacular logspam. Márquelo como keepalive para evitar tales casos.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: dwc3: gadget: corrige la desreferencia del puntero NULL en dwc3_gadget_suspend En el escenario actual, si el Plug-out y el Plug-In se ejecutan continuamente, podría haber una posibilidad al verificar dwc->gadget_driver en dwc3_gadget_suspend, puede ocurrir una desreferencia del puntero NULL. Pila de llamadas: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 básicamente borra la variable y CPU2 verifica la variable. Considere que CPU1 se está ejecutando y justo antes de que se borre gadget_driver y en paralelo CPU2 ejecuta dwc3_gadget_suspend donde encuentra dwc->gadget_driver que no es NULL y reanuda la ejecución y luego CPU1 completa la ejecución. CPU2 ejecuta dwc3_disconnect_gadget donde verifica que dwc->gadget_driver ya sea NULL debido a lo cual se produce la deferencia del puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: core: evita la desreferencia del puntero nulo en update_port_device_state Actualmente, la función update_port_device_state obtiene el usb_hub de udev->parent llamando a usb_hub_to_struct_hub. Sin embargo, en caso de que actconfig o maxchild sean 0, usb_hub sería NULL y, al acceder más para obtener port_dev, se produciría una desreferencia del puntero nulo. Solucione este problema introduciendo una verificación if después de que se complete usb_hub.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: HID: i2c-hid-of: corrige NULL-deref en caso de encendido fallido Hace un tiempo, la implementación de I2C HID se dividió en una parte ACPI y OF, pero el nuevo controlador OF nunca Inicializa el puntero del cliente al que se le quita la referencia en caso de fallos de encendido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm-crypt, dm-verity: deshabilitar tasklets Los tasklets tienen un problema inherente con la corrupción de la memoria. La función tasklet_action_common llama a tasklet_trylock, luego llama a la devolución de llamada del tasklet y luego llama a tasklet_unlock. Si la devolución de llamada del tasklet libera la estructura que contiene el tasklet o si llama a algún código que pueda liberarlo, tasklet_unlock escribirá en la memoria libre. Las confirmaciones 8e14f610159d y d9a02e016aaf intentan solucionarlo para dm-crypt, pero no es una solución suficiente y la corrupción de datos aún puede ocurrir [1]. No hay ninguna solución para dm-verity y dm-verity escribirá en la memoria libre con cada biografía procesada por tasklet. Habrá colas de trabajo atómicas implementadas en el kernel 6.9 [2]. Tendrán una mejor interfaz y no sufrirán el problema de corrupción de memoria. Pero necesitamos algo que detenga la corrupción de la memoria ahora y que pueda ser compatible con los núcleos estables. Entonces, propongo esta confirmación que deshabilita los tasklets tanto en dm-crypt como en dm-verity. Esta confirmación no elimina la compatibilidad con el tasklet, porque el código del tasklet se reutilizará cuando se implementen las colas de trabajo atómicas. [1] https://lore.kernel.org/all/d390d7ee-f142-44d3-822a-87949e14608b@suse.de/T/ [2] https://lore.kernel.org/lkml/20240130091300.2968534-1- tj@kernel.org/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nuevo: descargar valla uevents work to workqueue Esto debería romper el punto muerto entre el bloqueo fctx y el bloqueo irq. Esto descarga el procesamiento del trabajo del irq a una cola de trabajo.