Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: gestiona lclusters NONHEAD !delta[1] con gracia syzbot informó una ADVERTENCIA en iomap_iter_done: iomap_fiemap+0x73b/0x9b0 fs/iomap/fiemap.c:80 ioctl_fiemap fs/ioctl.c:220 [en línea] Generalmente, los lclusters NONHEAD no tendrán delta[1]==0, excepto para imágenes y sistemas de archivos creados por versiones de mkfs anteriores a la 1.0. Anteriormente, se cancelaba inmediatamente si delta[1]==0, lo que provocaba longitudes descomprimidas inadecuadas (por lo tanto, FIEMAP se ve afectado). Trátelo como delta[1]=1 para solucionar estas versiones heredadas de mkfs. `lclusterbits > 14` es ilegal para índices compactos, también genera un error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: se corrigen los montajes respaldados por archivos sobre FUSE syzbot informó de un null-ptr-deref en fuse_read_args_fill: fuse_read_folio+0xb0/0x100 fs/fuse/file.c:905 filemap_read_folio+0xc6/0x2a0 mm/filemap.c:2367 do_read_cache_folio+0x263/0x5c0 mm/filemap.c:3825 read_mapping_folio include/linux/pagemap.h:1011 [en línea] erofs_bread+0x34d/0x7e0 fs/erofs/data.c:41 erofs_read_superblock fs/erofs/super.c:281 [en línea] erofs_fc_fill_super+0x2b9/0x2500 fs/erofs/super.c:625 A diferencia de la mayoría de los sistemas de archivos, algunos sistemas de archivos de red y FUSE necesitan punteros de `archivo` válidos e inevitables para sus E/S de lectura [1]. De todos modos, esos casos de uso también deben ser compatibles. [1] https://docs.kernel.org/filesystems/vfs.html

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: CPPC: Se corrige la posible desreferenciación de puntero nulo para cppc_get_cpu_cost(). cpufreq_cpu_get_raw() puede devolver NULL si la CPU no está en la máscara de CPU policy->cpus y provocará una desreferenciación de puntero nulo, así que verifique NULL para cppc_get_cpu_cost().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: CPPC: Se corrige la posible desreferenciación de puntero nulo para cpufreq_cpu_get_raw(). cpufreq_cpu_get_raw() puede devolver NULL si la CPU no está en la máscara de CPU policy->cpus y provocará una desreferenciación de puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: kvm: Fix out-of-bounds array access En kvm_riscv_vcpu_sbi_init(), entry->ext_idx puede contener un índice fuera de los límites. Esto se utiliza como un marcador especial para las extensiones base, que no se pueden deshabilitar. Sin embargo, al recorrer las extensiones, ese marcador especial no se verifica antes de indexar la matriz. Agregue una verificación fuera de los límites a la función.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: unicode: Fix utf8_load() error path utf8_load() solicita el símbolo "utf8_data_table" y luego verifica si la versión UTF-8 solicitada es compatible. Si no es compatible, intenta poner la tabla de datos usando symbol_put(). Si se solicita una versión no compatible, symbol_put() falla de la siguiente manera: kernel BUG at kernel/module/main.c:786! RIP: 0010:__symbol_put+0x93/0xb0 Call Trace: ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __symbol_put+0x93/0xb0 ? exc_invalid_op+0x51/0x70 ? __symbol_put+0x93/0xb0 ? asm_exc_invalid_op+0x1a/0x20 ? __pfx_cmp_name+0x10/0x10 ? __symbol_put+0x93/0xb0 ? __symbol_put+0x62/0xb0 utf8_load+0xf8/0x150 Esto sucede porque symbol_put() espera la cadena única que identifica el símbolo, en lugar de un puntero al símbolo cargado. Solucione esto utilizando dicha cadena.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/s390: Implementar dominio de bloqueo Esto corrige un fallo al desconectar en caliente por sorpresa un dispositivo PCI. Este fallo ocurre porque durante la desconexión en caliente __iommu_group_set_domain_nofail() la conexión del dominio predeterminado falla cuando la plataforma ya no reconoce el dispositivo porque ya se ha eliminado y terminamos con un puntero de dominio NULL y UAF. Este es exactamente el caso al que se hace referencia en el segundo comentario en __iommu_device_set_domain() y tal como se indica allí, si en su lugar podemos conectar el dominio de bloqueo, se evita el UAF ya que puede gestionar el dispositivo ya eliminado. Implemente el dominio de bloqueo para usar esta gestión. Con este cambio, el fallo se corrige, pero aún encontramos una advertencia al intentar cambiar la propiedad de DMA en un dispositivo bloqueado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/hns: Se corrige la desreferenciación de puntero NULL en hns_roce_map_mr_sg() ib_map_mr_sg() permite que los ULP especifiquen NULL como argumento sg_offset. El controlador debe verificar si es un puntero NULL antes de desreferenciarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección de null-ptr-deref en f2fs_submit_page_bio() Existe el siguiente problema al instalar simultáneamente el módulo f2fs.ko y montar el sistema de archivos f2fs: KASAN: null-ptr-deref en el rango [0x0000000000000020-0x0000000000000027] RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs] Seguimiento de llamadas: f2fs_submit_page_bio+0x126/0x8b0 [f2fs] __get_meta_page+0x1d4/0x920 [f2fs] get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs] El problema anterior ocurre porque el biset del sistema de archivos f2fs no está configurado inicializado antes de registrar "f2fs_fs_type". Para solucionar el problema anterior, simplemente registre "f2fs_fs_type" al final de init_f2fs_fs(). Asegúrese de que todos los recursos del sistema de archivos f2fs estén inicializados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/mlx5: mover el registro del notificador de eventos para que esté después del registro del dispositivo. Mueva la inicialización y desinfección del trabajo de cambio de clave p de la etapa de recursos del dispositivo a la etapa del notificador, ya que esta es la etapa que gestiona estos eventos de trabajo. Corrija una ejecución entre la anulación del registro del dispositivo y el trabajo de cambio de clave p moviendo MLX5_IB_STAGE_DEVICE_NOTIFIER para que esté después de MLX5_IB_STAGE_IB_REG para garantizar que el notificador se anule el registro antes que el dispositivo durante la desinfección. Esto garantiza que no haya trabajos que se ejecuten después de que el dispositivo ya se haya anulado el registro, lo que puede causar el pánico a continuación. ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: cargado Tainted: GW OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1 Nombre del hardware: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 27/02/2023 Cola de trabajo: eventos pkey_change_handler [mlx5_ib] RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib] Código: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 <4c> 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40 RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36 RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128 RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001 R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000 R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905 FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib] process_one_work+0x1e8/0x3c0 worker_thread+0x50/0x3b0 ? rescuer_thread+0x380/0x380 kthread+0x149/0x170 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 Módulos vinculados en: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd Grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [última descarga: ib_core] CR2: 000000000000000 ---[ fin del seguimiento f6f8be4eae12f7bc ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para contabilizar datos sucios en __get_secs_required() Activará el pánico del sistema con el caso de prueba en [1]: ------------[ corte aquí ]------------ ¡ERROR del kernel en fs/f2fs/segment.c:2752! RIP: 0010:new_curseg+0xc81/0x2110 Seguimiento de llamadas: f2fs_allocate_data_block+0x1c91/0x4540 do_write_page+0x163/0xdf0 f2fs_outplace_write_data+0x1aa/0x340 f2fs_do_write_data_page+0x797/0x2280 f2fs_write_single_data_page+0x16cd/0x2190 f2fs_write_cache_pages+0x994/0x1c80 f2fs_write_data_pages+0x9cc/0xea0 do_writepages+0x194/0x7a0 filemap_fdatawrite_wbc+0x12b/0x1a0 __filemap_fdatawrite_range+0xbb/0xf0 file_write_and_wait_range+0xa1/0x110 f2fs_do_sync_file+0x26f/0x1c50 f2fs_sync_file+0x12b/0x1d0 vfs_fsync_range+0xfa/0x230 do_fsync+0x3d/0x80 __x64_sys_fsync+0x37/0x50 x64_sys_call+0x1e88/0x20d0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e La causa raíz es que si checkpoint_disabling y lfs_mode están activados, se activará OPU para todos los datos sobrescritos, lo que puede costar más segmento libre de lo esperado, por lo que f2fs debe tener en cuenta esos datos correctamente para calcular los segmentos libres consumidos más tarde y devolver ENOSPC antes para evitar quedarse sin segmentos libres durante la asignación de bloques. [1] https://lore.kernel.org/fstests/20241015025106.3203676-1-chao@kernel.org/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: ralink: mtmips: corrige el orden de sondeo de los relojes en los SoC ralink más antiguos Los relojes base son los primeros en ser sondeados y son dependencias reales del resto de relojes fijos, de factor y periféricos. Para los antiguos SoCs ralink RT2880, RT305x y RT3883, se debe definir primero 'xtal' ya que en cualquier otro caso, cuando se prueban relojes fijos, se retrasan hasta que se prueba 'xtal', por lo que aparece la siguiente advertencia: ADVERTENCIA: CPU: 0 PID: 0 en drivers/clk/ralink/clk-mtmips.c:499 rt3883_bus_recalc_rate+0x98/0x138 Módulos vinculados en: CPU: 0 PID: 0 Comm: swapper No contaminado 6.6.43 #0 Pila: 805e58d0 00000000 00000004 8004f950 00000000 00000004 00000000 00000000 80669c54 80830000 80700000 805ae570 80670068 00000001 80669bf8 00000000 00000000 00000000 805ae570 80669b38 00000020 804db7dc 00000000 00000000 203a6d6d 80669b78 80669e48 70617773 00000000 805ae570 00000000 00000009 00000000 00000001 00000004 00000001 00000000 00000000 83fe43b0 00000000 ... Seguimiento de llamadas: [<800065d0>] show_stack+0x64/0xf4 [<804bca14>] dump_stack_lvl+0x38/0x60 [<800218ac>] __warn+0x94/0xe4 [<8002195c>] warn_slowpath_fmt+0x60/0x94 [<80259ff8>] rt3883_bus_recalc_rate+0x98/0x138 [<80254530>] __clk_register+0x568/0x688 [<80254838>] of_clk_hw_register+0x18/0x2c [<8070b910>] rt2880_clk_of_clk_init_driver+0x18c/0x594 [<8070b628>] of_clk_init+0x1c0/0x23c [<806fc448>] plat_time_init+0x58/0x18c [<806fdaf0>] time_init+0x10/0x6c [<806f9bc4>] start_kernel+0x458/0x67c ---[ fin de seguimiento 0000000000000000 ]--- Cuando se incorporó este controlador, no pudimos encontrar ningún usuario activo de SoC ralink antiguos, por lo que no podemos realizar ninguna prueba real para ellos. Ahora, un usuario de un dispositivo Belkin f9k1109 versión 1 que usa RT3883 SoC apareció y reportó algunos problemas en openWRT: - https://github.com/openwrt/openwrt/issues/16054 Por lo tanto, defina un 'rt2880_xtal_recalc_rate()' que simplemente devuelva la frecuencia esperada de 40Mhz y úselo junto con los viejos SoC ralink para tener un seguimiento de arranque correcto sin advertencias y un plan de reloj que funcione desde el principio.