Vulnerabilidades

IBM OpenPages con Watson 8.3 y 9.0 podría permitir que un usuario autenticado obtenga información confidencial que sólo debería estar disponible para usuarios privilegiados.

mcp-remote está expuesto a la inyección de comandos del sistema operativo cuando se conecta a servidores MCP no confiables debido a una entrada manipulada desde la URL de respuesta de autorización_endpoint

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/damon/sysfs-schemes: la liberación de la antigua ruta damon_sysfs_scheme_filter->memcg_path al escribir en memcg_path_store() asigna un búfer de memoria recién asignado a filter->memcg_path, sin liberar el búfer de memoria previamente asignado. Como resultado, los usuarios pueden perder memoria del kernel escribiendo continuamente datos en el archivo sysfs de DAMOS, memcg_path. Para solucionar la pérdida, libere el búfer de memoria previamente asignado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-tcp: desinfectar el manejo de la lista de solicitudes Valide la solicitud en nvme_tcp_handle_r2t() para asegurarse de que no sea parte de ninguna lista; de lo contrario, una PDU R2T maliciosa podría inyectar un bucle en el procesamiento de la lista de solicitudes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: guardar el estado SR_SUM durante los cambios Cuando se cambian los subprocesos o las tareas, debemos asegurarnos de que se guarde el estado SR_SUM de la ejecución anterior y que el nuevo subproceso tenga el estado SR_SUM anterior restaurado. El problema se observó bajo carga pesada, especialmente con la herramienta syz-stress ejecutándose, con fallos como los siguientes en schedule_tail: No se puede manejar el acceso del kernel a la memoria del usuario sin rutinas uaccess en la dirección virtual 000000002749f0d0 Oops [#1] Módulos vinculados: CPU: 1 PID: 4875 Comm: syz-executor.0 No contaminado 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0 Nombre del hardware: riscv-virtio,qemu (DT) epc : schedule_tail+0x72/0xb2 kernel/sched/core.c:4264 ra : task_pid_vnr include/linux/sched.h:1421 [inline] ra : schedule_tail+0x70/0xb2 kernel/sched/core.c:4264 epc: ffffffe00008c8b0 ra: ffffffe00008c8ae sp: ffffffe025d17ec0 gp: ffffffe005d25378 tp: ffffffe00f0d0000 t0: 0000000000000000 t1: 0000000000000001 t2: 00000000000f4240 s0: ffffffe025d17ee0 s1: 000000002749f0d0 a0: 00000000000002a a1: 000000000000003 a2: 1ffffffc0cfac500 a3: ffffffe0000c80cc a4: 5ae9db91c19bbe00 a5: 0000000000000000 a6: 0000000000f00000 a7: ffffffe000082eba s2: 0000000000040000 s3: ffffffe00eef96c0 s4: ffffffe022c77fe0 s5: 0000000000004000 s6: ffffffe067d74e00 s7: ffffffe067d74850 s8: ffffffe067d73e18 s9: ffffffe067d74e00 s10: ffffffe00eef96e8 s11: 000000ae6cdf8368 t3 : 5ae9db91c19bbe00 t4 : ffffffc4043cafb2 t5 : ffffffc4043cafba t6 : 0000000000040000 estado: 0000000000000120 dirección incorrecta: 000000002749f0d0 causa: 000000000000000f Seguimiento de llamadas: [] schedule_tail+0x72/0xb2 kernel/sched/core.c:4264 [] ret_from_exception+0x0/0x14 Volcando buffer ftrace: (ftrace buffer vacío) ---[ fin de seguimiento b5f8f9231dc87dda ]--- El problema proviene de put_user() en schedule_tail (kernel/sched/core.c) que hace lo siguiente: asmlinkage __visible void schedule_tail(struct task_struct *prev) { ... if (current->set_child_tid) put_user(task_pid_vnr(current), current->set_child_tid); ... } la macro put_user() hace que la secuencia de código salga de la siguiente manera: 1: __enable_user_access() 2: reg = task_pid_vnr(current); 3: *current->set_child_tid = reg; 4: __disable_user_access(). El problema radica en que podríamos tener una función inactiva como argumento que podría borrar SR_SUM, causando el pánico mencionado. Esto se solucionó evaluando el argumento de la macro put_user() fuera de la sección habilitada por el usuario en el commit 285a76bb2cf5 ("riscv: evaluar el argumento put_user() antes de habilitar el acceso del usuario"). Para que riscv aproveche las macros unsafe_get/put_XXX() y evite el mismo problema que tuvimos con put_user() y las funciones inactivas, debemos asegurar que el flujo de código pueda pasar por switch_to() desde una región de código con SR_SUM habilitado y regresar con SR_SUM aún habilitado. Este parche soluciona el problema, lo que permitirá que en trabajos futuros se habilite el uso completo de las macros unsafe_get/put_XXX() sin necesidad de aplicar un coste de cambio de bit CSR en cada acceso. Haga que switch_to() guarde y restaure SR_SUM.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: arregla el puntero NULL en cache_set_flush() 1. LÍNEA#1794 - LÍNEA#1887 son algunos códigos sobre la función de bch_cache_set_alloc(). 2. LÍNEA#2078 - LÍNEA#2142 son algunos códigos sobre la función de register_cache_set(). 3. register_cache_set() llamará a bch_cache_set_alloc() en la LÍNEA#2098. 1794 estructura caché_set *bch_cache_set_alloc(estructura caché_sb *sb) 1795 { ... 1860 si (!(c->dispositivos = kcalloc(c->nr_uuids, tamaño de(void *), GFP_KERNEL)) || 1861 mempool_init_slab_pool(&c->búsqueda, 32, bch_búsqueda_cache) || 1862 mempool_init_kmalloc_pool(&c->bio_meta, 2, 1863 tamaño de(estructura bbio) + tamaño de(estructura bio_vec) * 1864 páginas_de_depósito(c)) || 1865 mempool_init_kmalloc_pool(&c->rellenar_iter, 1, tamaño_de_iter) || 1866 bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio), 1867 BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) || 1868 !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) || 1869 !(c->moving_gc_wq = alloc_workqueue("bcache_gc", 1870 WQ_MEM_RECLAIM, 0)) || 1871 bch_journal_alloc(c) || 1872 bch_btree_cache_alloc(c) || 1873 bch_open_buckets_alloc(c) || 1874 bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages))) 1875 goto err; ^^^^^^^^ 1876 ... 1883 devolver c; 1884 err: 1885 bch_cache_set_unregister(c); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1886 devolver NULL; 1887 } ... 2078 static const char *register_cache_set(struct cache *ca) 2079 { ... 2098 c = bch_cache_set_alloc(&ca->sb); 2099 if (!c) 2100 devolver err; ^^^^^^^^^^ ... 2128 ca->set = c; 2129 ca->set->cache[ca->sb.nr_this_dev] = ca; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... 2138 return NULL; 2139 err: 2140 bch_cache_set_unregister(c); 2141 return err; 2142 } (1) Si LÍNEA#1860 - LÍNEA#1874 es verdadero, entonces haga 'goto err'(LÍNEA#1875) y llame a bch_cache_set_unregister()(LÍNEA#1885). (2) Como (1) devuelve NULL(LÍNEA#1886), LÍNEA#2098 - LÍNEA#2100 retornaría. (3) Como (2) ha retornado, la LÍNEA n.º 2128 - LÍNEA n.º 2129 *no* daría el valor a c->cache[], lo que significa que c->cache[] es NULL. LA LÍNEA n.º 1624 - LÍNEA n.º 1665 son algunos códigos sobre la función de cache_set_flush(). Como (1), en la LÍNEA n.º 1885 llame a bch_cache_set_unregister() ---> bch_cache_set_stop() ---> closure_queue() -.-> cache_set_flush() (como se muestra a continuación en la LÍNEA n.º 1624) 1624 static void cache_set_flush(struct closure *cl) 1625 { ... 1654 for_each_cache(ca, c, i) 1655 if (ca->alloc_thread) ^^ 1656 kthread_stop(ca->alloc_thread); ... 1665 } (4) En la LÍNEA n.º 1655 ca es NULL (ver (3)) en cache_set_flush(), entonces ocurrió el fallo del núcleo como se muestra a continuación: [846.712887] bcache: error de register_cache() drbd6: no se puede asignar memoria [846.713242] bcache: error de register_bcache(): no se pudo registrar el dispositivo [846.713336] bcache: cache_set_free() Conjunto de caché 2f84bdc1-498a-4f2f-98a7-01946bf54287 no registrado [846.713768] ERROR: no se puede manejar la desreferencia del puntero NULL del núcleo en 00000000000009f8 [846.714790] PGD 0 P4D 0 [ 846.715129] Oops: 0000 [#1] SMP PTI [ 846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: cargado Contaminado: G OE --------- - - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1 [ 846.716082] Nombre del hardware: ESPAN GI-25212/X11DPL-i, BIOS 2.1 15/06/2018 [ 846.716451] Cola de trabajo: eventos cache_set_flush [bcache] [ 846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache] [ 846.717155] Código: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 0 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: serial: uartlite: registrar el controlador UART en init. Cuando dos instancias de dispositivos UART están realizando pruebas, puede producirse una ejecución de concurrencia. Si un subproceso invoca la función uart_register_driver, que primero asigna memoria al miembro 'uart_state' de la estructura uart_driver, la otra instancia puede omitir el registro del controlador UART y llamar a ulite_assign. Esto invoca uart_add_one_port, que espera que el controlador UART esté completamente inicializado. Esto genera un pánico del kernel debido a una desreferencia de puntero nulo: [8.143581] ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000002b8 [8.156982] #PF: acceso de escritura del supervisor en modo kernel [8.156984] #PF: error_code(0x0002) - página no presente [8.156986] PGD 0 P4D 0 ... [8.180668] RIP: 0010:mutex_lock+0x19/0x30 [8.188624] Rastreo de llamadas: [ 8.188629] ? __die_body.cold+0x1a/0x1f [ 8.195260] ? page_fault_oops+0x15c/0x290 [ 8.209183] ? __irq_resolve_mapping+0x47/0x80 [ 8.209187] ? exc_page_fault+0x64/0x140 [ 8.209190] ? asm_exc_page_fault+0x22/0x30 [ 8.209196] ? mutex_lock+0x19/0x30 [ 8.223116] uart_add_one_port+0x60/0x440 [ 8.223122] ? proc_tty_register_driver+0x43/0x50 [ 8.223126] ? tty_register_driver+0x1ca/0x1e0 [ 8.246250] ulite_probe+0x357/0x4b0 [uartlite] Para evitarlo, mueva el registro del controlador UART a la función init. Esto garantizará que uart_driver siempre se registre al llamar a la función de sondeo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: manejar correctamente el error del árbol csum con rescue=ibadroots [ERROR] Hay un reproductor basado en syzbot que puede hacer caer el kernel, con el siguiente seguimiento de llamada: (Con alguna salida de depuración agregada) DEBUG: rescue=ibadroots analizó BTRFS: dispositivo fsid 14d642db-7b15-43e4-81e6-4b8fac6a25f8 devid 1 transid 8 /dev/loop0 (7:0) escaneado por repro (1010) Información de BTRFS (dispositivo loop0): primer montaje del sistema de archivos 14d642db-7b15-43e4-81e6-4b8fac6a25f8 Información de BTRFS (dispositivo loop0): usando el algoritmo de suma de comprobación blake2b (blake2b-256-generic) Información de BTRFS (dispositivo loop0): usando el algoritmo de suma de comprobación blake2b (blake2b-256-generic) Advertencia de BTRFS de árbol de espacio libre (dispositivo loop0): la verificación de suma de comprobación falló en el espejo lógico 5312512 1 deseado 0xb043382657aede36608fd3386d6b001692ff406164733d94e2d9a180412c6003 encontrado 0x810ceb2bacb7f0f9eb2bf3b2b15c02af867cb35ad450898169f3b1f0bd818651 nivel 0 DEBUG: la lectura de la ruta raíz del árbol falló para el csum del árbol, ret=-5 Advertencia de BTRFS (dispositivo loop0): la verificación de suma de comprobación falló en el espejo lógico 5328896 1 deseado Se encontró 0x51be4e8b303da58e6340226815b70e3a93592dac3f30dd510c7517454de8567a. Advertencia BTRFS de nivel 0 (bucle de dispositivo 0): la verificación de suma de comprobación falló en el espejo lógico 5292032 deseado 1. Se encontró 0x1924ccd683be9efc2fa98582ef58760e3848e9043db8649ee382681e220cdee4. 0x0cb6184f6e8799d9f8cb335dccd1d1832da1071d12290dab3b85b587ecacca6e proceso de nivel 0 'repro' lanzado './file2' con NULL argv: cadena vacía agregada DEBUG: sin raíz csum, idatacsums=0 ibadroots=134217728 Oops: error de protección general, probablemente para dirección no canónica 0xdffffc0000000041: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x0000000000000208-0x000000000000020f] CPU: 5 UID: 0 PID: 1010 Comm: repro Tainted: G OE 6.15.0-custom+ #249 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfs_lookup_csum+0x93/0x3d0 [btrfs] Call Trace: btrfs_lookup_bio_sums+0x47a/0xdf0 [btrfs] btrfs_submit_bbio+0x43e/0x1a80 [btrfs] submit_one_bio+0xde/0x160 [btrfs] btrfs_readahead+0x498/0x6a0 [btrfs] read_pages+0x1c3/0xb20 page_cache_ra_order+0x4b5/0xc20 filemap_get_pages+0x2d3/0x19e0 filemap_read+0x314/0xde0 __kernel_read+0x35b/0x900 bprm_execve+0x62e/0x1140 do_execveat_common.isra.0+0x3fc/0x520 __x64_sys_execveat+0xdc/0x130 do_syscall_64+0x54/0x1d0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[ end trace 0000000000000000 ]--- [CAUSE] En primer lugar, el sistema de archivos tiene una raíz de árbol csum dañada, por lo tanto, para montar el sistema de archivos tenemos que usar la opción de montaje "ro,rescue=ibadroots". Normalmente, con esa opción de montaje, una raíz de árbol de sumas de confianza incorrecta debería activar la bandera BTRFS_FS_STATE_NO_DATA_CSUMS, de modo que cualquier lectura de datos futura ignore la búsqueda de sumas de confianza. Sin embargo, en este caso particular, tenemos el siguiente seguimiento de llamada que generó una raíz de sumas de confianza nula, pero no activó BTRFS_FS_STATE_NO_DATA_CSUMS: load_global_roots_objectid(): ret = btrfs_search_slot(); /* Correcto */ btrfs_item_key_to_cpu() found = true; /* Se encontró el elemento raíz del árbol de sumas de confianza. */ root = read_tree_root_path(); if (IS_ERR(root)) { if (!btrfs_test_opt(fs_info, IGNOREBADROOTS)) /* * Dado que tenemos la opción de montaje rescue=ibadroots, * @ret sigue siendo 0. */ break; if (!found || ret) { /* @found es verdadero, @ret es 0, se omite el manejo de errores del árbol de sumas de csuma. */ } Esto significa que omitimos completamente la configuración de BTRFS_FS_STATE_NO_DATA_CSUMS si el árbol de sumas de csuma está dañado, lo que resulta en una búsqueda posterior inesperada --- truncado ---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: códecs: wcd9335: Se corrige la falta de liberación de suministros del regulador. El controlador obtiene y habilita todos los suministros del regulador en la ruta de sondeo (wcd9335_parse_dt() y wcd9335_power_on_reset()), pero no realiza la limpieza en las rutas de error finales ni en la desvinculación (falta la devolución de llamada remove()). Esto provoca fugas de memoria y un recuento desequilibrado de habilitaciones del regulador durante los errores de sondeo o la desvinculación. Para solucionar esto, convierta todo el código a devm_regulator_bulk_get_enable(), lo que también simplifica considerablemente el código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/rsrc: se corrige la desanclaje de folio. syzbot se queja de un error de desasignación: [ 108.070381][ T14] ¡ERROR del kernel en mm/gup.c:71! [ 108.070502][ T14] Error interno: Ups - ERROR: 00000000f2000800 [#1] SMP [ 108.123672][ T14] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250221-8.fc42 02/21/2025 [ 108.127458][ T14] Workqueue: iou_exit io_ring_exit_work [ 108.174205][ T14] Call trace: [ 108.175649][ T14] sanity_check_pinned_pages+0x7cc/0x7d0 (P) [ 108.178138][ T14] unpin_user_page+0x80/0x10c [ 108.180189][ T14] io_release_ubuf+0x84/0xf8 [ 108.182196][ T14] io_free_rsrc_node+0x250/0x57c [ 108.184345][ T14] io_rsrc_data_free+0x148/0x298 [ 108.186493][ T14] io_sqe_buffers_unregister+0x84/0xa0 [ 108.188991][ T14] io_ring_ctx_free+0x48/0x480 [ 108.191057][ T14] io_ring_exit_work+0x764/0x7d8 [ 108.193207][ T14] process_one_work+0x7e8/0x155c [ 108.195431][ T14] worker_thread+0x958/0xed8 [ 108.197561][ T14] kthread+0x5fc/0x75c [ 108.199362][ T14] ret_from_fork+0x10/0x20 Podemos anclar la página final de un folio, pero entonces io_uring intentará desanclar la página principal. Si bien esto debería funcionar correctamente para mantener la página activa, los usuarios de mm indican que es incorrecto y genera una advertencia de depuración. Use unpin_user_folio() en lugar de unpin_user_page*. [axboe: adaptar al árbol actual, modificar el mensaje de confirmación]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: lib/group_cpus: corrección de la desreferencia de puntero NULL de group_cpus_evenly() Al probar null_blk con configfs, echo 0 > poll_queues activará el siguiente pánico: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000010 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 27 UID: 0 PID: 920 Comm: bash No contaminado 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef) Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__bitmap_or+0x48/0x70 Rastreo de llamadas: __group_cpus_evenly+0x822/0x8c0 group_cpus_evenly+0x2d9/0x490 blk_mq_map_queues+0x1e/0x110 null_map_queues+0xc9/0x170 [null_blk] blk_mq_update_queue_map+0xdb/0x160 blk_mq_update_nr_hw_queues+0x22b/0x560 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_poll_queues_store+0xa4/0x130 [null_blk] configfs_write_iter+0x109/0x1d0 vfs_write+0x26e/0x6f0 ksys_write+0x79/0x180 __x64_sys_write+0x1d/0x30 x64_sys_call+0x45c4/0x45f0 do_syscall_64+0xa5/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7e La causa principal es que numgrps está establecido en 0 y se devuelve ZERO_SIZE_PTR desde kcalloc(); posteriormente, se aplicará ZERO_SIZE_PTR. Solucione el problema comprobando primero numgrps en group_cpus_evenly() y devolviendo NULL directamente si numgrps es cero. [yukuai3@huawei.com: corrija también la versión sin SMP]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se han añadido comprobaciones de seguridad para drm_edid_raw(). Cuando se recupera el EDID mediante drm_edid_raw(), no se garantiza la devolución de los bytes de EDID correctos que el usuario solicita: puede ser nulo (lo que provoca un error) o con bytes demasiado largos que exceden el tamaño fijo de la matriz raw_edid (lo que puede provocar corrupción de memoria). Esto último se informó al conectar con un adaptador defectuoso. Se han añadido comprobaciones de seguridad para drm_edid_raw() para abordar los casos especiales mencionados y devolver EDID_BAD_INPUT en consecuencia. (Seleccionado del commit 648d3f4d209725d51900d6a3ed46b7b600140cdf)