Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: MIPS: Octeon: agregar verificación de estado del enlace PCIe La interfaz de lectura y escritura de configuración PCIe estándar se utiliza para acceder al espacio de configuración de los dispositivos PCIe periféricos del procesador mips después de la sorpresa del enlace PCIe. inactivo, puede generar pánico en el kernel causado por un "Error del bus de datos". Por lo tanto, es necesario agregar una verificación del estado del enlace PCIe para proteger el sistema. Cuando el enlace PCIe está inactivo o en entrenamiento, asignar un valor de 0 a la dirección de configuración puede evitar el comportamiento de lectura y escritura en el espacio de configuración de los dispositivos PCIe periféricos, evitando así el pánico del kernel.

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: 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: 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: mm: shmem: corrige la obtención de lruvec incorrecto al reemplazar un folio de shmem Al probar shmem swapin, encontré la siguiente advertencia en mi máquina. La razón es que reemplazar una publicación shmem antigua por una nueva hace que mem_cgroup_migrate() borre los datos memcg de la publicación anterior. Como resultado, el folio antiguo no puede obtener el lruvec de memcg correcto necesario para eliminarse de la lista LRU cuando se libera. Esto podría provocar posibles problemas graves, como bloqueos de la lista de LRU debido a que se mantiene el bloqueo de LRU incorrecto y estadísticas de LRU incorrectas. Para solucionar este problema, podemos utilizar mem_cgroup_replace_folio() para reemplazar el antiguo folio shmem. [ 5241.100311] página: refcount:0 mapcount:0 mapeo:00000000000000000 index:0x0 pfn:0x5d9960 [ 5241.100317] head: orden:4 mapcount:0 complete_mapcount:0 nr_pages_mapped:0 pincount:0 [ 5241.100319] banderas: 17fffe0000040068(actualización|lru |head|swapbacked|node=0|zone=2|lastcpupid=0x3ffff) [ 5241.100323] raw: 17fffe0000040068 ffffdffd6687948 fffffdffd69ae008 0000000000000000 [ 5241.100325] raw: 0000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 5241.100326] cabeza: 17fffe0000040068 ffffdffd6687948 ffffdffd69ae008 000000000 [ 5241.100327] cabeza: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 5241.100328] cabeza: 17fffe0000000204 fffffdffd6665801 ffffffffffffffff 0000000000000000 [ 5241 .100329] encabezado: 0000000a00000010 0000000000000000 00000000ffffffff 0000000000000000 [5241.100330] página volcada porque: VM_WARN_ON_ONCE_FOLIO(!memcg &&!mem_cgroup_disable d()) [ 5241.100338] --------- ---[ cortar aquí ]------------ [ 5241.100339] ADVERTENCIA: CPU: 19 PID: 78402 en include/linux/memcontrol.h:775 folio_lruvec_lock_irqsave+0x140/0x150 [...] [ 5241.100374] pc : folio_lruvec_lock_irqsave+0x140/0x150 [ 5241.100375] lr : folio_lruvec_lock_irqsave+0x138/0x150 [ 5241.100376] sp : ffff80008b38b930 [...] [ 5241 .100398] Seguimiento de llamadas: [5241.100399] folio_lruvec_lock_irqsave+0x140/0x150 [5241.100401] __page_cache_release+ 0x90/0x300 [ 5241.100404] __folio_put+0x50/0x108 [ 5241.100406] shmem_replace_folio+0x1b4/0x240 [ 5241.100409] shmem_swapin_folio+0x314/0x528 [ 5241.1004 11] shmem_get_folio_gfp+0x3b4/0x930 [ 5241.100412] shmem_fault+0x74/0x160 [ 5241.100414] __do_fault+0x40/ 0x218 [ 5241.100417] do_shared_fault+0x34/0x1b0 [ 5241.100419] do_fault+0x40/0x168 [ 5241.100420] handle_pte_fault+0x80/0x228 [ 5241.100422] 0x1c4/0x440 [ 5241.100424] handle_mm_fault+0x60/0x1f0 [ 5241.100426] do_page_fault+0x120/0x488 [ 5241.100429] do_translation_fault+0x4c/0x68 [ 5241.100431] do_mem_abort+0x48/0xa0 [ 5241.100434] el0_da+0x38/0xc0 [ 5241.100436] [ 5241.100437] el0t_64_sync+0x14c/0x150 [ 5241.100439] ---[ final de seguimiento 00000000000000000 ] --- [baolin.wang@linux.alibaba.com: elimine los comentarios menos útiles, según Matthew] Enlace: https://lkml.kernel.org/r/ccad3fe1375b468ebca3227b6b729f3eaf9d8046.1718423197.git.baolin.wang@linux.alibaba. com

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: ima: Evite el bloqueo en la sección crítica del lado de lectura de RCU Ocurre un pánico en ima_match_policy: ERROR: no se puede manejar la desreferencia del puntero NULL del kernel en 00000000000000010 PGD 42f873067 P4D 0 Ups: 0000 [#1 ] SMP NOPTI CPU: 5 PID: 1286325 Comm: kubeletmonit.sh Kdump: cargado Contaminado: P Nombre del hardware: QEMU PC estándar (i440FX + PIIX, 1996), BIOS 0.0.0 06/02/2015 RIP: 0010:ima_match_policy+0x84 /0x450 Código: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39 7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d f2 b9 f4 00 0f 84 9c 01 00 <44> 85 73 10 74 ea 44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f RSP: 0018:ff71570009e07a80 EFLAGS: 00010207 RAX: 0000000000000000 RBX: 0000000000 RCX: 0000000000000200 RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000 RBP: 0000000000000000 R08 : 0000000000000000 R09: ffffffffabfce739 R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970 R13: 00000000ff3e2785 R14: 000000000c R15: 0000000000000001 FS: 00007f5195b51740(0000) GS:ff3e278b12d40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: : 0000000080050033 CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ima_get_action+0x22/0x30 Process_measurement+0xb0/0x830 ? page_add_file_rmap+0x15/0x170? alloc_set_pte+0x269/0x4c0? prep_new_page+0x81/0x140? simple_xattr_get+0x75/0xa0? selinux_file_open+0x9d/0xf0 ima_file_check+0x64/0x90 path_openat+0x571/0x1720 do_filp_open+0x9b/0x110 ? page_counter_try_charge+0x57/0xc0? files_cgroup_alloc_fd+0x38/0x60? __alloc_fd+0xd4/0x250? do_sys_open+0x1bd/0x250 do_sys_open+0x1bd/0x250 do_syscall_64+0x5d/0x1d0 Entry_SYSCALL_64_after_hwframe+0x65/0xca Commit c7423dbdbc9e ("ima: Handle -ESTALE devuelto por ima_filter_rule_match()") introdujo la llamada a ima_lsm _copy_rule dentro de una sección crítica del lado de lectura de RCU que contiene kmalloc con GFP_KERNEL. Esto implica una posible suspensión y viola las limitaciones de las secciones críticas del lado de lectura de RCU en sistemas que no son PREEMPT. Dormir dentro de la sección crítica del lado de lectura de la RCU puede provocar que sincronizar_rcu() regrese antes de tiempo y rompa la protección de la RCU, lo que permite que se produzca una UAF. La causa raíz de este problema podría describirse de la siguiente manera: | Hilo A | Hilo B | | |ima_match_policy | | | rcu_read_lock | |ima_lsm_update_rule | | | sincronizar_rcu | | | | kmalloc(GFP_KERNEL)| | | dormir | ==> sincronizar_rcu regresa temprano | kfree(entrada) | | | | entrada = entrada->siguiente| ==> Sucede UAF y la entrada ahora se vuelve NULL (o podría ser cualquier cosa). | | entrada->acción | ==> Acceder a la entrada puede causar pánico. Para solucionar este problema, estamos convirtiendo todos los kmalloc que se llaman dentro de la sección crítica del lado de lectura de RCU para usar GFP_ATOMIC. [PM: comentario faltante corregido, líneas largas, caso !CONFIG_IMA_LSM_RULES]

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.