Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: flow_dissector: use DEBUG_NET_WARN_ON_ONCE El siguiente símbolo es fácil de reproducir tanto en núcleos anteriores como en núcleos estables. Florian Westphal proporcionó la siguiente confirmación: d1dab4f71d37 ("net: add and use __skb_get_hash_metric_net") pero Willem de Bruijn también sugirió esta solución complementaria y se puede retroportar fácilmente al kernel estable, que consiste en usar DEBUG_NET_WARN_ON_ONCE en lugar de silenciar lo siguiente splat dado __skb_get_hash() es utilizado por la infraestructura de seguimiento de nftables para identificar paquetes en los seguimientos. [69133.561393] ------------[ cortar aquí ]------------ [69133.561404] ADVERTENCIA: CPU: 0 PID: 43576 en net/core/flow_dissector.c :1104 __skb_flow_dissect+0x134f/ [...] [69133.561944] CPU: 0 PID: 43576 Comm: socat No contaminado 6.10.0-rc7+ #379 [69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0 133.561970] Código: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ff ff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff <0f> 0b e9 20 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8 [69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246 [69133.561988] RAX: 00000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19 [69133.561994] RDX: dffffc0000000000 RSI: ffffc900000007388 RDI: ffff888103a1b418 [69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000 [69133.562007] R10: ffffc90000007388 R11: fffffff810cface 2: ffff888103a1b400 [69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28 [69133.562020] FS: 00007f40f7131740(000 0) GS:ffff888390800000(0000 ) knlGS:0000000000000000 [69133.562027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [69133.562033] CR2: 00007f40f7346ee0 CR3: 5d200001 CR4: 00000000001706f0 [69133.562040] Seguimiento de llamadas: [69133.562044] [69133.562049] ? __advertir+0x9f/0x1a0 [ 1211.841384] ? __skb_flow_dissect+0x107e/0x2860 [...] [ 1211.841496] ? bpf_flow_dissect+0x160/0x160 [ 1211.841753] __skb_get_hash+0x97/0x280 [ 1211.841765] ? __skb_get_hash_metric+0x230/0x230 [1211.841776]? mod_find+0xbf/0xe0 [1211.841786]? get_stack_info_noinstr+0x12/0xe0 [1211.841798]? bpf_ksym_find+0x56/0xe0 [1211.841807]? __rcu_read_unlock+0x2a/0x70 [1211.841819] nft_trace_init+0x1b9/0x1c0 [nf_tables] [1211.841895]? nft_trace_notify+0x830/0x830 [nf_tables] [1211.841964]? get_stack_info+0x2b/0x80 [1211.841975]? nft_do_chain_arp+0x80/0x80 [nf_tables] [ 1211.842044] nft_do_chain+0x79c/0x850 [nf_tables]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipvs: desreferenciar correctamente pe en ip_vs_add_service Utilice pe directamente para resolver la advertencia dispersa: net/netfilter/ipvs/ip_vs_ctl.c:1471:27: advertencia: desreferencia de la expresión noderef

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: fsl: fsl_qmc_audio: comprobar el valor devuelto de devm_kasprintf() devm_kasprintf() puede devolver un puntero NULL en caso de error, pero este valor devuelto no se comprueba. Solucione esta falta y verifique el valor devuelto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: corrige la ejecución en z_erofs_get_gbuf() En z_erofs_get_gbuf(), la tarea actual se puede migrar a otra CPU entre `z_erofs_gbuf_id()` y `spin_lock(&gbuf->lock)` . Por lo tanto, z_erofs_put_gbuf() desencadenará el siguiente problema que se encontró en la prueba de estrés: <2>[772156.434168] ERROR del kernel en fs/erofs/zutil.c:58. .. <4>[772156.435007] <4>[772156.439237] CPU: 0 PID: 3078 Comm: estrés Kdump: cargado Contaminado: GE 6.10.0-rc7+ #2 <4>[772156.439239] Nombre de hardware: Alibaba Cloud Alibaba Cloud ECS , BIOS 1.0.0 01/01/2017 <4>[772156.439241] pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) <4>[772156.439243] pc: z_erofs_put_gbuf+0x64/0x70 [erofs] <4>[772156.439252] lr: z_erofs_lz4_decompress+0x600/0x6a0 [erofs] .. <6>[772156.445958] estrés (3127): drop_caches: 1 <4>[772156.446120] Rastreo de llamadas: <4>[772156. 446121] z_erofs_put_gbuf+0x64/0x70 [erofs] <4>[772156.446761] z_erofs_lz4_decompress+0x600/0x6a0 [erofs] <4>[772156.446897] z_erofs_decompress_queue+0x740/0xa10 [erofs <4>[ 772156.447036] z_erofs_runqueue+0x428/0x8c0 [erofs] <4>[772156.447160] z_erofs_readahead+0x224/0x390 [erofs] ..

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: imx-pxp: corrija la desreferencia de ERR_PTR en pxp_probe() devm_regmap_init_mmio() puede fallar, agregue una verificación y rescate en caso de error.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: Verifique el puntero NULL [por qué y cómo] Es necesario asegurarse de que plane_state esté inicializado antes de acceder a sus miembros. (cereza escogida del commit 295d91cbc700651782a60572f83c24861607b648)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: maneja el estado inconsistente en nilfs_btnode_create_block() Syzbot informó que se detectó una inconsistencia en el estado del búfer en nilfs_btnode_create_block(), lo que provocó un error en el kernel. No es apropiado tratar esta inconsistencia como un error; puede ocurrir si la dirección del bloque de argumentos (el índice del búfer del bloque recién creado) es un número de bloque virtual y se ha reasignado debido a la corrupción del mapa de bits utilizado para administrar su estado de asignación. Por lo tanto, modifique nilfs_btnode_create_block() y sus llamadores para tratarlo como un posible error del sistema de archivos, en lugar de desencadenar un error del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrige el valor de retorno de f2fs_convert_inline_inode() Si el dispositivo es de solo lectura, haga que f2fs_convert_inline_inode() devuelva EROFS en lugar de cero; de lo contrario, puede provocar pánico durante la reescritura de la página sucia del inodo en línea como se muestra a continuación : f2fs_write_single_data_page+0xbb6/0x1e90 fs/f2fs/data.c:2888 f2fs_write_cache_pages fs/f2fs/data.c:3187 [en línea] __f2fs_write_data_pages fs/f2fs/data.c:3342 [en línea] efe/0x3a90 fs/f2fs/ data.c:3369 do_writepages+0x359/0x870 mm/page-writeback.c:2634 filemap_fdatawrite_wbc+0x125/0x180 mm/filemap.c:397 __filemap_fdatawrite_range mm/filemap.c:430 [en línea] file_write_and_wait_range+0x1aa/0x290 mm/filemap .c:788 f2fs_do_sync_file+0x68a/0x1ae0 fs/f2fs/file.c:276 generic_write_sync include/linux/fs.h:2806 [en línea] f2fs_file_write_iter+0x7bd/0x24e0 fs/f2fs/file.c:4977 call_write_iter include/linux/ fs.h:2114 [en línea] new_sync_write fs/read_write.c:497 [en línea] vfs_write+0xa72/0xc90 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/ common.c:52 [en línea] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: f2fs: solución para no ensuciar el inodo para el sistema de archivos de solo lectura syzbot informa el error de f2fs como se muestra a continuación: ¡ERROR del kernel en fs/f2fs/inode.c:933! RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933 Seguimiento de llamadas: desalojar+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [en línea] evict_inodes+0x5f8/0x690 fs /inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 desactivar_locked_super+0xc1/0x130 fs /super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h :411 [en línea] ptrace_report_syscall_exit include/linux/ptrace.h:473 [en línea] syscall_exit_work kernel/entry/common.c:251 [en línea] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [en línea] __syscall_exit_to_user_mode_work kernel/entry/common .c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6b The root cause is: - do_sys_open - f2fs_lookup - __f2fs_find_entry - f2fs_i_ Depth_write - f2fs_mark_inode_dirty_sync - f2fs_dirty_inode - set_inode_flag(inode, FI_DIRTY_INODE) - umount - kill_f2fs_super - kill_block_super - generic_shutdown_super - sync_filesystem: sb es de solo lectura, omitir sync_file sistema() - evict_inodes - iput - f2fs_evict_inode - f2fs_bug_on(sbi, is_inode_flag_set(inodo, FI_DIRTY_INODE)): desencadena el pánico en el kernel Cuando intentamos reparar i_current_ Depth en un sistema de archivos de solo lectura, omitamos el inodo sucio para evitar el pánico en f2fs_evict_inode().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Actualizar registro->página_{máscara,bits} si se cambia registro->tamaño_página. Si un sistema de archivos NTFS está montado en otro sistema con PAGE_SIZE diferente al sistema original, log->page_size cambiará en log_replay(), pero log->page_{mask,bits} no cambia en consecuencia. Esto provocará pánico porque "u32 bytes = log->page_size - page_off" obtendrá un valor negativo en read_log_page() posterior.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dev/parport: corrige el riesgo de que la matriz esté fuera de los límites. Se corrigieron los problemas de matriz fuera de los límites causados por sprintf reemplazándolo con snprintf para una copia de datos más segura, garantizando el búfer de destino no está desbordado. A continuación se muestra el seguimiento de la pila que encontré durante el problema real: [66.575408s] [pid:5118,cpu4,QThread,4]Pánico en el kernel: no se sincroniza: stack-protector: la pila del kernel está dañada en: do_hardware_base_addr+0xcc/0xd0 [parport ] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comunicación: QThread contaminado: GSWO 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4, QThread,6]TGID: 5087 Comm: EFileApp [66.575439s] [pid:5118,cpu4,QThread,7]Nombre del hardware: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 29/04/2024 [66.575439 s] [pid:5118,cpu4,QThread,8]Rastreo de llamadas: [66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0 [66.575469s] [pid:5118,cpu4,QThread,0 ] show_stack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] pánico+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38 [66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI/DPC: corrige el use-after-free en DPC simultáneos y la eliminación en caliente. Keith informa un use-after-free cuando ocurre un evento de DPC simultáneamente con la eliminación en caliente del mismo. parte de la jerarquía: dpc_handler() espera que el bus secundario esté listo debajo del puerto descendente donde ocurrió el evento DPC. Para hacerlo, sondea el espacio de configuración del primer dispositivo secundario en el bus secundario. Si ese dispositivo secundario se elimina simultáneamente, los accesos a su estructura pci_dev hacen que el kernel falle. Esto se debe a que pci_bridge_wait_for_secondary_bus() no mantiene una referencia en el dispositivo secundario. Antes de v6.3, la función solo se llamaba al reanudar desde la suspensión del sistema o al reanudar el tiempo de ejecución. Mantener una referencia no era necesario en aquel entonces porque el subproceso pciehp IRQ nunca podía ejecutarse al mismo tiempo. (Al reanudar desde la suspensión del sistema, las IRQ no se habilitan hasta después de la fase resume_noirq. Y la reanudación del tiempo de ejecución siempre se espera antes de que se elimine un dispositivo PCI). Sin embargo, a partir de v6.3, pci_bridge_wait_for_secondary_bus() también se llama en un evento DPC. El commit 53b54ad074de ("PCI/DPC: Esperar la preparación del bus secundario después del reinicio"), que introdujo eso, no pudo apreciar que pci_bridge_wait_for_secundary_bus() ahora necesita mantener una referencia en el dispositivo secundario porque dpc_handler() y pciehp pueden ejecutarse simultáneamente. El commit fue respaldada a núcleos estables v5.10+, por lo que ese es el más antiguo afectado. Agregue la adquisición de referencia que falta. Seguimiento de pila abreviado: ERROR: no se puede manejar el error de página para la dirección: 00000000091400c0 CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0 RIP: pci_bus_read_config_dword+0x17/0x50 pci_dev_wait() pci_bridge_wait_for_secondary_bus() dpc_reset_link() _hacer_recuperación () dpc_handler()