Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mips: bmips: BCM6358: asegúrese de que CBR esté configurado correctamente. Se descubrió que algunos dispositivos tienen la dirección CBR configurada en 0, lo que provoca pánico en el kernel cuando se llama a arch_sync_dma_for_cpu_all. Esto se notó en una situación en la que el sistema se inicia desde TP1 y BMIPS_GET_CBR() devuelve 0 en lugar de una dirección válida y !!(read_c0_brcm_cmt_local() & (1 << 31)); no fallar. La verificación actual de si la descarga de RAC debe desactivarse o no no es suficiente, por lo tanto, verifiquemos si CBR es una dirección válida o no.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: agregue la opción para que un tty rechace un nuevo ldisc... y utilícelo para limitar las terminales virtuales a solo N_TTY. Son algo especiales y, en particular, la rutina "con_write()" viola la regla "las escrituras no pueden dormir" en la que se basan algunos ldiscs. Esto evita el ERROR: función de suspensión llamada desde un contexto no válido en kernel/printk/printk.c:2659 cuando N_GSM se ha conectado a una consola virtual, y gsmld_write() llama a con_write() mientras mantiene un spinlock, y con_write() luego intenta para obtener el bloqueo de la consola.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: imx: Introduce tiempo de espera cuando se espera que el transmisor esté vacío. Esperando como máximo 1 segundo para que se establezca USR2_TXDC, evitamos un posible punto muerto. En caso de que se agote el tiempo de espera, no hay mucho que podamos hacer, por lo que simplemente ignoramos el estado del transmisor e intentamos continuar con optimismo.

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.