Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sysctl: inicializar siempre i_uid/i_gid Inicializar siempre i_uid/i_gid dentro del núcleo sysfs para que set_ownership() pueda omitir su configuración de forma segura. Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: corrija los valores predeterminados de i_uid/i_gid en los inodos /proc/sys.") agregó valores predeterminados para i_uid/i_gid cuando no se implementó set_ownership(). También omitió ajustar net_ctl_set_ownership() para usar los mismos valores predeterminados en caso de que fallara el cálculo de un valor mejor.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: venus: arreglar el use after free en vdec_close Parece haber un posible use after free con vdec_close(). El firmware agregará trabajo de liberación de búfer a la cola de trabajos a través de devoluciones de llamada HFI como parte normal de la decodificación. Cerrar aleatoriamente el dispositivo decodificador desde el espacio de usuario durante la decodificación normal puede generar una lectura después de la liberación por instante. Solucionarlo cancelando el trabajo en vdec_close.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige el use after free el mapa de extensión al agregar páginas a una biografía comprimida En add_ra_bio_pages() estamos accediendo al mapa de extensión para calcular 'add_size' después de que eliminamos nuestra referencia en el mapa de extensión, lo que resulta en un use-after-free. Solucione este problema calculando 'add_size' antes de eliminar nuestra referencia del mapa de extensión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: corrige un posible punto muerto en __exfat_get_dentry_set Al acceder a un archivo con más entradas que ES_MAX_ENTRY_NUM, la matriz bh se asigna en __exfat_get_entry_set. El problema es que el bh-array está asignado con GFP_KERNEL. No tiene sentido. En los siguientes casos, puede ocurrir un punto muerto para sbi->s_lock entre los dos procesos. CPU0 CPU1 ---- ---- kswapd balance_pgdat lock(fs_reclaim) exfat_iterate lock(&sbi->s_lock) exfat_readdir exfat_get_uniname_from_ext_entry exfat_get_dentry_set __exfat_get_dentry_set kmalloc_array ... lock(fs_reclaim) ... desalojar exfat_evict_inode lock(&sbi->s_lock) para arreglar esto, asignemos bh-array con GFP_NOFS.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/mglru: corrige div-by-zero en vmpression_calc_level() evict_folios() utiliza una segunda pasada para recuperar las publicaciones que han pasado por la reescritura de páginas y quedan limpias antes de finalizar el primer pase, ya que folio_rotate_reclaimable() no puede manejar esos folios debido al aislamiento. El segundo paso intenta evitar un posible doble conteo deduciendo scan_control->nr_scanned. Sin embargo, esto puede resultar en un desbordamiento insuficiente de nr_scanned, bajo una condición en la que Shrink_folio_list() no incrementa nr_scanned, es decir, cuando falla folio_trylock(). El desbordamiento insuficiente puede causar que el divisor, es decir, escala=escaneado+reclamado en vmpression_calc_level(), se convierta en cero, lo que resulta en el siguiente bloqueo: [excepción RIP: vmpression_work_fn+101] Process_one_work en ffffffffa3313f2b Dado que scan_control->nr_scanned no tiene una semántica establecida, la posible doble contabilización tiene riesgos mínimos. Por lo tanto, solucione el problema no deduciendo scan_control->nr_scanned en evict_folios().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/huge_memory: evite el caché de páginas de tamaño PMD si es necesario. xarray no puede admitir un tamaño de caché de páginas arbitrario. el tamaño de caché de página más grande y admitido se define como MAX_PAGECACHE_ORDER mediante el commit 099d90642a71 ("mm/filemap: hacer que MAX_PAGECACHE_ORDER sea aceptable para xarray"). Sin embargo, es posible tener una caché de página de 512 MB en la ruta de colapso de la enorme memoria en un sistema ARM64 cuyo tamaño de página base es de 64 KB. La caché de página de 512 MB supera la limitación y aparece una advertencia cuando la entrada de xarray se divide como se muestra en el siguiente ejemplo. [root@dhcp-10-26-1-207 ~]# cat /proc/1/smaps | grep KernelPageSize KernelPageSize: 64 kB [root@dhcp-10-26-1-207 ~]# cat /tmp/test.c : int main(int argc, char **argv) { const char *filename = TEST_XFS_FILENAME; intfd = 0; vacío *buf = (vacío *)-1, *p; int pgsize = getpagesize(); int ret = 0; if (pgsize != 0x10000) { fprintf(stdout, "¡Se requiere un sistema con un tamaño de página base de 64 KB!\n"); devolver -EPERM; } system("echo 0 > /sys/devices/virtual/bdi/253:0/read_ahead_kb"); sistema("echo 1 > /proc/sys/vm/drop_caches"); /* Abrir el archivo xfs */ fd = open(nombre de archivo, O_RDONLY); afirmar(fd > 0); /* Crear VMA */ buf = mmap(NULL, TEST_MEM_SIZE, PROT_READ, MAP_SHARED, fd, 0); afirmar(buf != (void *)-1); fprintf(stdout, "búfer asignado en 0x%p\n", buf); /* Completar VMA */ ret = madvise(buf, TEST_MEM_SIZE, MADV_NOHUGEPAGE); afirmar(ret == 0); ret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_READ); afirmar(ret == 0); /* Contraer VMA */ ret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE); afirmar(ret == 0); ret = madvise(buf, TEST_MEM_SIZE, MADV_COLLAPSE); if (ret) { fprintf(stdout, "Error %d en madvise(MADV_COLLAPSE)\n", errno); salir; } /* Dividir entrada de matriz x. Se necesita permiso de escritura */ munmap(buf, TEST_MEM_SIZE); buf = (nulo *)-1; cerrar(fd); fd = open(nombre de archivo, O_RDWR); afirmar(fd > 0); fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE, TEST_MEM_SIZE - tamaño de página, tamaño de página); salida: if (buf != (void *)-1) munmap(buf, TEST_MEM_SIZE); si (fd > 0) cerrar(fd); volver atrás; } [root@dhcp-10-26-1-207 ~]# gcc /tmp/test.c -o /tmp/test [root@dhcp-10-26-1-207 ~]# /tmp/test -- ----------[ cortar aquí ]------------ ADVERTENCIA: CPU: 25 PID: 7560 en lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Módulos vinculados en : nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \ nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \ nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \ _set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse \ xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 virtio_net \ sha1_ce net_failover virtio_blk virtio_console failover dimlib virtio_mmio CPU: 25 PID: 7560 Comm : prueba Kdump: cargado No contaminado 6.10.0-rc7-gavin+ #9 Nombre del hardware: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 24/05/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO + DIT -SSBS BTYPE=--) pc: xas_split_alloc+0xf8/0x128 lr: split_huge_page_to_list_to_order+0x1c4/0x780 sp: ffff8000ac32f660 x29: ffff8000ac32f660 x28: ffff0000e0969eb0 x27: 000ac32f6c0 x26: 0000000000000c40 x25: ffff0000e0969eb0 x24: 000000000000000d x23: ffff8000ac32f6c0 x22: ffffffdfc0700000 x21 : 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0700000 x18: 0000000000000000 x17: 0000000000000000 x16: ffffd5f3708ffc70 x15: 000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: ffffffffffffffc0 x10: 0000000000000040 x9: 08e692c x8: 0000000000000003 x7: 0000000000000000 x6: ffff0000e0969eb8 x5: ffffd5f37289e378 x4: 0000000000000000 x3: 0000000000000c40 x2: 000000000000000d x1: 000000000000000c x0: 0000000000000000 Rastreo de llamadas: xas_split_alloc+0xf8/0x128 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: landlock: no pierda de vista las restricciones en cred_transfer Cuando se reemplaza la estructura cred de un proceso, esto _almost_ always invoca el gancho LSM cred_prepare; pero en un caso especial (cuando KEYCTL_SESSION_TO_PARENT actualiza las credenciales de los padres), se utiliza el gancho LSM cred_transfer. Landlock solo implementa el gancho cred_prepare, no cred_transfer, por lo que KEYCTL_SESSION_TO_PARENT hace que se pierda toda la información sobre las restricciones de Landlock. Básicamente, esto significa que un proceso con la capacidad de utilizar las llamadas al sistema fork() y keyctl() puede deshacerse de todas las restricciones de Landlock sobre sí mismo. Solucionelo agregando un gancho cred_transfer que haga lo mismo que el gancho cred_prepare existente. (Se implementa haciendo que hook_cred_prepare() llame a hook_cred_transfer() para que sea menos probable que las dos funciones diverjan accidentalmente en el futuro).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: buzón: mtk-cmdq: mover devm_mbox_controller_register() después de devm_pm_runtime_enable() Cuando mtk-cmdq se desvincula, aparece un mensaje WARN_ON con la condición pm_runtime_get_sync() < 0. De acuerdo con el seguimiento de llamadas a continuación: cmdq_mbox_shutdown mbox_free_channel mbox_controller_unregister __devm_mbox_controller_unregister ... Se puede deducir que la causa raíz es llamar a pm_runtime_get_sync() después de llamar a pm_runtime_disable() como se observa a continuación: 1. El controlador CMDQ usa devm_mbox_controller_register() en cmdq_probe() para vincular el cmdq al mbox_controller, por lo que devm_mbox_controller_unregister() cancelará automáticamente el registro del dispositivo vinculado al controlador del buzón cuando se elimine el recurso administrado por el dispositivo. Eso significa que devm_mbox_controller_unregister() y cmdq_mbox_shoutdown() serán llamados después de cmdq_remove(). 2. El controlador CMDQ también usa devm_pm_runtime_enable() en cmdq_probe() después de devm_mbox_controller_register(), por lo que se llamará a devm_pm_runtime_disable() después de cmdq_remove(), pero antes de devm_mbox_controller_unregister(). Para solucionar este problema, cmdq_probe() necesita mover devm_mbox_controller_register() después de devm_pm_runtime_enable() para que se llame a devm_pm_runtime_disable() después de devm_mbox_controller_unregister().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/dasd: corrige comprobaciones de errores en dasd_copy_pair_store() dasd_add_busid() puede devolver un error a través de ERR_PTR() si falla una asignación. Sin embargo, dos sitios de llamada en dasd_copy_pair_store() no verifican el resultado, lo que podría provocar una desreferencia del puntero NULL. Solucione este problema verificando el resultado con IS_ERR() y devolviendo el error en la pila.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: flow_dissector: use DEBUG_NET_WARN_ON_ONCE El siguiente símbolo es fácil de reproducir tanto en núcleos anteriores como en núcleos estables. Florian Westphal proporcionó la siguiente confirmación: d1dab4f71d37 ("net: add and use __skb_get_hash_metric_net") pero Willem de Bruijn también sugirió esta solución complementaria y se puede retroportar fácilmente al kernel estable, que consiste en usar DEBUG_NET_WARN_ON_ONCE en lugar de silenciar lo siguiente splat dado __skb_get_hash() es utilizado por la infraestructura de seguimiento de nftables para identificar paquetes en los seguimientos. [69133.561393] ------------[ cortar aquí ]------------ [69133.561404] ADVERTENCIA: CPU: 0 PID: 43576 en net/core/flow_dissector.c :1104 __skb_flow_dissect+0x134f/ [...] [69133.561944] CPU: 0 PID: 43576 Comm: socat No contaminado 6.10.0-rc7+ #379 [69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0 133.561970] Código: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ff ff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff <0f> 0b e9 20 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8 [69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246 [69133.561988] RAX: 00000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19 [69133.561994] RDX: dffffc0000000000 RSI: ffffc900000007388 RDI: ffff888103a1b418 [69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000 [69133.562007] R10: ffffc90000007388 R11: fffffff810cface 2: ffff888103a1b400 [69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28 [69133.562020] FS: 00007f40f7131740(000 0) GS:ffff888390800000(0000 ) knlGS:0000000000000000 [69133.562027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [69133.562033] CR2: 00007f40f7346ee0 CR3: 5d200001 CR4: 00000000001706f0 [69133.562040] Seguimiento de llamadas: [69133.562044] [69133.562049] ? __advertir+0x9f/0x1a0 [ 1211.841384] ? __skb_flow_dissect+0x107e/0x2860 [...] [ 1211.841496] ? bpf_flow_dissect+0x160/0x160 [ 1211.841753] __skb_get_hash+0x97/0x280 [ 1211.841765] ? __skb_get_hash_metric+0x230/0x230 [1211.841776]? mod_find+0xbf/0xe0 [1211.841786]? get_stack_info_noinstr+0x12/0xe0 [1211.841798]? bpf_ksym_find+0x56/0xe0 [1211.841807]? __rcu_read_unlock+0x2a/0x70 [1211.841819] nft_trace_init+0x1b9/0x1c0 [nf_tables] [1211.841895]? nft_trace_notify+0x830/0x830 [nf_tables] [1211.841964]? get_stack_info+0x2b/0x80 [1211.841975]? nft_do_chain_arp+0x80/0x80 [nf_tables] [ 1211.842044] nft_do_chain+0x79c/0x850 [nf_tables]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipvs: desreferenciar correctamente pe en ip_vs_add_service Utilice pe directamente para resolver la advertencia dispersa: net/netfilter/ipvs/ip_vs_ctl.c:1471:27: advertencia: desreferencia de la expresión noderef

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: maneja el estado inconsistente en nilfs_btnode_create_block() Syzbot informó que se detectó una inconsistencia en el estado del búfer en nilfs_btnode_create_block(), lo que provocó un error en el kernel. No es apropiado tratar esta inconsistencia como un error; puede ocurrir si la dirección del bloque de argumentos (el índice del búfer del bloque recién creado) es un número de bloque virtual y se ha reasignado debido a la corrupción del mapa de bits utilizado para administrar su estado de asignación. Por lo tanto, modifique nilfs_btnode_create_block() y sus llamadores para tratarlo como un posible error del sistema de archivos, en lugar de desencadenar un error del kernel.