Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: landlock: no pierda de vista las restricciones en cred_transfer Cuando se reemplaza la estructura cred de un proceso, esto _almost_ always invoca el gancho LSM cred_prepare; pero en un caso especial (cuando KEYCTL_SESSION_TO_PARENT actualiza las credenciales de los padres), se utiliza el gancho LSM cred_transfer. Landlock solo implementa el gancho cred_prepare, no cred_transfer, por lo que KEYCTL_SESSION_TO_PARENT hace que se pierda toda la información sobre las restricciones de Landlock. Básicamente, esto significa que un proceso con la capacidad de utilizar las llamadas al sistema fork() y keyctl() puede deshacerse de todas las restricciones de Landlock sobre sí mismo. Solucionelo agregando un gancho cred_transfer que haga lo mismo que el gancho cred_prepare existente. (Se implementa haciendo que hook_cred_prepare() llame a hook_cred_transfer() para que sea menos probable que las dos funciones diverjan accidentalmente en el futuro).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/dasd: corrige comprobaciones de errores en dasd_copy_pair_store() dasd_add_busid() puede devolver un error a través de ERR_PTR() si falla una asignación. Sin embargo, dos sitios de llamada en dasd_copy_pair_store() no verifican el resultado, lo que podría provocar una desreferencia del puntero NULL. Solucione este problema verificando el resultado con IS_ERR() y devolviendo el error en la pila.

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.