Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: f2fs: no configure RO al apagar f2fs El apagado no verifica el error de thaw_super debido a solo lectura, lo que causa un punto muerto como el que se muestra a continuación. f2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) issues_discard_thread - bdev_freeze - frozen_super - f2fs_stop_checkpoint() - f2fs_handle_critical_error - sb_start_write - establecer RO - esperando - bdev_thaw - thaw_super_locked - devolver -EINVAL, si sb_rdonly() - card_thread -> esperar kthread_stop(discard_thread);

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: no crear inodo EA bajo bloqueo de búfer ext4_xattr_set_entry() crea nuevos inodos EA mientras mantiene el bloqueo de búfer en el bloque xattr externo. Esto es problemático ya que anida todo el bloqueo de asignación (que adquiere bloqueos en otros búfer) bajo el bloqueo del búfer. Esto puede incluso bloquearse cuando el sistema de archivos está dañado y, por ejemplo, el archivo de cuota está configurado para contener el bloque xattr como bloque de datos. Mueva la asignación del inodo EA de ext4_xattr_set_entry() a las personas que llaman.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Evitar la saturación de la matriz hw_desc en dw-axi-dmac. Tengo un caso de uso donde nr_buffers = 3 y en el que cada descriptor está compuesto por 3 segmentos, lo que da como resultado que el canal DMA descs_allocated sea 9. Dado que axi_desc_put() maneja hw_desc considerando descs_allocated, este escenario provocaría un pánico en el kernel (la matriz hw_desc se desbordará). Para solucionar este problema, la propuesta es agregar un nuevo miembro a la estructura axi_dma_desc, donde mantenemos el número de hw_descs asignados (axi_desc_alloc()) y lo usamos en axi_desc_put() para manejar la matriz hw_desc correctamente. Además, propongo eliminar la llamada axi_chan_start_first_queued() después de completar la transferencia, ya que se identificó que puede ocurrir un desequilibrio (los descriptores iniciados pueden interrumpirse y la transferencia se ignora debido a que el canal DMA no está habilitado).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: eliminar el indicador SB_INLINECRYPT en default_options En f2fs_remount, el indicador SB_INLINECRYPT se borrará y se restablecerá. Si crea un archivo nuevo o abre un archivo durante este intervalo, estos archivos no utilizarán inlinecrypt. En el peor de los casos, puede provocar daños en los datos si Wrappedkey_v0 está habilitado. Hilo A: Hilo B: -f2fs_remount -f2fs_file_open o f2fs_new_inode -default_options <- borrar el indicador SB_INLINECRYPT -fscrypt_select_encryption_impl -parse_options <- configurar SB_INLINECRYPT nuevamente

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pseries: aplica la validez y el tamaño del búfer de resultados de hcall plpar_hcall(), plpar_hcall9() y las funciones relacionadas esperan que los llamadores proporcionen búferes de resultados válidos de cierto tamaño mínimo. Actualmente esto se comunica sólo a través de comentarios en el código y el compilador no tiene idea. Por ejemplo, si escribo un error como este: long retbuf[PLPAR_HCALL_BUFSIZE]; // debería ser PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); Esto se compila sin emitir diagnósticos, pero probablemente da como resultado daños en la pila en tiempo de ejecución cuando plpar_hcall9() almacena los resultados más allá del final de la matriz. (Para ser claros, este es un ejemplo artificial y todavía no he encontrado una instancia real). Para hacer que esta clase de error sea menos probable, podemos usar parámetros de matriz de tamaño explícito en lugar de punteros en las declaraciones de las API hcall. Cuando se compila con -Warray-bounds[1], el código anterior ahora provoca un diagnóstico como este: error: el argumento de la matriz es demasiado pequeño; es de tamaño 32, el destinatario requiere al menos 72 [-Werror,-Warray-bounds] 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, | ^ ~~~~~~ [1] Habilitado para compilaciones LLVM pero no para GCC por ahora. Consulte El commit 0da6e5fd6c37 ("gcc: deshabilite '-Warray-bounds' para gcc-13 también") y relacionados cambios.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medio: mtk-vcodec: posible deferencia de puntero nulo en SCP Es necesario verificar el valor de retorno de devm_kzalloc() para evitar la deferencia de puntero NULL. Esto es similar a CVE-2022-3113.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/page_table_check: corrige el fallo en ZONE_DEVICE Es posible que no todas las páginas se apliquen a la verificación de pgtable. Un ejemplo son las páginas ZONE_DEVICE: asignan PFN directamente y no asignan page_ext en absoluto, incluso si hay una página de estructura alrededor. Se puede hacer referencia a devm_memremap_pages(). Cuando tanto ZONE_DEVICE como page-table-check están habilitados, intente asignar algunas memorias dax, uno puede desencadenar un error del kernel constantemente ahora cuando el kernel intenta inyectar algunos mapas pfn en el dispositivo dax: ERROR del kernel en mm/page_table_check.c: 55! Si bien es bastante legal usar set_pxx_at() para páginas ZONE_DEVICE para resolución de fallas de página, omita todas las comprobaciones si page_ext ni siquiera existe en pgtable checker, lo que se aplica a ZONE_DEVICE pero tal vez más.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm: enorme_memoria: corrige el mapeo_grande_folio_support() mal utilizado para publicaciones anónimas Cuando hice una prueba de división de publicaciones grandes, apareció una ADVERTENCIA "[ 5059.122759][ T166] No se puede dividir la publicación del archivo en un valor distinto de 0 "orden" se activó. Pero los casos de prueba son sólo para folios anónimos. mientras que mapping_large_folio_support() solo es razonable para las publicaciones de caché de páginas. En split_huge_page_to_list_to_order(), la publicación pasó a mapping_large_folio_support(), tal vez una publicación anónima. Falta la verificación folio_test_anon(). Así que la división del THP anónimo fracasó. Esto también es lo mismo para shmem_mapping(). Será mejor que agreguemos un cheque para ambos. Pero shmem_mapping() en __split_huge_page() no está involucrado, ya que para las publicaciones anónimas, el parámetro final se establece en -1, por lo que (head[i].index >= end) siempre es falso. shmem_mapping() no se llama. También agregue un VM_WARN_ON_ONCE() en mapping_large_folio_support() para un mapeo anónimo, para que podamos detectar el uso incorrecto más fácilmente. Es posible que existan publicaciones de THP en el caché de páginas, incluso si el sistema de archivos no admite publicaciones grandes, esto se debe a que cuando CONFIG_TRANSPARENT_HUGEPAGE está habilitado, khugepaged intentará colapsar las páginas respaldadas por archivos de solo lectura en THP. Pero el mapeo en realidad no admite correctamente folios grandes de varios pedidos. Usando /sys/kernel/debug/split_huge_pages para verificar esto, con este parche, un THP anónimo grande se divide con éxito y la advertencia cesa.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: corrige la desreferencia del puntero NULL en ocfs2_abort_trigger() bdev->bd_super se ha eliminado y el commit 8887b94d9322 cambia el uso de bdev->bd_super a b_assoc_map->host->i_sb. Dado que ocfs2 no ha configurado bh->b_assoc_map, activará la desreferencia del puntero NULL al llamar a ocfs2_abort_trigger(). En realidad, esto se señaló en la historia, consulte el commit 74e364ad1b13. Pero cometí un error al revisar el commit 8887b94d9322 y luego reintroducir esta regresión. Dado que no podemos reactivar bdev en el encabezado del búfer, solucione este problema inicializando todos los tipos de activadores de ocfs2 cuando complete el super, y luego obtenga el activador de ocfs2 específico de ocfs2_caching_info cuando acceda al diario. [joseph.qi@linux.alibaba.com:v2] Enlace: https://lkml.kernel.org/r/20240602112045.1112708-1-joseph.qi@linux.alibaba.com

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: corrigió la desreferencia del puntero NULL en ocfs2_journal_dirty() bdev->bd_super se eliminó y commit 8887b94d9322 cambió el uso de bdev->bd_super a b_assoc_map->host->i_sb. Esto introduce la siguiente desreferencia del puntero NULL en ocfs2_journal_dirty() ya que b_assoc_map aún no está inicializado. Esto se puede reproducir fácilmente ejecutando xfstests generic/186, que no simula más créditos. [134.351592] ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000... [134.355341] RIP: 0010:ocfs2_journal_dirty+0x14f/0x160 [ocfs2]... [134.365071] Seguimiento de llamadas: [134.3653 12] [134.365524] ? __die_body+0x1e/0x60 [ 134.365868] ? page_fault_oops+0x13d/0x4f0 [134.366265]? __pfx_bit_wait_io+0x10/0x10 [134.366659]? horario+0x27/0xb0 [ 134.366981] ? exc_page_fault+0x6a/0x140 [134.367356]? asm_exc_page_fault+0x26/0x30 [134.367762]? ocfs2_journal_dirty+0x14f/0x160 [ocfs2] [ 134.368305] ? ocfs2_journal_dirty+0x13d/0x160 [ocfs2] [ 134.368837] ocfs2_create_new_meta_bhs.isra.51+0x139/0x2e0 [ocfs2] [ 134.369454] ocfs2_grow_tree+0x688/0x8a0 [ocfs2] 134.369927] ocfs2_split_and_insert.isra.67+0x35c/0x4a0 [ocfs2] [ 134.370521] ocfs2_split_extent+0x314/0x4d0 [ocfs2] [ 134.371019] ocfs2_change_extent_flag+0x174/0x410 [ocfs2] [ 134.371566] ocfs2_add_refcount_flag+0x3fa/0x630 ocfs2] [134.372117] ocfs2_reflink_remap_extent+0x21b/0x4c0 [ocfs2] [134.372994]? inode_update_timestamps+0x4a/0x120 [134.373692]? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2] [ 134.374545] ? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2] [ 134.375393] ocfs2_reflink_remap_blocks+0xe4/0x4e0 [ocfs2] [ 134.376197] ocfs2_remap_file_range+0x1de/0x390 [ocfs2] [ 13 4.376971] ? permiso_archivo_seguridad+0x29/0x50 [ 134.377644] vfs_clone_file_range+0xfe/0x320 [ 134.378268] ioctl_file_clone+0x45/0xa0 [ 134.378853] do_vfs_ioctl+0x457/0x990 [ 134.379 422] __x64_sys_ioctl+0x6e/0xd0 [ 134.379987] do_syscall_64+0x5d/0x170 [ 134.380550] entrada_SYSCALL_64_after_hwframe+ 0x76/0x7e [ 134.381231] RIP: 0033:0x7fa4926397cb [ 134.381786] Código: 73 01 c3 48 8b 0d bd 56 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f f84 00 00 00 00 00 90 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8d 56 38 00 f7 d8 64 89 01 48 [ 134.383930] RSP: 002b:00007ffc2b39f7b8 : 00000246 ORIG_RAX: 00000000000000010 [ 134.384854] RAX : ffffffffffffffda RBX: 0000000000000004 RCX: 00007fa4926397cb [ 134.385734] RDX: 00007ffc2b39f7f0 RSI: 000000004020940d RDI: 0000000000000003 [ 134.386606] RBP: 0000000000000000 R08: 00111a82a4f015bb R09: 00007fa494221000 [ 134.387476] R10: 0000000000000000 R11: 0000000000000 246 R12: 0000000000000000 [ 134.388342] R13: 0000000000f10000 R14: 0000558e844e2ac8 R15: 0000000000f10000 [ 134.389207] Solucionelo abortando solo la transacción y el diario en ocfs2_journal_dirty() ahora, y deje ocfs2_abort() más tarde cuando detecte un identificador abortado, por ejemplo, iniciar la siguiente transacción. En este caso, registre también los detalles del identificador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: arreglar slab-out-of-bounds en ext4_mb_find_good_group_avg_frag_lists() Podemos activar un slab-out-of-bounds con los siguientes comandos: mkfs.ext4 -F /dev/ $disk 10G montaje /dev/$disk /tmp/test echo 2147483647 > /sys/fs/ext4/$disk/mb_group_prealloc echo test > /tmp/test/file && sync ============ ==================================================== ==== ERROR: KASAN: losa fuera de los límites en ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] Lectura de tamaño 8 en la dirección ffff888121b9d0f0 por tarea kworker/u2:0/11 CPU: 0 PID: 11 Comm: kworker/ u2:0 Tainted: GL 6.7.0-next-20240118 #521 Seguimiento de llamadas: dump_stack_lvl+0x2c/0x50 kasan_report+0xb6/0xf0 ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4_mb_regular_allocator+0x19e9 /0x2370 [ext4] text4_mb_new_blocks+0x88a/0x1370 [ text4] text4_ext_map_blocks+0x14f7/0x2390 [ext4] text4_map_blocks+0x569/0xea0 [ext4] text4_do_writepages+0x10f6/0x1bc0 [ext4] [...] ==================== ================================================ El flujo de La activación del problema es la siguiente: // Establezca s_mb_group_prealloc en 2147483647 a través de sysfs ext4_mb_new_blocks ext4_mb_normalize_request ext4_mb_normalize_group_request ac->ac_g_ex.fe_len = EXT4_SB(sb)->s_mb_group_prealloc ext4_mb_regular_allocator ext4_mb_choose _next_group ext4_mb_choose_next_group_best_avail mb_avg_fragment_size_order orden = fls(len) - 2 = 29 ext4_mb_find_good_group_avg_frag_lists frag_list = &sbi- >s_mb_avg_fragment_size[order] if (list_empty(frag_list)) // ¡Activa SOOB! En un tamaño de bloque de 4k, la longitud de la lista s_mb_avg_fragment_size es 14, pero se establece un s_mb_group_prealloc de gran tamaño, lo que provoca que los límites de losa se activen al intentar acceder a un elemento en el índice 29. Agregue un nuevo attr_id attr_clusters_in_group con valores en el rango [0, sbi->s_clusters_per_group] y declare mb_group_prealloc como ese tipo para solucionar el problema. Además, evite devolver un pedido de mb_avg_fragment_size_order() mayor que MB_NUM_ORDERS(sb) y reduzca algunos bucles inútiles.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm6: verifique el valor de retorno de ip6_dst_idev() en xfrm6_get_saddr() ip6_dst_idev() puede devolver NULL, xfrm6_get_saddr() debe actuar en consecuencia. syzbot informó: Ups: falla de protección general, probablemente para la dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 12 Comm: trabajador/ u8:1 No contaminado 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/04/2024 Cola de trabajo: wg-kex-wg1 wg_packet_handshake_send_worker RIP: 0010:xfrm6_get_saddr +0x93/0x130 net/ipv6/xfrm6_policy.c:64 Código: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff f 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00 RSP: 0018:ffffc90000117378 EFLAGS: 00010246 RAX dff ffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7 RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98 RBP: ffff88807ad73248 R08: 0000000000000007 R09: ffffffffffff000 R10: ffff88807b079dc0 11: 0000000000000007 R12: ffffc90000117480 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0 000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS : 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: xfrm_get_saddr net/xfrm/xfrm_policy .c:2452 [en línea] xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [en línea] xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541 xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_ política.c:2835 xfrm_bundle_lookup net /xfrm/xfrm_policy.c:3070 [en línea] xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201 xfrm_lookup net/xfrm/xfrm_policy.c:3298 [en línea] xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm _política.c :3309 ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256 send6+0x611/0xd20 controladores/net/wireguard/socket.c:139 wg_socket_send_skb_to_peer+0xf9/0x220 controladores/net/wireguard/socket.c:178 enviar_buffer_to_peer+ 0x12b/0x190 controladores/net/wireguard/socket.c:200 wg_packet_send_handshake_initiation+0x227/0x360 controladores/net/wireguard/send.c:40 wg_packet_handshake_send_worker+0x1c/0x30 controladores/net/wireguard/send.c:51 Process_one_work+0x9fb/ 0x1b60 kernel/workqueue.c:3231 Process_scheduled_works kernel/workqueue.c:3312 [en línea] trabajador_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/ x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244