Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: validar sectores_por_clústeres de BOOT Cuando el campo sectores_por_clústeres de BOOT de NTFS es > 0x80, representa un valor de desplazamiento. Asegúrese de que el valor de desplazamiento no sea demasiado grande antes de usarlo (el tamaño máximo del clúster de NTFS es 2 MB). Devuelva -EVINVAL si es demasiado grande. Esto evita valores de desplazamiento negativos y valores de desplazamiento que sean más grandes que el tamaño del campo. Previene este error de UBSAN: UBSAN: desplazamiento fuera de los límites en ../fs/ntfs3/super.c:673:16 el exponente de desplazamiento -192 es negativo

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: zsmalloc: arregla las ejecuciones entre la liberación asincrónica de zspage y la migración de página El trabajador de liberación asincrónica de zspage intenta bloquear la lista completa de páginas de una zspage sin defenderse contra la migración de página. Dado que las páginas que aún no se han bloqueado pueden migrar simultáneamente fuera de la lista de páginas de la zspage mientras lock_zspage() se procesa, lock_zspage() puede sufrir algunas ejecuciones letales diferentes. Puede bloquear una página que ya no pertenece a la zspage y desreferenciar de forma insegura page_private(), puede desreferenciar de forma insegura un puntero roto a la siguiente página (ya que hay una ejecución de datos), y puede observar un puntero NULL espurio a la siguiente página y, por lo tanto, no bloquear todas las páginas de la zspage (ya que una sola migración de página reconstruirá la lista de páginas completa, y create_page_chain() pone a cero incondicionalmente cada puntero de lista en el proceso). Corrija las ejecuciones usando migrants_read_lock() en lock_zspage() para sincronizar con la migración de página.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_qca: usar del_timer_sync() antes de liberar Al mirar un informe de fallas en una lista de temporizadores que se está corrompiendo, lo que generalmente sucede cuando se libera un temporizador mientras aún está activo. Esto se activa comúnmente por el código que llama a del_timer() en lugar de del_timer_sync() justo antes de liberar. Un posible culpable es el controlador hci_qca, que hace exactamente eso. Eric mencionó que wake_retrans_timer podría volver a armarse a través de la cola de trabajo, así que también mueva la destrucción de la cola de trabajo antes de del_timer_sync().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fpu: KVM: Establecer el tamaño uABI de la FPU invitada base en sizeof(struct kvm_xsave) Establezca el tamaño uABI inicial de la FPU invitada de KVM en 'struct kvm_xsave', es decir, en el tamaño uABI histórico de KVM. Al guardar el estado de la FPU para el espacio de usuario, KVM (bueno, ahora la FPU) establece los bits FP+SSE en el encabezado XSAVE incluso si el host no admite XSAVE. Establecer el encabezado XSAVE permite migrar la VM a un host que admita XSAVE sin que el nuevo host tenga que gestionar el estado de la FPU que puede o no ser compatible con XSAVE. Establecer el tamaño uABI en el tamaño predeterminado del host da como resultado escrituras fuera de los límites (establecer los bits FP+SSE) y corrupción de datos (que afortunadamente es detectada por KASAN) cuando se ejecuta en hosts sin XSAVE, por ejemplo, en CPU Core2. ADVERTENCIA si el tamaño predeterminado es mayor que el tamaño uABI histórico de KVM; todas las funciones que puedan aumentar el tamaño de FPU más allá del tamaño histórico deben ser habilitadas. ===================================================================== ERROR: KASAN: slab-out-of-bounds in fpu_copy_uabi_to_guest_fpstate+0x86/0x130 Read of size 8 at addr ffff888011e33a00 by task qemu-build/681 CPU: 1 PID: 681 Comm: qemu-build Not tainted 5.18.0-rc5-KASAN-amd64 #1 Hardware name: /DG35EC, BIOS ECG3510M.86A.0118.2010.0113.1426 01/13/2010 Call Trace: dump_stack_lvl+0x34/0x45 print_report.cold+0x45/0x575 kasan_report+0x9b/0xd0 fpu_copy_uabi_to_guest_fpstate+0x86/0x130 kvm_arch_vcpu_ioctl+0x72a/0x1c50 [kvm] kvm_vcpu_ioctl+0x47f/0x7b0 [kvm] __x64_sys_ioctl+0x5de/0xc90 do_syscall_64+0x31/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xae Allocated by task 0: (stack is not available) The buggy address belongs to the object at ffff888011e33800 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 0 bytes to the right of 512-byte region [ffff888011e33800, ffff888011e33a00) The buggy address belongs to the physical page: page:0000000089cd4adb refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11e30 head:0000000089cd4adb order:2 compound_mapcount:0 compound_pincount:0 flags: 0x4000000000010200(slab|head|zone=1) raw: 4000000000010200 dead000000000100 dead000000000122 ffff888001041c80 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888011e33900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888011e33980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff888011e33a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888011e33a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888011e33b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ======================================================================= Desactivar bloqueo depuración debido a la corrupción del kernel

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: comprobar si el número de clúster es válido Syzbot informó una lectura de slab fuera de los límites en exfat_clear_bitmap. Esto fue provocado por el reproductor que llama a truncute con tamaño 0, lo que provoca el siguiente seguimiento: ERROR: KASAN: slab-out-of-bounds in exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174 Read of size 8 at addr ffff888115aa9508 by task syz-executor251/365 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack_lvl+0x1e2/0x24b lib/dump_stack.c:118 print_address_description+0x81/0x3c0 mm/kasan/report.c:233 __kasan_report mm/kasan/report.c:419 [inline] kasan_report+0x1a4/0x1f0 mm/kasan/report.c:436 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:309 exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174 exfat_free_cluster+0x25a/0x4a0 fs/exfat/fatent.c:181 __exfat_truncate+0x99e/0xe00 fs/exfat/file.c:217 exfat_truncate+0x11b/0x4f0 fs/exfat/file.c:243 exfat_setattr+0xa03/0xd40 fs/exfat/file.c:339 notify_change+0xb76/0xe10 fs/attr.c:336 do_truncate+0x1ea/0x2d0 fs/open.c:65 Move the is_valid_cluster() helper from fatent.c to a common header to make it reusable in other *.c files. And add is_valid_cluster() to validate if cluster number is within valid range in exfat_clear_bitmap() and exfat_set_bitmap().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: conntrack: volver a obtener conntrack después de la inserción En caso de que conntrack esté en conflicto, la inserción puede liberar skb->_nfct y establecer skb->_nfct en la entrada ya confirmada. Esto no se encontró antes porque la entrada conntrack y el espacio de extensión solían liberarse después de un período de gracia de rcu, además de que la ejecución necesita eventos habilitados para activarse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: Use __try_cmpxchg_user() para actualizar los bits A/D de la PTE invitada Use la recientemente introducida __try_cmpxchg_user() para actualizar los bits A/D de la PTE invitada en lugar de mapear la PTE en el espacio de direcciones del kernel. La ruta VM_PFNMAP está rota ya que asume que vm_pgoff es la pfn base del rango VMA mapeado, lo cual es conceptualmente incorrecto ya que vm_pgoff es el desplazamiento relativo al archivo y no tiene nada que ver con la pfn. El horrible hack funcionó para el caso de uso original (respaldar la memoria invitada con /dev/mem), pero conduce al acceso a pfn "aleatorios" para prácticamente cualquier otro caso VM_PFNMAP.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: se corrige una posible doble liberación durante un montaje fallido de RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2088799

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Mover la comprobación cfg_log_verbose antes de llamar a lpfc_dmp_dbg() En un intento de registrar el mensaje 0126 con LOG_TRACE_EVENT, el siguiente seguimiento de llamada de bloqueo duro cuelga el sistema. Seguimiento de llamadas: _raw_spin_lock_irqsave+0x32/0x40 lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc] lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc] lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc] lpfc_els_flush_cmd+0x43c/0x670 [lpfc] lpfc_els_flush_all_cmd+0x37/0x60 [lpfc] lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc] lpfc_do_work+0x1485/0x1d70 [lpfc] kthread+0x112/0x130 ret_from_fork+0x1f/0x40 Kernel panic - not syncing: Hard LOCKUP The same CPU tries to claim the phba->port_list_lock twice. Move the cfg_log_verbose checks as part of the lpfc_printf_vlog() and lpfc_printf_log() macros before calling lpfc_dmp_dbg(). There is no need to take the phba->port_list_lock within lpfc_dmp_dbg().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath11k: corrige la advertencia de dev_wake en mhi_pm_disable_transition(). Cuando se prueba la recuperación del dispositivo con el siguiente comando, aparece una advertencia en el mensaje que se muestra a continuación. echo assert > /sys/kernel/debug/ath11k/wcn6855\ hw2.0/simulate_fw_crash echo assert > /sys/kernel/debug/ath11k/qca6390\ hw2.0/simulate_fw_crash warning message: [ 1965.642121] ath11k_pci 0000:06:00.0: simulating firmware assert crash [ 1968.471364] ieee80211 phy0: Hardware restart was requested [ 1968.511305] ------------[ cut here ]------------ [ 1968.511368] WARNING: CPU: 3 PID: 1546 at drivers/bus/mhi/core/pm.c:505 mhi_pm_disable_transition+0xb37/0xda0 [mhi] [ 1968.511443] Modules linked in: ath11k_pci ath11k mac80211 libarc4 cfg80211 qmi_helpers qrtr_mhi mhi qrtr nvme nvme_core [ 1968.511563] CPU: 3 PID: 1546 Comm: kworker/u17:0 Kdump: loaded Tainted: G W 5.17.0-rc3-wt-ath+ #579 [ 1968.511629] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 [ 1968.511704] Workqueue: mhi_hiprio_wq mhi_pm_st_worker [mhi] [ 1968.511787] RIP: 0010:mhi_pm_disable_transition+0xb37/0xda0 [mhi] [ 1968.511870] Code: a9 fe ff ff 4c 89 ff 44 89 04 24 e8 03 46 f6 e5 44 8b 04 24 41 83 f8 01 0f 84 21 fe ff ff e9 4c fd ff ff 0f 0b e9 af f8 ff ff <0f> 0b e9 5c f8 ff ff 48 89 df e8 da 9e ee e3 e9 12 fd ff ff 4c 89 [ 1968.511923] RSP: 0018:ffffc900024efbf0 EFLAGS: 00010286 [ 1968.511969] RAX: 00000000ffffffff RBX: ffff88811d241250 RCX: ffffffffc0176922 [ 1968.512014] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff888118a90a24 [ 1968.512059] RBP: ffff888118a90800 R08: 0000000000000000 R09: ffff888118a90a27 [ 1968.512102] R10: ffffed1023152144 R11: 0000000000000001 R12: ffff888118a908ac [ 1968.512229] R13: ffff888118a90928 R14: dffffc0000000000 R15: ffff888118a90a24 [ 1968.512310] FS: 0000000000000000(0000) GS:ffff888234200000(0000) knlGS:0000000000000000 [ 1968.512405] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1968.512493] CR2: 00007f5538f443a8 CR3: 000000016dc28001 CR4: 00000000003706e0 [ 1968.512587] Call Trace: [ 1968.512672] [ 1968.512751] ? _raw_spin_unlock_irq+0x1f/0x40 [ 1968.512859] mhi_pm_st_worker+0x3ac/0x790 [mhi] [ 1968.512959] ? mhi_pm_mission_mode_transition.isra.0+0x7d0/0x7d0 [mhi] [ 1968.513063] process_one_work+0x86a/0x1400 [ 1968.513184] ? pwq_dec_nr_in_flight+0x230/0x230 [ 1968.513312] ? move_linked_works+0x125/0x290 [ 1968.513416] worker_thread+0x6db/0xf60 [ 1968.513536] ? process_one_work+0x1400/0x1400 [ 1968.513627] kthread+0x241/0x2d0 [ 1968.513733] ? kthread_complete_and_exit+0x20/0x20 [ 1968.513821] ret_from_fork+0x22/0x30 [ 1968.513924] Reason is mhi_deassert_dev_wake() from mhi_device_put() is called but mhi_assert_dev_wake() from __mhi_device_get_sync() is not called in progress of recovery. Commit 8e0559921f9a ("bus: mhi: core: Skip device wake in error or shutdown state") add check for the pm_state of mhi in __mhi_device_get_sync(), and the pm_state is not the normal state untill recovery is completed, so it leads the dev_wake is not 0 and above warning print in mhi_pm_disable_transition() while checking mhi_cntrl->dev_wake. Add check in ath11k_pci_write32()/ath11k_pci_read32() to skip call mhi_device_put() if mhi_device_get_sync() does not really do wake, then the warning gone. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipw2x00: Se corrige la posible desreferenciación NULL en libipw_xmit() crypt y crypt->ops podrían ser nulos, por lo que debemos verificar los valores nulos antes de la desreferenciación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/kexec: se corrige la pérdida de memoria del búfer de encabezado elf Esto lo informa el detector kmemleak: objeto sin referencia 0xffffc900002a9000 (size 4096): comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s) hex dump (first 32 bytes): 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............ 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..>............. backtrace: [<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170 [<000000002b66b6c0>] __vmalloc_node+0xb4/0x160 [<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0 [<0000000019afff23>] crash_load_segments+0x260/0x470 [<0000000019ebe95c>] bzImage64_load+0x814/0xad0 [<0000000093e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0 [<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0 [<0000000038f5a97a>] __do_sys_kexec_file_load+0x28d/0x530 [<0000000087c19992>] do_syscall_64+0x3b/0x90 [<0000000066e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xae In crash_prepare_elf64_headers(), se asigna un búfer a través de vmalloc() para almacenar encabezados elf. Sin embargo, no se libera correctamente al sistema cuando se vuelve a cargar o descargar el kernel kdump. Entonces se produce una pérdida de memoria. Arréglelo introduciendo la función específica x86 arch_kimage_file_post_load_cleanup() y liberando el búfer allí. Y también elimine el código incorrecto de liberación del búfer del encabezado elf. Antes de llamar a la función de carga kexec_file específica de arch, se ha inicializado la instancia de la imagen. Por lo tanto, 'image->elf_headers' debe ser NULL. No tiene sentido liberar el búfer del encabezado elf en ese lugar. Tres personas diferentes han informado tres errores sobre la pérdida de memoria en x86_64 dentro de Redhat.