Vulnerabilidades

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: 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: 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: zram: arregla el puntero NULL en comp_algorithm_show() LTP informó una desreferencia de puntero NULL de la siguiente manera: CPU: 7 UID: 0 PID: 5995 Comm: cat Kdump: cargado No contaminado 6.12.0-rc6+ #3 Nombre del hardware: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __pi_strcmp+0x24/0x140 lr : zcomp_available_show+0x60/0x100 [zram] sp : ffff800088b93b90 x29: ffff800088b93b90 x28: 0000000000000001 x27: 0000000000400cc0 x26: 0000000000000ffe x25: ffff80007b3e2388 x24: 00000000000000000 x23: ffff80007b3e2390 x22: ffff0004041a9000 x21: ffff80007b3e2900 x20: 0000000000000000 x19: 00000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff80007b3e2900 x9: ffff80007b3cb280 x8: 0101010101010101 x7: 0000000000000000 x6: 0000000000000000 x5: 0000000000000040 x4 : 0000000000000000 x3 : 00656c722d6f7a6c x2 : 000000000000000 x1 : ffff80007b3e2900 x0 : 0000000000000000 Rastreo de llamadas: __pi_strcmp+0x24/0x140 comp_algorithm_show+0x40/0x70 [zram] dev_attr_show+0x28/0x80 sysfs_kf_seq_show+0x90/0x140 kernfs_seq_show+0x34/0x48 seq_read_iter+0x1d4/0x4e8 El zram->comp_algs[ZRAM_PRIMARY_COMP] puede ser NULL en zram_add() si No se ha llamado a comp_algorithm_set(). El usuario puede acceder al dispositivo zram mediante sysfs después de device_add_disk(), por lo que hay una ventana de tiempo para activar la desreferencia del puntero NULL. Muévalo hacia delante en device_add_disk() para asegurarse de que cuando el usuario pueda acceder al dispositivo zram, esté listo. comp_algorithm_set() está protegido por zram->init_lock en otros lugares y no existe ese problema.

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.

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: iommu/tegra241-cmdqv: Se corrige el error de alineación en max_n_shift Al configurar un kernel con PAGE_SIZE=4KB, dependiendo de su configuración de CONFIG_CMA_ALIGNMENT, VCMDQ_LOG2SIZE_MAX=19 podría fallar la prueba de alineación y generar un WARN_ON: ADVERTENCIA: en drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3646 Rastreo de llamadas: arm_smmu_init_one_queue+0x15c/0x210 tegra241_cmdqv_init_structures+0x114/0x338 arm_smmu_device_probe+0xb48/0x1d90 Se soluciona limitando max_n_shift a CMDQ_MAX_SZ_SHIFT como lo hace SMMUv3 CMDQ.

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: 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: scsi: bfa: Se corrige el use-after-free en bfad_im_module_exit() ERROR: KASAN: use-after-free de losa en __lock_acquire+0x2aca/0x3a20 Lectura de tamaño 8 en la dirección ffff8881082d80c8 por la tarea modprobe/25303 Seguimiento de llamadas: dump_stack_lvl+0x95/0xe0 print_report+0xcb/0x620 kasan_report+0xbd/0xf0 __lock_acquire+0x2aca/0x3a20 lock_acquire+0x19b/0x520 _raw_spin_lock+0x2b/0x40 attribute_container_unregister+0x30/0x160 Asignado por tarea 25303: pila de guardado de kasan+0x24/0x50 pista de guardado de kasan+0x14/0x30 __kasan_kmalloc+0x7f/0x90 transporte de acoplamiento de fc+0x4f/0x4740 [transporte de scsi_fc] inicio del módulo de bfad_im+0x17/0x80 [bfa] inicio del módulo de bfad_init+0x23/0xff0 [bfa] hacer una llamada de inicio+0xdc/0x550 hacer el módulo de inicio+0x22d/0x6b0 módulo de carga+0x4e96/0x5ff0 módulo de inicio desde el archivo+0xcd/0x130 módulo de inicio idempotente+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Liberado por la tarea 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x38/0x50 kfree+0x212/0x480 bfad_im_module_init+0x7e/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f El problema anterior ocurre de la siguiente manera: bfad_init error = bfad_im_module_init() fc_release_transport(bfad_im_scsi_transport_template); if (error) goto ext; ext: bfad_im_module_exit(); fc_release_transport(bfad_im_scsi_transport_template); --> Disparador de doble liberación No llame a bfad_im_module_exit() si bfad_im_module_init() falló.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/l2tp: corrección de advertencia en l2tp_exit_net encontrada por syzbot En el controlador de salida de red de l2tp, verificamos que un IDR esté vacío antes de destruirlo: WARN_ON_ONCE(!idr_is_empty(&pn->l2tp_tunnel_idr)); idr_destroy(&pn->l2tp_tunnel_idr); Al forzar fallas de asignación de memoria en idr_alloc_32, syzbot puede provocar una condición donde idr_is_empty devuelve falso a pesar de que no haya elementos en el IDR. Esto resulta ser porque el árbol de radix del IDR contiene solo nodos de árbol de radix internos y es esto lo que hace que idr_is_empty devuelva falso. Los nodos internos son limpiados por idr_destroy. Utilice idr_for_each para verificar que el IDR esté vacío en lugar de idr_is_empty para evitar el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netlink: corrige la advertencia de falso positivo en extack durante los volcados Commit bajo corrige el informe extendido de extack a los volcados. Funciona en condiciones normales, porque los errores de extack generalmente se informan durante ->start() o el primer ->dump(), es bastante raro que el volcado comience bien pero falle más tarde. Sin embargo, si el volcado falla más tarde, el skb de entrada ya tendrá el mensaje de inicio extraído, por lo que la verificación de si el atributo incorrecto cae dentro de skb->data fallará. Cambie la verificación para usar nlh, que siempre es válido. syzbot encontró una forma de abordar ese escenario llenando la cola de recepción. En este caso, iniciamos un volcado pero no llamamos a ->dump() hasta que haya espacio de lectura para un skb. ADVERTENCIA: CPU: 1 PID: 5845 en net/netlink/af_netlink.c:2210 netlink_ack_tlv_fill+0x1a8/0x560 net/netlink/af_netlink.c:2209 RIP: 0010:netlink_ack_tlv_fill+0x1a8/0x560 net/netlink/af_netlink.c:2209 Seguimiento de llamadas: netlink_dump_done+0x513/0x970 net/netlink/af_netlink.c:2250 netlink_dump+0x91f/0xe10 net/netlink/af_netlink.c:2351 netlink_recvmsg+0x6bb/0x11d0 net/netlink/af_netlink.c:1983 sock_recvmsg_nosec net/socket.c:1051 [en línea] sock_recvmsg+0x22f/0x280 net/socket.c:1073 __sys_recvfrom+0x246/0x3d0 net/socket.c:2267 __do_sys_recvfrom net/socket.c:2285 [en línea] __se_sys_recvfrom net/socket.c:2281 [en línea] __x64_sys_recvfrom+0xde/0x100 net/socket.c:2281 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entrada_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff37dd17a79