Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrige MST Null Ptr para RV. El cambio intenta corregir el siguiente error específico de la plataforma RV: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000008 PGD 0 P4D 0 Ups: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway No contaminado 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Nombre de hardware: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R1 2ET61W (1.31) 28/07/2022 QEPD : 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Código: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 0 0 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8af b9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 00000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 00000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8a fe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000008 CR3: 000000010ddc6000 CR4: 00000 000003506e0 Llamar Seguimiento: ? __morir+0x23/0x70 ? page_fault_oops+0x171/0x4e0? plist_add+0xbe/0x100? exc_page_fault+0x7c/0x180? asm_exc_page_fault+0x26/0x30? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e915 8e1cd0a243bdc8e6da040c054] ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243 bdc8e6da040c054] amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] drm_atomic_check_only+0x5c5/0xa40 drm_mode_atomic_ioctl+0x76e/0x bc0? _copiar_al_usuario+0x25/0x30? drm_ioctl+0x296/0x4b0? __pfx_drm_mode_atomic_ioctl+0x10/0x10 drm_ioctl_kernel+0xcd/0x170 drm_ioctl+0x26d/0x4b0 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 amdgpu_drm_ioctl+0x4e/0x90 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] __x64_sys_ioctl+0x94/0xd0 do_syscall_ 64+0x60/0x90 ? do_syscall_64+0x6c/0x90 Entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f4dad17f76f Código: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c> RSP: 002b:00007ffd9ae859f0 EFLAGS: 00000246 ORIG_RAX: 00000000000000010 RAX: ffffffffffffffda RBX: 000055e255a5590 0 RCX: 00007f4dad17f76f RDX: 00007ffd9ae85a90 RSI: 00000000c03864bc RDI: 000000000000000b RBP: 00007ffd9ae85a90 R08: 0000000000000003 R09 : 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c03864bc R13: 0000000000000000b R14: 000055e255a7fc60 R1 5: 000055e255a01eb0 Módulos vinculados en: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ccm cmac algif_hash algif_skcipher af_alg joydev mousedev bnep > typec libphy k10temp ipmi_msghandler roles i2c_scmi acpi_ cpufreq mac_hid nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_mas> CR2: 0000000000000008 ---[ final de seguimiento 00000000000000000 ]--- RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x26 0 [drm_display_helper] Código: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 00000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 ---truncado- --

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iio: magnetómetro: rm3100: agregue verificación de los límites para el valor leído de RM3100_REG_TMRC Recientemente, encontramos una falla del kernel en la función rm3100_common_probe causada por el acceso fuera de los límites de la matriz rm3100_samp_rates (debido al hardware subyacente fallas). Agregue verificación de los límites para evitar el acceso fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing/timerlat: mover hrtimer_init a timerlat_fd open() Actualmente, el hrtimer de timerlat se inicializa en la primera lectura de timerlat_fd y se destruye al cerrar(). Funciona, pero causa un error si el programa de usuario abre() y cierra() el archivo sin leerlo. Aquí hay un ejemplo: # echo NO_OSNOISE_WORKLOAD > /sys/kernel/debug/tracing/osnoise/options # echo timerlat > /sys/kernel/debug/tracing/current_tracer # cat < ./timerlat_load.py # !/usr/ bin/env python3 timerlat_fd = open("/sys/kernel/tracing/osnoise/per_cpu/cpu0/timerlat_fd", 'r') timerlat_fd.close(); EOF # ./taskset -c 0 ./timerlat_load.py ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000010 #PF: acceso de lectura del supervisor en modo kernel #PF: código_de error(0x0000) - página no presente PGD 0 P4D 0 Ups: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2673 Comm: python3 No contaminado 6.6.13-200.fc39.x86_64 #1 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16. 3-1.fc39 01/04/2014 RIP: 0010:hrtimer_active+0xd/0x50 Código: 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 8b 57 30 <8b> 42 10 a8 01 74 09 f3 90 8b 42 10 a8 01 75 f7 80 7f 38 00 75 1d RSP: 0018:ffffb031009b7e10 EF LAGS: 00010286 RAX: 000000000002db00 RBX: ffff9118f786db08 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9117a0e64400 RDI: ffff9118f786db08 RBP: ffff9118f786db80 R08: ffff9117a0ddd42 0 R09: ffff9117804d4f70 R10: 0000000000000000 R11: 0000000000000000 R12: ffff9118f786db08 R13: ffff91178fdd5e20 R14: ffff9117840978c0 R15: 000 0000000000000 FS: 00007f2ffbab1740(0000) GS:ffff9118f7840000( 0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000010 CR3: 00000001b402e000 CR4: 000000000075 0ee0 PKRU: 55555554 Seguimiento de llamadas: ? __morir+0x23/0x70 ? page_fault_oops+0x171/0x4e0? srso_alias_return_thunk+0x5/0x7f? avc_has_extended_perms+0x237/0x520? exc_page_fault+0x7f/0x180? asm_exc_page_fault+0x26/0x30? hrtimer_active+0xd/0x50 hrtimer_cancel+0x15/0x40 timerlat_fd_release+0x48/0xe0 __fput+0xf5/0x290 __x64_sys_close+0x3d/0x80 do_syscall_64+0x60/0x90 ? srso_alias_return_thunk+0x5/0x7f? __x64_sys_ioctl+0x72/0xd0? srso_alias_return_thunk+0x5/0x7f? syscall_exit_to_user_mode+0x2b/0x40? srso_alias_return_thunk+0x5/0x7f? do_syscall_64+0x6c/0x90? srso_alias_return_thunk+0x5/0x7f? exit_to_user_mode_prepare+0x142/0x1f0? srso_alias_return_thunk+0x5/0x7f? syscall_exit_to_user_mode+0x2b/0x40? srso_alias_return_thunk+0x5/0x7f? do_syscall_64+0x6c/0x90 Entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f2ffb321594 Código: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 0 0 90 f3 0f 1e fa 80 3d d5 cd 0d 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 3c c3 0f 1f 00 55 48 89 e5 48 83 ec 10 89 7d RSP: 002b:00007ffe8d8eef18 EFLAGS: 00000202 O IG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX: 00007f2ffba4e668 RCX: 00007f2ffb321594 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007ffe8d8eef40 R08: 0000000000000000 R09: 0 000000000000000 R10: 55c926e3167eae79 R11: 0000000000000202 R12: 0000000000000003 R13: 00007ffe8d8ef030 R14: 0000000000000000 R15: 0000 7f2ffba4e668 CR2: 0000000000000010 ---[ end trace 0000000000000000 ]--- Mueva hrtimer_init a timerlat_fd open() para evitar este problema.

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: BTLB: soluciona el problema al configurar BTLB al iniciar la CPU. Al usar hotplug y activar una CPU de 32 bits, solicite al firmware la información de BTLB para configurar la estática ( bloque) Entradas TLB. Para eso se necesita acceso de escritura a la estructura estática btlb_info, pero como está marcada como __ro_after_init, el kernel falla por defecto y faltan permisos de escritura. Solucione el problema eliminando la anotación __ro_after_init.

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