Vulnerabilidades

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 ha resuelto la siguiente vulnerabilidad: btrfs: zonificado: asigna sumas de verificación ficticias para zonas zonificadas NODATASUM escribe Shin'ichiro informó que cuando ejecuta el caso de prueba btrfs/167 de fstests en dispositivos zonificados emulados, ve el siguiente puntero NULL desreferencia en 'btrfs_zone_finish_endio()': Vaya: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000011: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x0000000000000088-0x00000000000000 8f] CPU: 4 PID: 2332440 Comm: kworker/u80:15 Contaminado: GW 6.10.0-rc2-kts+ #4 Nombre de hardware: Supermicro Super Server/X11SPi-TF, BIOS 3.3 21/02/2020 Cola de trabajo: btrfs-endio-write btrfs_work_helper [btrfs] RIP : 0010:btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs] RSP: 0018:ffff88867f107a90 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 893e5534 RDX: 0000000000000011 RSI: 0000000000000004 RDI: 0000000000000088 RBP: 0000000000000002 R08: 0000000000000001 R09: 6028 R10: ffff88840b4b0143 R11: ffff88834dfff600 R12: ffff88840b4b0000 R13: 0000000000020000 R14: 00000000000000000 R15: ffff888530ad5210 FS: 0000000000000(0000) GS:ffff888e3f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f87223fff38 CR3 : 00000007a7c6a002 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000000 DR3: 0000000000000000 DR6: 000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: ? __die_body.cold+0x19/0x27 ? die_addr+0x46/0x70? exc_general_protection+0x14f/0x250? asm_exc_general_protection+0x26/0x30? do_raw_read_unlock+0x44/0x70? btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs] btrfs_finish_one_ordered+0x5d9/0x19a0 [btrfs] ? __pfx_lock_release+0x10/0x10? do_raw_write_lock+0x90/0x260? __pfx_do_raw_write_lock+0x10/0x10? __pfx_btrfs_finish_one_ordered+0x10/0x10 [btrfs]? _raw_write_unlock+0x23/0x40? btrfs_finish_ordered_zoned+0x5a9/0x850 [btrfs]? lock_acquire+0x435/0x500 btrfs_work_helper+0x1b1/0xa70 [btrfs]? __programar+0x10a8/0x60b0? __pfx___might_resched+0x10/0x10 proceso_one_work+0x862/0x1410 ? __pfx_lock_acquire+0x10/0x10? __pfx_process_one_work+0x10/0x10? asignar_trabajo+0x16c/0x240 trabajador_hilo+0x5e6/0x1010? __pfx_worker_thread+0x10/0x10 kthread+0x2c3/0x3a0 ? trace_irq_enable.constprop.0+0xce/0x110? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Al habilitar CONFIG_BTRFS_ASSERT se reveló la siguiente aserción para activar: aserción fallida: !list_empty(&ordered->list), en fs/btrfs/zoned.c:1815 Esto indica que Falta la lista de sumas de verificación en la extensión_ordenada. Como btrfs/167 está escribiendo NOCOW, esto es de esperarse. Un análisis más detallado con drgn confirmó la suposición: >>> inode = prog.crashed_thread().stack_trace()[11]['ordered'].inode >>> btrfs_inode = drgn.container_of(inode, "struct btrfs_inode", \ " vfs_inode") >>> print(btrfs_inode.flags) (u32)1 Como el modo de emulación de zonas simula zonas convencionales en dispositivos normales, no podemos usar Zone-Append para escribir. Pero solo adjuntamos sumas de verificación ficticias si realizamos una escritura de adición de zona. Entonces, para las escrituras de datos de zonas NOCOW en zonas convencionales, adjunte también una suma de verificación ficticia.

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 resolvió la siguiente vulnerabilidad: i2c: lpi2c: evite llamar a clk_get_rate durante la transferencia. En lugar de llamar repetidamente a clk_get_rate para cada transferencia, bloquee la velocidad del reloj y almacene en caché el valor. Se ha observado un punto muerto al agregar el códec de audio tlv320aic32x4 al sistema. Cuando este proveedor de reloj agrega su reloj, el mutex clk ya está bloqueado, necesita acceder a i2c, que a cambio también necesita el mutex para clk_get_rate.

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 resolvió la siguiente vulnerabilidad: KVM: solucione una ejecución de datos en last_boosted_vcpu en kvm_vcpu_on_spin() Utilice {READ,WRITE}_ONCE() para acceder a kvm->last_boosted_vcpu para garantizar que las cargas y los almacenes sean atómicos. En el escenario extremadamente improbable de que el compilador rompa los almacenes, es teóricamente posible que KVM intente obtener una vCPU utilizando un índice fuera de los límites, por ejemplo, si la escritura se divide en varios almacenes de 8 bits y se combina con un 32 -carga de bits en una VM con 257 vCPU: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff]; Según lo detectado por KCSAN: ERROR: KCSAN: ejecución de datos en kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] escribe en 0xffffc90025a92344 de 4 bytes por tarea 4340 en la CPU 16: kvm_vcpu_on_spin (arch/x86/kvm/../../. ./virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm /vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c :890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64 .S:130) leído en 0xffffc90025a92344 de 4 bytes por la tarea 4342 en la CPU 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/ x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86 .c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) Entry_SYSCALL_64_after_hwframe (arch/ x86/entry/entry_64.S:130) valor cambiado: 0x00000012 -> 0x00000000

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 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: net: no deja un puntero sk colgando cuando falla la creación del socket. Es posible activar un use-after-free: * adjuntando una sonda fentry a __sock_release() y el sonda que llama al asistente bpf_get_socket_cookie() * ejecuta traceroute -I 1.1.1.1 en una máquina virtual recién iniciada. Un kernel habilitado para KASAN registrará algo como lo siguiente (decodificado y eliminado): =============== ==================================================== = ERROR: KASAN: slab-use-after-free en __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include /linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) Lectura de tamaño 8 en la dirección ffff888007110dd8 mediante tarea traceroute/299 CPU: 2 PID: 299 Comm: traceroute Contaminado: GE 6.10.0- rc2+ #2 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 01/04/2014 Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:117 ( discriminador 1)) print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 neto /core/sock_diag.c:29) kasan_report (mm/kasan/report.c:603)? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 neto /core/sock_diag.c:29) kasan_check_range (mm/kasan/generic.c:183 mm/kasan/generic.c:189) __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include /linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) bpf_get_socket_ptr_cookie (./arch/x86/include/asm /preempt.h:94 ./include/linux/sock_diag.h:42 net/core/filter.c:5094 net/core/filter.c:5092) bpf_prog_875642cf11f1d139___sock_release+0x6e/0x8e bpf_trampoline_6442506592+0x47/0xaf __ calcetín_release (net/ socket.c:652) __sock_create (net/socket.c:1601) ... Asignado por la tarea 299 en la CPU 2 en 78.328492s: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common. c:68) __kasan_slab_alloc (mm/kasan/common.c:312 mm/kasan/common.c:338) kmem_cache_alloc_noprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007) sk_prot_alloc (net/core/sock.c:2075) sk_alloc (net/core/sock.c:2134) inet_create (net/ipv4/af_inet.c:327 net/ipv4/af_inet.c:252) __sock_create (net/socket. c:1572) __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) __x64_sys_socket (net/socket.c:1718) do_syscall_64 (arch/x86/entry/common.c: 52 arch/x86/entry/common.c:83) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Liberado por la tarea 299 en la CPU 2 a las 78.328502s: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:68) kasan_save_free_info (mm/kasan/generic.c:582) veneno_slab_object (mm/kasan/common.c:242) __kasan_slab_free (mm/kasan/common.c:256) kmem_cache_free ( mm/slub.c:4437 mm/slub.c:4511) __sk_destruct (net/core/sock.c:2117 net/core/sock.c:2208) inet_create (net/ipv4/af_inet.c:397 net/ipv4 /af_inet.c:252) __sock_create (net/socket.c:1572) __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) __x64_sys_socket (net/socket.c:1718 ) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Solucione este problema borrando la referencia del socket de estructura en sk_common_release () para cubrir todas las familias de protocolos, cree funciones, que pueden ya adjuntar la referencia al objeto sk con sock_init_data().