Vulnerabilidades

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: unicode: Fix utf8_load() error path utf8_load() solicita el símbolo "utf8_data_table" y luego verifica si la versión UTF-8 solicitada es compatible. Si no es compatible, intenta poner la tabla de datos usando symbol_put(). Si se solicita una versión no compatible, symbol_put() falla de la siguiente manera: kernel BUG at kernel/module/main.c:786! RIP: 0010:__symbol_put+0x93/0xb0 Call Trace: ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __symbol_put+0x93/0xb0 ? exc_invalid_op+0x51/0x70 ? __symbol_put+0x93/0xb0 ? asm_exc_invalid_op+0x1a/0x20 ? __pfx_cmp_name+0x10/0x10 ? __symbol_put+0x93/0xb0 ? __symbol_put+0x62/0xb0 utf8_load+0xf8/0x150 Esto sucede porque symbol_put() espera la cadena única que identifica el símbolo, en lugar de un puntero al símbolo cargado. Solucione esto utilizando dicha cadena.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: gestiona lclusters NONHEAD !delta[1] con gracia syzbot informó una ADVERTENCIA en iomap_iter_done: iomap_fiemap+0x73b/0x9b0 fs/iomap/fiemap.c:80 ioctl_fiemap fs/ioctl.c:220 [en línea] Generalmente, los lclusters NONHEAD no tendrán delta[1]==0, excepto para imágenes y sistemas de archivos creados por versiones de mkfs anteriores a la 1.0. Anteriormente, se cancelaba inmediatamente si delta[1]==0, lo que provocaba longitudes descomprimidas inadecuadas (por lo tanto, FIEMAP se ve afectado). Trátelo como delta[1]=1 para solucionar estas versiones heredadas de mkfs. `lclusterbits > 14` es ilegal para índices compactos, también genera un error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección de null-ptr-deref en f2fs_submit_page_bio() Existe el siguiente problema al instalar simultáneamente el módulo f2fs.ko y montar el sistema de archivos f2fs: KASAN: null-ptr-deref en el rango [0x0000000000000020-0x0000000000000027] RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs] Seguimiento de llamadas: f2fs_submit_page_bio+0x126/0x8b0 [f2fs] __get_meta_page+0x1d4/0x920 [f2fs] get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs] El problema anterior ocurre porque el biset del sistema de archivos f2fs no está configurado inicializado antes de registrar "f2fs_fs_type". Para solucionar el problema anterior, simplemente registre "f2fs_fs_type" al final de init_f2fs_fs(). Asegúrese de que todos los recursos del sistema de archivos f2fs estén inicializados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: zram: arregla el puntero NULL en comp_algorithm_show() LTP informó una desreferencia de puntero NULL de la siguiente manera: CPU: 7 UID: 0 PID: 5995 Comm: cat Kdump: cargado No contaminado 6.12.0-rc6+ #3 Nombre del hardware: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __pi_strcmp+0x24/0x140 lr : zcomp_available_show+0x60/0x100 [zram] sp : ffff800088b93b90 x29: ffff800088b93b90 x28: 0000000000000001 x27: 0000000000400cc0 x26: 0000000000000ffe x25: ffff80007b3e2388 x24: 00000000000000000 x23: ffff80007b3e2390 x22: ffff0004041a9000 x21: ffff80007b3e2900 x20: 0000000000000000 x19: 00000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff80007b3e2900 x9: ffff80007b3cb280 x8: 0101010101010101 x7: 0000000000000000 x6: 0000000000000000 x5: 0000000000000040 x4 : 0000000000000000 x3 : 00656c722d6f7a6c x2 : 000000000000000 x1 : ffff80007b3e2900 x0 : 0000000000000000 Rastreo de llamadas: __pi_strcmp+0x24/0x140 comp_algorithm_show+0x40/0x70 [zram] dev_attr_show+0x28/0x80 sysfs_kf_seq_show+0x90/0x140 kernfs_seq_show+0x34/0x48 seq_read_iter+0x1d4/0x4e8 El zram->comp_algs[ZRAM_PRIMARY_COMP] puede ser NULL en zram_add() si No se ha llamado a comp_algorithm_set(). El usuario puede acceder al dispositivo zram mediante sysfs después de device_add_disk(), por lo que hay una ventana de tiempo para activar la desreferencia del puntero NULL. Muévalo hacia delante en device_add_disk() para asegurarse de que cuando el usuario pueda acceder al dispositivo zram, esté listo. comp_algorithm_set() está protegido por zram->init_lock en otros lugares y no existe ese problema.