Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: doble anulación del registro de gancho en la ruta netns __nft_release_hooks() se llama desde la ruta de salida pre_netns, lo que anula el registro de los ganchos; luego, se activa el evento NETDEV_UNREGISTER, que anula el registro de los ganchos nuevamente. [ 565.221461] WARNING: CPU: 18 PID: 193 at net/netfilter/core.c:495 __nf_unregister_net_hook+0x247/0x270 [...] [ 565.246890] CPU: 18 PID: 193 Comm: kworker/u64:1 Tainted: G E 5.18.0-rc7+ #27 [ 565.253682] Workqueue: netns cleanup_net [ 565.257059] RIP: 0010:__nf_unregister_net_hook+0x247/0x270 [...] [ 565.297120] Call Trace: [ 565.300900] [ 565.304683] nf_tables_flowtable_event+0x16a/0x220 [nf_tables] [ 565.308518] raw_notifier_call_chain+0x63/0x80 [ 565.312386] unregister_netdevice_many+0x54f/0xb50 Anule el registro y destruya el gancho netdev de netns pre_exit a través de kfree_rcu para que la ruta NETDEV_UNREGISTER vea los ganchos no registrados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: Eliminar WARNs que afirman que un triple fallo nunca "escapa" de L2 Eliminar WARNs que comprueban que KVM nunca permite que un triple fallo para L2 escape y termine incorrectamente en L1. En funcionamiento normal, la comprobación de cordura es perfectamente válida, pero supone incorrectamente que es imposible para el espacio de usuario inducir KVM_REQ_TRIPLE_FAULT sin rebotar a través de KVM_RUN (lo que garantiza que kvm_check_nested_state() verá y manejará el triple fallo). El WARN se puede activar actualmente si el espacio de usuario inyecta una comprobación de máquina mientras L2 está activo y CR4.MCE=0. Y una solución futura para permitir guardar/restaurar KVM_REQ_TRIPLE_FAULT, por ejemplo, para que un triple fallo sintetizado no se pierda en la migración, hará que sea trivialmente fácil para el espacio de usuario activar el WARN. Borrar KVM_REQ_TRIPLE_FAULT al salir forzosamente del modo invitado es tentador, pero incorrecto, especialmente si/cuando la solicitud se guarda/restaura, por ejemplo, si el espacio de usuario restaura eventos (incluido un triple error) y luego restaura el estado anidado (que puede salir forzosamente del modo invitado). Si ignoramos el hecho de que KVM actualmente no proporciona las API necesarias, es responsabilidad del espacio de usuario administrar los eventos pendientes durante el guardado/restauración. ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 7 PID: 1399 at arch/x86/kvm/vmx/nested.c:4522 nested_vmx_vmexit+0x7fe/0xd90 [kvm_intel] Modules linked in: kvm_intel kvm irqbypass CPU: 7 PID: 1399 Comm: state_test Not tainted 5.17.0-rc3+ #808 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:nested_vmx_vmexit+0x7fe/0xd90 [kvm_intel] Call Trace: vmx_leave_nested+0x30/0x40 [kvm_intel] vmx_set_nested_state+0xca/0x3e0 [kvm_intel] kvm_arch_vcpu_ioctl+0xf49/0x13e0 [kvm] kvm_vcpu_ioctl+0x4b9/0x660 [kvm] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae ---[ end trace 0000000000000000 ]---

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: KVM: SVM: Usar kzalloc para interfaces sev ioctl para evitar fugas de datos del kernel Para algunas interfaces sev ioctl, el parámetro de longitud que se pasa puede ser menor o igual a SEV_FW_BLOB_MAX_SIZE, pero mayor que los datos que devuelve el firmware de PSP. En este caso, kmalloc asignará memoria que sea del tamaño de la entrada en lugar del tamaño de los datos. Dado que el firmware de PSP no sobrescribe por completo el búfer asignado, estas interfaces sev ioctl pueden devolver memoria de losa de kernel no inicializada.

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: ALSA: usb-audio: Cancelar trabajo pendiente al cerrar un subflujo MIDI Al cerrar un subflujo de salida MIDI USB, es posible que aún haya un trabajo pendiente, que eventualmente accedería al objeto de tiempo de ejecución rawmidi que se está liberando. Para solucionar el problema, asegúrese de cancelar el trabajo pendiente al cerrar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: arregla el bloqueo entre escrituras dio concurrentes cuando hay poco espacio libre en los datos Al reservar espacio de datos para una escritura IO directa podemos acabar en un bloqueo si tenemos varias tareas intentando escribir en el mismo rango de archivos, hay varias extensiones cubiertas por ese rango de archivos, tenemos poco espacio disponible para los datos y las escrituras no expanden el i_size del inodo. El bloqueo puede ocurrir así: 1) Tenemos un archivo con un i_size de 1M, en el desplazamiento 0 tiene una extensión con un tamaño de 128K y en el desplazamiento 128K tiene otra extensión también con un tamaño de 128K; 2) La tarea A realiza una escritura IO directa contra el rango de archivos [0, 256K), y debido a que la escritura está dentro del límite i_size, toma el bloqueo del inodo (nivel VFS) en modo compartido; 3) La tarea A bloquea el rango de archivos [0, 256K) en btrfs_dio_iomap_begin() y luego obtiene el mapa de extensión para la extensión que cubre el rango [0, 128K). En btrfs_get_blocks_direct_write(), crea una extensión ordenada para ese rango de archivos ([0, 128K)); 4) Antes de regresar de btrfs_dio_iomap_begin(), desbloquea el rango de archivos [0, 256K); 5) La tarea A ejecuta btrfs_dio_iomap_begin() nuevamente, esta vez para el rango de archivos [128K, 256K), y bloquea el rango de archivos [128K, 256K); 6) La tarea B también inicia una escritura de E/S directa contra el rango de archivos [0, 256K). También bloquea el inodo en modo compartido, ya que está dentro del límite i_size, y luego intenta bloquear el rango de archivos [0, 256K). Puede bloquear el subrango [0, 128K) pero luego bloquea la espera del rango [128K, 256K), ya que está bloqueado actualmente por la tarea A; 7) La tarea A ingresa a btrfs_get_blocks_direct_write() e intenta reservar espacio de datos. Debido a que tenemos poco espacio libre disponible, activa la tarea de recuperación de datos asíncrona y espera a que reserve espacio de datos; 8) La tarea de recuperación asíncrona decide esperar a que se completen todas las extensiones ordenadas existentes (a través de btrfs_wait_ordered_roots()). Encuentra la extensión ordenada creada previamente por la tarea A para el rango de archivos [0, 128K) y espera a que se complete; 9) La extensión ordenada para el rango de archivos [0, 128K) no se puede completar porque se bloquea en btrfs_finish_ordered_io() cuando intenta bloquear el rango de archivos [0, 128K). Esto da como resultado un punto muerto, porque: - la tarea B mantiene bloqueado el rango de archivos [0, 128K), esperando que la tarea A desbloquee el rango [128K, 256K); - la tarea A mantiene bloqueado el rango de archivos [128K, 256K) y está esperando que la tarea de recuperación de datos asíncrona satisfaga su solicitud de reserva de espacio; - la tarea de recuperación de datos asíncrona está esperando que se complete la extensión ordenada [0, 128K), pero la extensión ordenada no se puede completar porque el rango de archivos [0, 128K) está bloqueado actualmente por la tarea B, que está esperando que la tarea A desbloquee el rango de archivos [128K, 256K) y la tarea A está esperando la tarea de recuperación de datos asíncrona. Esto da como resultado un bloqueo entre 4 tareas: la tarea A, la tarea B, la tarea de recuperación de datos asincrónica y la tarea que realiza la finalización de la extensión ordenada (una tarea de cola de trabajo). Este tipo de bloqueo puede ser activado esporádicamente por el caso de prueba generic/300 de fstests y da como resultado un seguimiento de pila como el siguiente: [12084.033689] INFO: la tarea kworker/u16:7:123749 se bloqueó durante más de 241 segundos. [12084.033689] INFO: task kworker/u16:7:123749 blocked for more than 241 seconds. [12084.034877] Not tainted 5.18.0-rc2-btrfs-next-115 #1 [12084.035562] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [12084.036548] task:kworker/u16:7 state:D stack: 0 pid:123749 ppid: 2 flags:---truncated---