Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: qcom: sc7280: Fix missing Soundwire runtime stream alloc Commit 15c7fab0e047 ("ASoC: qcom: Move Soundwire runtime stream alloc to soundcards") movió la asignación de tiempo de ejecución de flujo Soundwire del controlador Qualcomm Soundwire al controlador de tarjeta de sonido de cada máquina individual, excepto que olvidó actualizar la tarjeta SC7280. Al igual que para otras tarjetas de sonido Qualcomm que usan Soundwire, el controlador de la tarjeta debe asignar y liberar el tiempo de ejecución. De lo contrario, la reproducción de sonido dará como resultado una desreferencia de puntero NULL u otro efecto de accesos a memoria no inicializados (lo que se confirmó en SDM845 que tenía un problema similar).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: arregla la ejecución entre laundromat y free_stateid. Hay una ejecución entre el manejo de laundromat de delegaciones revocadas y un cliente que envía la operación free_stateid. El hilo de laundromat encuentra que la delegación ha expirado y necesita ser revocada, por lo que marca el stid de delegación revocado y lo pone en una lista de reaper, pero luego desbloquea el bloqueo de estado y la revocación de delegación real ocurre sin el bloqueo. Una vez que el stid está marcado como revocado, un hilo de procesamiento de free_stateid en ejecución hace lo siguiente: (1) llama a list_del_init() que lo elimina de la lista de reaper y (2) libera la estructura del stid de delegación. El hilo de laundromat termina sin llamar a la función revoke_delegation() para esta delegación en particular, pero eso significa que no liberará la concesión de bloqueo que existe en el archivo. Ahora, una nueva apertura para este archivo llega y termina encontrando que la lista de arrendamientos no está vacía y llama a nfsd_breaker_owns_lease() que termina intentando desreferenciar un stateid de delegación liberado. Lo que genera la siguiente advertencia de KASAN de use-after-free: kernel: == ... 2069.0.0.0.0 08/03/2024 núcleo: Seguimiento de llamadas: núcleo: dump_backtrace+0x98/0x120 núcleo: show_stack+0x1c/0x30 núcleo: dump_stack_lvl+0x80/0xe8 núcleo: print_address_description.constprop.0+0x84/0x390 núcleo: print_report+0xa4/0x268 núcleo: kasan_report+0xb4/0xf8 núcleo: __asan_report_load8_noabort+0x1c/0x28 núcleo: nfsd_breaker_owns_lease+0x140/0x160 [nfsd] núcleo: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd] núcleo: nfsd_file_acquire_opened+0x84/0x110 [nfsd] núcleo: nfs4_get_vfs_file+0x634/0x958 [nfsd] núcleo: nfsd4_process_open2+0xa40/0x1a40 [nfsd] núcleo: nfsd4_open+0xa08/0xe80 [nfsd] núcleo: nfsd4_proc_compound+0xb8c/0x2130 [nfsd] núcleo: nfsd_dispatch+0x22c/0x718 [nfsd] núcleo: svc_process_common+0x8e8/0x1960 [sunrpc] núcleo: svc_process+0x3d4/0x7e0 [sunrpc] núcleo: svc_handle_xprt+0x828/0xe10 [sunrpc] kernel: svc_recv+0x2cc/0x6a8 [sunrpc] kernel: nfsd+0x270/0x400 [nfsd] kernel: kthread+0x288/0x310 kernel: ret_from_fork+0x10/0x20 Este parche propone una solución basada en agregar 2 nuevos valores de stid adicionales sc_status que ayudan a coordinar entre la lavandería y otras operaciones (nfsd4_free_stateid() y nfsd4_delegreturn()). Primero, para asegurarse de que una vez que el stid esté marcado como revocado, no sea eliminado por nfsd4_free_stateid(), la lavandería tome una referencia en el stateid. Luego, al coordinar si el stid se ha colocado en la lista cl_revoked o si estamos procesando FREE_STATEID y debemos asegurarnos de eliminarlo de la lista, cada uno verifica ese estado y actúa en consecuencia. Si laundromat ha agregado a la lista cl_revoke antes de la llegada de FREE_STATEID, entonces nfsd4_free_stateid() sabe eliminarlo de la lista. Si nfsd4_free_stateid() encuentra que las operaciones llegaron antes de que laundromat lo haya colocado en la lista cl_revoke, marca el estado como liberado y luego laundromat ya no lo agregará a la lista. Además, para nfsd4_delegreturn() cuando buscamos el stid especificado, necesitamos acceder a los stid que están marcados como eliminados o liberables, significa que laundromat ha comenzado a procesarlo pero no ha terminado y este delegreturn debe devolver nfserr_deleg_revoked y no nfserr_bad_stateid. Este último no activará un FREE_STATEID y la falta del mismo dejará este stid en la lista cl_revoked indefinidamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: platform/x86/intel/pmc: Corregir pmc_core_iounmap para llamar a iounmap para direcciones válidas. La confirmación 50c6dbdfd16e ("x86/ioremap: Mejorar las comprobaciones del rango de direcciones de iounmap()") introduce una ADVERTENCIA cuando los rangos de direcciones de iounmap no son válidos. En Thinkpad P1 Gen 7 (Meteor Lake-P), esto provocó que apareciera la siguiente advertencia: ADVERTENCIA: CPU: 7 PID: 713 en arch/x86/mm/ioremap.c:461 iounmap+0x58/0x1f0 Módulos vinculados en: rfkill(+) snd_timer(+) fjes(+) snd soundcore intel_pmc_core(+) int3403_thermal(+) int340x_thermal_zone intel_vsec pmt_telemetry acpi_pad pmt_class acpi_tad int3400_thermal acpi_thermal_rel joydev loop nfnetlink zram xe drm_suballoc_helper nouveau i915 mxm_wmi drm_ttm_helper gpu_sched drm_gpuvm drm_exec drm_buddy i2c_algo_bit crct10dif_pclmul crc32_pclmul ttm crc32c_intel polyval_clmulni rtsx_pci_sdmmc ucsi_acpi polyval_generic mmc_core hid_multitouch drm_display_helper ghash_clmulni_intel typec_ucsi nvme sha512_ssse3 video sha256_ssse3 nvme_core intel_vpu sha1_ssse3 rtsx_pci cec typec nvme_auth i2c_hid_acpi i2c_hid wmi pinctrl_meteorlake serio_raw ip6_tables ip_tables fuse CPU: 7 UID: 0 PID: 713 Comm: (udev-worker) No contaminado 6.12.0-rc2iounmap+ #42 Nombre del hardware: LENOVO 21KWCTO1WW/21KWCTO1WW, BIOS N48ET19W (1.06) 18/07/2024 RIP: 0010:iounmap+0x58/0x1f0 Código: 85 6a 01 00 00 48 8b 05 e6 e2 28 04 48 39 c5 72 19 eb 26 cc cc cc 48 ba 00 00 00 00 00 00 32 00 48 8d 44 02 ff 48 39 c5 72 23 <0f> 0b 48 83 c4 08 5b 5d 41 5c c3 cc cc cc cc 48 ba 00 00 00 00 00 RSP: 0018:ffff888131eff038 EFLAGS: 00010207 RAX: ffffc90000000000 RBX: 0000000000000000 RCX: ffff888e33b80000 RDX: dffffc0000000000 RSI: ffff888e33bc29c0 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8881598a8000 R09: ffff888e2ccedc10 R10: 0000000000000003 R11: ffffffffb3367634 R12: 00000000fe000000 R13: ffff888101d0da28 R14: ffffffffc2e437e0 R15: ffff888110b03b28 FS: 00007f3c1d4b3980(0000) GS:ffff888e33b80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005651cfc93578 CR3: 0000000124e4c002 CR4: 0000000000f70ef0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: ? __warn.cold+0xb6/0x176 ? iounmap+0x58/0x1f0 ? report_bug+0x1f4/0x2b0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x17/0x40 ? pci_enable_device_flags+0x1e3/0x2e0 ? __pfx_mtl_core_init+0x10/0x10 [intel_pmc_core] pmc_core_ssram_init+0x7f/0x110 [intel_pmc_core] mtl_core_init+0xda/0x130 [intel_pmc_core] ? __mutex_init+0xb9/0x130 pmc_core_probe+0x27e/0x10b0 [intel_pmc_core] ? _raw_spin_lock_irqsave+0x96/0xf0 ? __pfx_pmc_core_probe+0x10/0x10 [intel_pmc_core] ? __pfx_mutex_unlock+0x10/0x10 ? __pfx_mutex_lock+0x10/0x10 ? device_pm_check_callbacks+0x82/0x370 ? acpi_dev_pm_attach+0x234/0x2b0 platform_probe+0x9f/0x150 really_probe+0x1e0/0x8a0 __driver_probe_device+0x18c/0x370 ? __pfx___driver_attach+0x10/0x10 driver_probe_device+0x4a/0x120 __driver_attach+0x190/0x4a0 ? __pfx___driver_attach+0x10/0x10 bus_for_each_dev+0x103/0x180 ? __pfx_bus_for_each_dev+0x10/0x10 ? klist_add_tail+0x136/0x270 bus_add_driver+0x2fc/0x540 driver_register+0x1a5/0x360 ? __pfx_pmc_core_driver_init+0x10/0x10 [intel_pmc_core] do_one_initcall+0xa4/0x380 ? __pfx_do_one_initcall+0x10/0x10 ? kasan_unpoison+0x44/0x70 do_init_module+0x296/0x800 load_module+0x5090/0x6ce0 ? __pfx_load_module+0x10/0x10 ? ima_post_read_file+0x193/0x200 ? __pfx_ima_post_read_file+0x10/0x10 ? rw_verify_area+0x152/0x4c0 ? kernel_read_file+0x257/0x750 ? __pfx_kernel_read_file+0x10/0x10 ? __pfx_filemap_get_read_batch+0x10/0x10 ? init_module_from_file+0xd1/0x130 init_module_from_file+0xd1/0x130 ? __pfx_init_module_from_file+0x10/0 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md/raid10: se corrige la desreferencia ptr nulo en raid10_size() En raid10_run(), si raid10_set_queue_limits() tiene éxito, el valor de retorno se establece en cero y, si fallan los siguientes procedimientos, raid10_run() devolverá cero mientras que mddev->private sigue siendo NULL, lo que provoca una desreferencia ptr nula en raid10_size(). Solucione el problema sobrescribiendo solo el valor de retorno si raid10_set_queue_limits() falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Habilitar IRQ si do_ale() se activa en un contexto habilitado para irq. La excepción de acceso no alineado se puede activar en un contexto habilitado para irq, como el modo de usuario; en este caso, do_ale() puede llamar a get_user(), lo que puede provocar una suspensión. Entonces obtendremos: ERROR: función inactiva llamada desde un contexto no válido en arch/loongarch/kernel/access-helper.h:7 in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 129, nombre: modprobe preempt_count: 0, esperado: 0 Profundidad de anidación de RCU: 0, esperado: 0 CPU: 0 UID: 0 PID: 129 Comm: modprobe Contaminado: GW 6.12.0-rc1+ #1723 Contaminado: [W]=WARN Pila: 9000000105e0bd48 0000000000000000 9000000003803944 9000000105e08000 9000000105e0bc70 9000000105e0bc78 000000000000000 0000000000000000 9000000105e0bc78 0000000000000001 9000000185e0ba07 9000000105e0b890 ffffffffffffffff 9000000105e0bc78 73924b81763be05b 9000000100194500 000000000000020c 00000000000000a 0000000000000000 000000000000003 000000000000023f0 000000000000e1401 00000000072f8000 0000007ffbb0e260 0000000000000000 000000000000000 9000000005437650 90000000055d5000 0000000000000000 0000000000000003 0000007ffbb0e1f0 000000000000000 000005567b00490 0000000000000000 9000000003803964 0000007ffbb0dfec 000000000000000b0 0000000000000007 0000000000000003 0000000000071c1d ... Seguimiento de llamadas: [<9000000003803964>] show_stack+0x64/0x1a0 [<9000000004c57464>] dump_stack_lvl+0x74/0xb0 [<9000000003861ab4>] __might_resched+0x154/0x1a0 [<900000000380c96c>] emulate_load_store_insn+0x6c/0xf60 [<9000000004c58118>] do_ale+0x78/0x180 [<9000000003801bc8>] handle_ale+0x128/0x1e0 Entonces habilite IRQ si se activa una excepción de acceso no alineado en un contexto habilitado para irq para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/lam: Deshabilitar ADDRESS_MASKING en la mayoría de los casos. El enmascaramiento de direcciones lineales (LAM) tiene una debilidad relacionada con la ejecución transitoria como se describe en el documento SLAM[1]. A menos que se habilite la separación del espacio de direcciones lineales (LASS), esta debilidad puede ser explotable. Hasta que el kernel agregue soporte para LASS[2], solo permita LAM para COMPILE_TEST, o cuando las mitigaciones de especulación se hayan deshabilitado en el momento de la compilación, de lo contrario, mantenga LAM deshabilitado. No hay procesadores en el mercado que admitan LAM todavía, por lo que actualmente nadie se ve afectado por este problema. [1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf [2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/ [ dhansen: actualización MITIGACIONES_DE_ESPECULACIÓN -> MITIGACIONES_DE_CPU ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firewire: core: fix invalid port index for parent device En una confirmación 24b7f8e5cd65 ("firewire: core: use helper functions for self ID sequence"), la enumeración sobre la secuencia de auto-identificación se refactorizó con algunas funciones auxiliares con pruebas KUnit. Se garantiza que estas funciones auxiliares funcionarán como se espera mediante las pruebas KUnit, sin embargo, su aplicación incluye un error para asignar un valor no válido al índice del puerto conectado al dispositivo principal. Este error afecta al caso en que cualquier dispositivo de nodo adicional que tenga tres o más puertos esté conectado al controlador 1394 OHCI. En el caso, la ruta para actualizar la caché del árbol podría alcanzar WARN_ON() y obtener un fallo de protección general debido al acceso a una dirección no válida calculada por el valor no válido. Esta confirmación corrige el error para asignar el índice de puerto correcto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: arm64: Anular el registro del redistribuidor en caso de creación fallida de una vCPU. Alex informa que syzkaller ha conseguido activar un use-after-free al desmantelar una máquina virtual: ERROR: KASAN: slab-use-after-free en kvm_put_kvm+0x300/0xe68 virt/kvm/kvm_main.c:5769 Lectura de tamaño 8 en la dirección ffffff801c6890d0 por la tarea syz.3.2219/10758 CPU: 3 UID: 0 PID: 10758 Comm: syz.3.2219 No contaminado 6.11.0-rc6-dirty #64 Nombre del hardware: linux,dummy-virt (DT) Rastreo de llamadas: dump_backtrace+0x17c/0x1a8 arch/arm64/kernel/stacktrace.c:317 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:324 __dump_stack lib/dump_stack.c:93 [en línea] dump_stack_lvl+0x94/0xc0 lib/dump_stack.c:119 print_report+0x144/0x7a4 mm/kasan/report.c:377 kasan_report+0xcc/0x128 mm/kasan/report.c:601 __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381 kvm_put_kvm+0x300/0xe68 virt/kvm/kvm_main.c:5769 kvm_vm_release+0x4c/0x60 virt/kvm/kvm_main.c:1409 __fput+0x198/0x71c fs/file_table.c:422 ____fput+0x20/0x30 fs/file_table.c:450 task_work_run+0x1cc/0x23c kernel/task_work.c:228 do_notify_resume+0x144/0x1a0 include/linux/resume_user_mode.h:50 el0_svc+0x64/0x68 arch/arm64/kernel/entry-common.c:169 el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Tras una inspección más detallada, parece que no eliminamos correctamente el registro MMIO para una vCPU que falla en la creación tarde en el juego, por ejemplo, una vCPU con el mismo ID ya existe en la VM. Es importante considerar el contexto de la confirmación que introdujo este error al mover la anulación del registro fuera de __kvm_vgic_vcpu_destroy(). Ese cambio buscó correctamente evitar una inversión de srcu v. config_lock al dividir el desmontaje de la vCPU en dos partes, una protegida por config_lock. Corrija el use-after-free mientras evita la inversión del bloqueo agregando una anulación del registro con caso especial a __kvm_vgic_vcpu_destroy(). Esto es seguro porque las vCPU fallidas se eliminan fuera de config_lock.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: rechazar la reconfiguración de ro->rw si hay requisitos de ro estrictos [ERROR]. Syzbot informa del siguiente fallo: Información de BTRFS (estado de loop0 del dispositivo MCS): deshabilitar el árbol de espacio libre Información de BTRFS (estado de loop0 del dispositivo MCS): borrando el indicador de función de compatibilidad para FREE_SPACE_TREE (0x1) Información de BTRFS (estado de loop0 del dispositivo MCS): borrando el indicador de función de compatibilidad para FREE_SPACE_TREE_VALID (0x2) Vaya: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x000000000000018-0x000000000000001f] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 RIP: 0010:backup_super_roots fs/btrfs/disk-io.c:1691 [en línea] RIP: 0010:write_all_supers+0x97a/0x40f0 fs/btrfs/disk-io.c:4041 Seguimiento de llamadas: btrfs_commit_transaction+0x1eae/0x3740 fs/btrfs/transaction.c:2530 btrfs_delete_free_space_tree+0x383/0x730 fs/btrfs/free-space-tree.c:1312 btrfs_start_pre_rw_mount+0xf28/0x1300 fs/btrfs/disk-io.c:3012 btrfs_remount_rw fs/btrfs/super.c:1309 [en línea] btrfs_reconfigure+0xae6/0x2d40 fs/btrfs/super.c:1534 btrfs_reconfigure_for_mount fs/btrfs/super.c:2020 [en línea] btrfs_get_tree_subvol fs/btrfs/super.c:2079 [en línea] btrfs_get_tree+0x918/0x1920 fs/btrfs/super.c:2115 vfs_get_tree+0x90/0x2b0 fs/super.c:1800 do_new_mount+0x2be/0xb40 fs/namespace.c:3472 do_mount fs/namespace.c:3812 [en línea] __do_sys_mount fs/namespace.c:4020 [en línea] __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:3997 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSA] Para admitir el montaje de diferentes subvolúmenes con diferentes indicadores RO/RW para las nuevas API de montaje, btrfs introdujo dos workarounds para admitir esta función: - Omitir las comprobaciones de opciones/funciones de montaje si estamos montando un subvolumen diferente - Reconfigurar el fs a RW si el montaje inicial es RO Combinando estos dos, podemos tener la siguiente secuencia: - Montar el fs ro,rescue=all,clear_cache,space_cache=v1 rescue=all marcará el fs como de solo lectura, por lo que no se borrará la caché v2. - Montar un subvolumen rw del mismo fs. Entramos en btrfs_get_tree_subvol(), pero fc_mount() devuelve EBUSY porque nuestro nuevo fc es RW, diferente del fs original. Ahora ingresamos btrfs_reconfigure_for_mount(), que cambia el indicador RO primero para que podamos obtener el fs_info existente. Luego reconfiguramos el fs a RW. - Durante la reconfiguración, se omite la verificación de opciones/características Esto significa que reiniciaremos el borrado de la caché v2 y volveremos a la caché v1. Esto activará escrituras en el sistema de archivos y, dado que el sistema de archivos original tiene la opción "rescue=all", omite la lectura del árbol csum. Y, eventualmente, provoca la desreferencia del puntero NULL en la reescritura del superbloque. [SOLUCIÓN] Para la reconfiguración causada por diferentes indicadores de RO/RW de subvolumen, asegúrese de que siempre ejecutamos btrfs_check_options() para garantizar que se cumplan los requisitos de RO estrictos adecuados. De hecho, la función btrfs_check_options() no realiza muchas comprobaciones complejas, sino requisitos de RO estrictos y algunas comprobaciones de dependencia de funciones, por lo que no hay ninguna razón especial para no realizar la comprobación para la reconfiguración del montaje.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: se corrige la advertencia al destruir 'cifs_io_request_pool' Hay un problema como el siguiente: ADVERTENCIA: CPU: 1 PID: 27826 en mm/slub.c:4698 free_large_kmalloc+0xac/0xe0 RIP: 0010:free_large_kmalloc+0xac/0xe0 Rastreo de llamadas: ? Obviamente, 'cifs_io_request_pool' no es creado por mempool_create(). Entonces simplemente use mempool_exit() para revertir 'cifs_io_request_pool'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Deshabilitar PSR-SU también en Parade 08-01 TCON Stuart Hayhurst ha descubierto que tanto en el arranque como en pantalla completa, el vídeo VA-API provoca pantallas negras durante alrededor de 1 segundo y rastros de ADVERTENCIA [1] en el kernel al llamar a dmub_psr_enable() con Parade 08-01 TCON. Todos estos síntomas desaparecen con PSR-SU deshabilitado para este TCON, así que deshabilítelo por ahora mientras se pueden analizar los rastros DMUB [2] del fallo y se puede determinar correctamente el estado del fallo. (seleccionado de la confirmación afb634a6823d8d9db23c5fb04f79c5549349628b)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: corrige una fuga de información del kernel más en el volcado de algoritmos. Durante las pruebas fuzz, se descubrió el siguiente problema: ERROR: KMSAN: fuga de información del kernel en _copy_to_iter+0x598/0x2a30 _copy_to_iter+0x598/0x2a30 __skb_datagram_iter+0x168/0x1060 skb_copy_datagram_iter+0x5b/0x220 netlink_recvmsg+0x362/0x1700 sock_recvmsg+0x2dc/0x390 __sys_recvfrom+0x381/0x6d0 __x64_sys_recvfrom+0x130/0x200 x64_sys_call+0x32c8/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Ununit se almacenó en la memoria en: copy_to_user_state_extra+0xcc1/0x1e00 dump_one_state+0x28c/0x5f0 xfrm_state_walk+0x548/0x11e0 xfrm_dump_sa+0x1e0/0x840 netlink_dump+0x943/0x1c40 __netlink_dump_start+0x746/0xdb0 xfrm_user_rcv_msg+0x429/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit se creó en: __kmalloc+0x571/0xd30 attached_auth+0x106/0x3e0 xfrm_add_sa+0x2aa0/0x4230 xfrm_user_rcv_msg+0x832/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Los bytes 328-379 de 732 no están inicializados El acceso a la memoria de tamaño 732 comienza en ffff88800e18e000 Datos copiados a la dirección de usuario 00007ff30f48aff0 CPU: 2 PID: 18167 Comm: syz-executor.0 No contaminado 6.8.11 #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Corrige la copia de algoritmos xfrm donde algunos datos aleatorios de los campos de estructura pueden terminar en el espacio de usuario. El relleno en las estructuras se puede rellenar con datos aleatorios (posiblemente confidenciales) y nunca se debe proporcionar directamente al espacio de usuario. Un problema similar se resolvió en la confirmación 8222d5910dae ("xfrm: relleno de ceros al volcar algoritmos y encap") encontrado por Linux Verification Center (linuxtesting.org) con Syzkaller.