Vulnerabilidades

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

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/writeback: corrige la posible división por cero en wb_dirty_limits(), nuevamente (struct dirty_throttle_control *)->thresh es un largo sin firmar, pero se pasa como argumento del divisor u32 a div_u64(). En arquitecturas donde la longitud sin firmar es de 64 bytes, el argumento se truncará implícitamente. Utilice div64_u64() en lugar de div_u64() para que el valor utilizado en la comprobación "¿Es esta una división segura" sea el mismo que el divisor? Además, elimine la conversión redundante del numerador a u64, ya que eso debería suceder implícitamente. Esto sería difícil de explotar en el dominio memcg, dado el uso de la aritmética basada en proporciones domain_drity_limits(), pero es mucho más fácil en el dominio de reescritura global con un dispositivo de respaldo BDI_CAP_STRICTLIMIT, usando, por ejemplo, vm.dirty_bytes=(1<<32)*PAGE_SIZE de modo que dtc->thresh == (1<<32)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrige la doble liberación de bloques debido a extensiones incorrectas. moving_len En ext4_move_extents(), move_len solo se actualiza cuando todos los movimientos se ejecutan exitosamente y solo descarta las preasignaciones de orig_inode y donante_inode cuando se mueve_len no es cero. Cuando el bucle no sale después de mover con éxito algunas extensiones, moving_len no se actualiza y permanece en 0, por lo que no descarta las asignaciones previas. Si las extensiones movidas se superponen con las extensiones preasignadas, las extensiones superpuestas se liberan dos veces en ext4_mb_release_inode_pa() y ext4_process_freed_data() (como se describe en el commit 94d7c16cbbbd ("ext4: corrige la doble liberación de bloques con EXT4_IOC_MOVE_EXT")), y se incrementa bb_free dos veces. Por lo tanto, cuando se ejecuta trim, se activa un error de división cero en mb_update_avg_fragment_size() porque bb_free no es cero y bb_fragments es cero. Por lo tanto, actualice move_len después de cada movimiento de extensión para evitar el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: parisc: corrige la corrupción aleatoria de datos del controlador de excepciones La implementación actual del controlador de excepciones, que ayuda al acceder a la memoria del espacio del usuario, puede exhibir corrupción aleatoria de datos si el compilador decide usar un registro diferente al el registro especificado %r29 (definido en ASM_EXCEPTIONTABLE_REG) para el código de error. Si el compilador elige otro registro, el manejador de fallas almacenará -EFAULT en %r29 y, por lo tanto, eliminará cualquier cosa para la que se utilice este registro. Al observar el ensamblaje, encontré que esto sucede a veces en emulate_ldd(). Para resolver el problema, la solución más sencilla sería si de alguna manera fuera posible decirle al manejador de fallas qué registro se utiliza para contener el código de error. No es posible usar %0 o %1 en el ensamblador en línea ya que aparecerá, por ejemplo, como %r29 (con el prefijo "%r"), que el ensamblador GNU no puede convertir a un número entero. Este parche adopta otro enfoque mejor y más flexible: ampliamos el __ex_table (que está fuera de la ruta de ejecución) en 32 palabras. En esta palabra le decimos al compilador que inserte la instrucción ensambladora "o %r0,%r0,%reg", donde %reg hace referencia al registro que el compilador eligió para el código de retorno de error. En caso de un error de acceso, el controlador de fallas encuentra la entrada __ex_table y puede examinar el código de operación. El registro utilizado está codificado en los 5 bits más bajos y el manejador de fallas puede almacenar -EFAULT en este registro. Dado que ampliamos __ex_table a 3 palabras, ya no podemos usar la opción de configuración BUILDTIME_TABLE_SORT.

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: 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/