Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xsk: liberar skb cuando las opciones de metadatos TX no son válidas Cuando se asigna un nuevo skb para transmitir un descriptor xsk, es decir, para cada descriptor que no sea multibuf o el primer fragmento de un descriptor multibuf, pero luego se descubre que el descriptor tiene opciones no válidas establecidas para los metadatos TX, el nuevo skb nunca se libera. Esto puede filtrar skbs hasta que el búfer de envío esté lleno, lo que hace imposible enviar más paquetes. Solucione esto liberando el skb en la ruta de error si actualmente estamos tratando con el primer fragmento, es decir, un skb asignado en esta iteración de xsk_build_skb.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: corrección de use-after-free en device_for_each_child() Syzbot ha informado del siguiente splat de KASAN: ERROR: KASAN: slab-use-after-free en device_for_each_child+0x18f/0x1a0 Lectura de tamaño 8 en la dirección ffff88801f605308 por la tarea kbnepd bnep0/4980 CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 No contaminado 6.12.0-rc4-00161-gae90f6a6170d #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 Rastreo de llamadas: dump_stack_lvl+0x100/0x190 ? dispositivo_para_cada_hijo+0x18f/0x1a0 imprimir_informe+0x13a/0x4cb ? __virt_addr_valid+0x5e/0x590 ? __phys_addr+0xc6/0x150 ? dispositivo_para_cada_hijo+0x18f/0x1a0 kasan_informe+0xda/0x110 ? dispositivo_para_cada_hijo+0x18f/0x1a0 ? __pfx_dev_memalloc_noio+0x10/0x10 dispositivo_para_cada_hijo+0x18f/0x1a0 ? __pfx_device_for_each_child+0x10/0x10 pm_runtime_set_memalloc_noio+0xf2/0x180 netdev_unregister_kobject+0x1ed/0x270 anular_registro_de_dispositivo_de_red_muchas_notificaciones+0x123c/0x1d80 ? __mutex_trylock_common+0xde/0x250 ? __pfx_unregister_netdevice_muchas_notificaciones+0x10/0x10 ? trace_contention_end+0xe6/0x140 ? __mutex_lock+0x4e7/0x8f0 ? __pfx_lock_acquire.part.0+0x10/0x10 ? rcu_is_watching+0x12/0xc0 ? anular el registro de_netdev+0x12/0x30 anular el registro de_netdevice_queue+0x30d/0x3f0 ? __pfx_anular el registro de_netdevice_queue+0x10/0x10 ? __pfx_down_write+0x10/0x10 anular el registro de_netdev+0x1c/0x30 bnep_session+0x1fb3/0x2ab0 ? __pfx_bnep_session+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? __pfx_woken_wake_function+0x10/0x10 ? __kthread_parkme+0x132/0x200 ? __pfx_bnep_session+0x10/0x10 ? kthread+0x13a/0x370 ? __pfx_bnep_session+0x10/0x10 kthread+0x2b7/0x370 ? __pfx_kthread+0x10/0x10 ret_de_la_bifurcación+0x48/0x80 ? Asignado por la tarea 4974: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x1d1/0x440 hci_alloc_dev_priv+0x1d/0x2820 __vhci_create_device+0xef/0x7d0 vhci_write+0x2c7/0x480 vfs_write+0x6a0/0xfc0 ksys_write+0x12f/0x260 do_syscall_64+0xc7/0x250 entrada_SYSCALL_64_after_hwframe+0x77/0x7f Liberado por la tarea 4979: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x4f/0x70 kfree+0x141/0x490 hci_release_dev+0x4d9/0x600 bt_host_release+0x6a/0xb0 device_release+0xa4/0x240 kobject_put+0x1ec/0x5a0 put_device+0x1f/0x30 vhci_release+0x81/0xf0 __fput+0x3f6/0xb30 En 'hci_conn_del_sysfs()', se puede llamar a 'device_unregister()' cuando un contador de referencia subyacente (kobject) es mayor que 1. Esto significa que la re-asignación de padres (que ocurre cuando el dispositivo se libera realmente) se demora y, durante esa demora, se puede eliminar el dispositivo controlador principal (hciX). Dado que esto último puede crear un puntero colgante al padre liberado, evite ese escenario cambiando el padre a NULL explícitamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: 6fire: Liberar recursos al liberar la tarjeta El código 6fire actual intenta liberar los recursos justo después de la llamada a usb6fire_chip_abort(). Pero en este momento, el objeto de la tarjeta podría estar todavía en uso (ya que estamos llamando a snd_card_free_when_closed()). Para evitar posibles UAF, mueva la liberación de recursos a private_free de la tarjeta en lugar de la llamada manual a usb6fire_chip_destroy() en la devolución de llamada de desconexión USB.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: caiaq: Usar snd_card_free_when_closed() en la desconexión Se supone que la devolución de llamada de desconexión USB es corta y no requiere una espera demasiado larga. Por otro lado, el código actual usa snd_card_free() en la desconexión, pero esto espera el cierre de todos los fds usados, por lo tanto, puede tomar mucho tiempo. Eventualmente bloquea los ioctl USB de la capa superior, lo que puede desencadenar un bloqueo suave. Una solución fácil es reemplazar snd_card_free() con snd_card_free_when_closed(). Esta variante regresa inmediatamente mientras que la liberación de recursos se realiza de forma asincrónica por la liberación del dispositivo de la tarjeta en el último cierre. Este parche también divide el código en las fases de desconexión y liberación; la primera se llama inmediatamente en la devolución de llamada de desconexión USB mientras que la segunda se llama desde el destructor de la tarjeta.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: us122l: Usar snd_card_free_when_closed() en la desconexión Se supone que la devolución de llamada de desconexión USB es corta y no requiere una espera demasiado larga. Por otro lado, el código actual usa snd_card_free() en la desconexión, pero esto espera el cierre de todos los fds usados, por lo tanto, puede tomar mucho tiempo. Eventualmente bloquea los ioctl USB de la capa superior, lo que puede desencadenar un bloqueo suave. Una solución fácil es reemplazar snd_card_free() con snd_card_free_when_closed(). Esta variante regresa inmediatamente mientras que la liberación de recursos se realiza de forma asincrónica por la liberación del dispositivo de la tarjeta en el último cierre. El bucle de comprobación us122l->mmap_count también se elimina. La comprobación es inútil para la operación asincrónica con *_when_closed().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usx2y: Usar snd_card_free_when_closed() en la desconexión Se supone que la devolución de llamada de desconexión USB es corta y no requiere una espera demasiado larga. Por otro lado, el código actual usa snd_card_free() en la desconexión, pero esto espera el cierre de todos los fds usados, por lo tanto, puede tomar mucho tiempo. Eventualmente bloquea los ioctl USB de la capa superior, lo que puede desencadenar un bloqueo suave. Una solución fácil es reemplazar snd_card_free() con snd_card_free_when_closed(). Esta variante regresa inmediatamente mientras que la liberación de recursos se realiza de forma asincrónica por la liberación del dispositivo de la tarjeta en el último cierre.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: kvm: Fix out-of-bounds array access En kvm_riscv_vcpu_sbi_init(), entry->ext_idx puede contener un índice fuera de los límites. Esto se utiliza como un marcador especial para las extensiones base, que no se pueden deshabilitar. Sin embargo, al recorrer las extensiones, ese marcador especial no se verifica antes de indexar la matriz. Agregue una verificación fuera de los límites a la función.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/s390: Implementar dominio de bloqueo Esto corrige un fallo al desconectar en caliente por sorpresa un dispositivo PCI. Este fallo ocurre porque durante la desconexión en caliente __iommu_group_set_domain_nofail() la conexión del dominio predeterminado falla cuando la plataforma ya no reconoce el dispositivo porque ya se ha eliminado y terminamos con un puntero de dominio NULL y UAF. Este es exactamente el caso al que se hace referencia en el segundo comentario en __iommu_device_set_domain() y tal como se indica allí, si en su lugar podemos conectar el dominio de bloqueo, se evita el UAF ya que puede gestionar el dispositivo ya eliminado. Implemente el dominio de bloqueo para usar esta gestión. Con este cambio, el fallo se corrige, pero aún encontramos una advertencia al intentar cambiar la propiedad de DMA en un dispositivo bloqueado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: se corrigen los montajes respaldados por archivos sobre FUSE syzbot informó de un null-ptr-deref en fuse_read_args_fill: fuse_read_folio+0xb0/0x100 fs/fuse/file.c:905 filemap_read_folio+0xc6/0x2a0 mm/filemap.c:2367 do_read_cache_folio+0x263/0x5c0 mm/filemap.c:3825 read_mapping_folio include/linux/pagemap.h:1011 [en línea] erofs_bread+0x34d/0x7e0 fs/erofs/data.c:41 erofs_read_superblock fs/erofs/super.c:281 [en línea] erofs_fc_fill_super+0x2b9/0x2500 fs/erofs/super.c:625 A diferencia de la mayoría de los sistemas de archivos, algunos sistemas de archivos de red y FUSE necesitan punteros de `archivo` válidos e inevitables para sus E/S de lectura [1]. De todos modos, esos casos de uso también deben ser compatibles. [1] https://docs.kernel.org/filesystems/vfs.html

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/rxe: se han corregido las advertencias de vaciado de qp en req. Cuando el qp está en estado de error, el estado de los WQE en la cola debe establecerse en error. De lo contrario, aparecerá lo siguiente. [ 920.617269] ADVERTENCIA: CPU: 1 PID: 21 en drivers/infiniband/sw/rxe/rxe_comp.c:756 rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.617744] Módulos vinculados en: rnbd_client(O) rtrs_client(O) rtrs_core(O) rdma_ucm rdma_cm iw_cm ib_cm crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel ib_uverbs ib_core loop brd null_blk ipv6 [ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Contaminado: GO 6.1.113-storage+ #65 [ 920.618986] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 920.619396] RIP: 0010:rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.619658] Código: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24 [ 920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246 [ 920.620817] RAX: 000000000000000 RBX: 000000000000000c RCX: 0000000000000008 [ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac [ 920.621548] RBP: 00000000000000000 R08: 00000000000000001 R09: ffffffffac406450 [ 920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800 [ 920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 000000000000000 [ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000 [ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0 [ 920.623680] Rastreo de llamadas: [ 920.623815] [ 920.623933] ? __warn+0x79/0xc0 [ 920.624116] ? asm_exc_invalid_op+0x16/0x20 [ 920.625203] ? rxe_cq_post+0xe2/0x180 [rdma_rxe] [ 920.626583] ? do_complete+0x18d/0x220 [rdma_rxe] [ 920.626812] ? rxe_completer+0x1a3/0xcc0 [rdma_rxe] [ 920.627050] rxe_do_task+0x80/0x110 [rdma_rxe] [ 920.627285] tasklet_action_common.constprop.0+0xa4/0x120 [ 920.627522] handle_softirqs+0xc2/0x250 [ 920.627728] ? rango_de_ordenación+0x20/0x20 [ 920.627942] ejecutar_ksoftirqd+0x1f/0x30 [ 920.628158] función_de_subproceso_de_arranque_smp+0xc7/0x1b0 [ 920.628334] subproceso_k+0xd6/0x100 [ 920.628504] ? kthread_completar_y_salir+0x20/0x20 [ 920.628709] retirar_de_la_bifurcación+0x1f/0x30 [ 920.628892]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: CPPC: Se corrige la posible desreferenciación de puntero nulo para cppc_get_cpu_cost(). cpufreq_cpu_get_raw() puede devolver NULL si la CPU no está en la máscara de CPU policy->cpus y provocará una desreferenciación de puntero nulo, así que verifique NULL para cppc_get_cpu_cost().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: CPPC: Se corrige la posible desreferenciación de puntero nulo para cpufreq_cpu_get_raw(). cpufreq_cpu_get_raw() puede devolver NULL si la CPU no está en la máscara de CPU policy->cpus y provocará una desreferenciación de puntero nulo.