Vulnerabilidades

Flags SDK es un kit de herramientas de código abierto para Next.js y SvelteKit. Las versiones afectadas incluyen flags de la versión 3.2.0 y anteriores, y @vercel/flags de la versión 3.1.1 y anteriores, ya que, en determinadas circunstancias, un atacante con conocimiento detallado de la vulnerabilidad puede listar todos los flags devueltos por el endpoint de descubrimiento de flags (.well-known/vercel/flags). Esta vulnerabilidad permite la divulgación de información, lo que permite a un atacante acceder a una lista de todos los flags de características expuestos a través del endpoint de descubrimiento de flags, incluyendo los nombres y descripciones de los flags, las opciones disponibles y sus etiquetas (p. ej., verdadero, falso) y los valores predeterminados de los flags. Este problema se ha corregido en flags@4.0.0; los usuarios de flags y @vercel/flags también deben migrar a flags@4.0.0.

El método de autenticación de Azure de Vault Community, Vault Enterprise ("Vault") no validaba correctamente las notificaciones en el token emitido por Azure, lo que podía provocar la omisión del parámetro bound_locations al iniciar sesión. Corregido en Vault Community Edition 1.19.1 y Vault Enterprise 1.19.1, 1.18.7, 1.17.14 y 1.16.18.

Se detectó una vulnerabilidad crítica en Casdoor hasta la versión 1.811.0. Esta vulnerabilidad afecta la función HandleScim del archivo controllers/scim.go del componente SCIM User Creation Endpoint. La manipulación permite la omisión de la autorización. El ataque puede iniciarse remotamente. Actualizar a la versión 1.812.0 puede solucionar este problema. El parche se llama 3d12ac8dc2282369296c3386815c00a06c6a92fe. Se recomienda actualizar el componente afectado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: corrige kunmap incorrecto al usar LZMA en plataformas HIGHMEM Como lo muestra el seguimiento de llamadas, la causa raíz son páginas incorrectas de kunmap: ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000 CPU: 1 PID: 40 Comm: kworker/u5:0 No contaminado 6.2.0-rc5 #4 Cola de trabajo: erofs_worker z_erofs_decompressqueue_work EIP: z_erofs_lzma_decompress+0x34b/0x8ac z_erofs_decompress+0x12/0x14 z_erofs_decompress_queue+0x7e7/0xb1c z_erofs_decompressqueue_work+0x32/0x60 process_one_work+0x24b/0x4d8 ? process_one_work+0x1a4/0x4d8, work_thread+0x14c/0x3fc, kthread+0xe6/0x10c, rescuer_thread+0x358/0x358, kthread_complete_and_exit+0x18/0x18, ret_from_fork+0x1c/0x28 ---[ fin del seguimiento 000000000000000 ]--- El error es trivial y debería estar corregido. No afecta a las plataformas !HIGHMEM.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrige otro error de fsmap de un bloque en sistemas de archivos de 1k Aparentemente, syzbot descubrió que emitir esta llamada FSMAP: Produce este fallo si el sistema de archivos subyacente es un sistema de archivos ext4 de 1k bloques: ¡ERROR del kernel en fs/ext4/ext4.h:3331! Código de operación no válido: 0000 [#1] PREEMPT SMP CPU: 3 PID: 3227965 Comm: xfs_io Contaminado: GWO 6.2.0-rc8-achx Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 01/04/2014 RIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4] RSP: 0018:ffffc90007c03998 EFLAGS: 00010246 RAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000 RDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11 RBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400 R10: ffffc90007c03950 R11: 0000000000000000 R12: 000000000000001 R13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398 FS: 00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0 Rastreo de llamadas: ext4_mballoc_query_range+0x4b/0x210 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_getfsmap_datadev+0x713/0x890 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_getfsmap+0x2b7/0x330 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_ioc_getfsmap+0x153/0x2b0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] __ext4_ioctl+0x2a7/0x17e0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] __x64_sys_ioctl+0x82/0xa0 hacer_llamada_al_sistema_64+0x2b/0x80 entrada_LLAMADA_AL_SISTEMA_64_después_de_hwframe+0x46/0xb0 RIP: 0033:0x7fdf20558aff RSP: 002b:00007ffd318a9e30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000000200c0 RCX: 00007fdf20558aff RDX: 00007fdf1feb2010 RSI: 00000000c0c0583b RDI: 0000000000000003 RBP: 00005625c0634be0 R08: 00005625c0634c40 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fdf1feb2010 R13: 00005625be70d994 R14: 000000000000800 R15: 000000000000000 Para las llamadas GETFSMAP, el llamador selecciona un dispositivo de bloque físico escribiendo su número de bloque en fsmap_head.fmh_keys[01].fmr_device. Para consultar las asignaciones de un subrango del dispositivo, el byte inicial del rango se escribe en fsmap_head.fmh_keys[0].fmr_physical y el último byte en fsmap_head.fmh_keys[1].fmr_physical. IOWs, para consultar qué asignaciones se superponen con los bytes 3-14 de /dev/sda, debe configurar las entradas de la siguiente manera: fmh_keys[0] = { .fmr_device = major(8, 0), .fmr_physical = 3}, fmh_keys[1] = { .fmr_device = major(8, 0), .fmr_physical = 14}, lo que le devolvería lo que esté asignado en los 12 bytes a partir del desplazamiento físico 3. El fallo se debe a una validación de rango insuficiente de keys[1] en ext4_getfsmap_datadev. En sistemas de archivos de 1k bloques, el bloque 0 no forma parte del sistema de archivos, lo que significa que s_first_data_block es distinto de cero. ext4_get_group_no_and_offset resta esta cantidad del argumento blocknr antes de descomponerlo en un número de grupo y un número de bloque dentro de un grupo. En las IOW, el grupo de bloques 0 abarca los bloques 1-8192 (basado en 1) en lugar de 0-8191 (basado en 0), como ocurre con tamaños de bloque mayores. El resultado final de esta codificación es que blocknr < s_first_data_block no es una entrada válida para esta función. La variable end_fsb se establece a partir de las claves copiadas del espacio de usuario, lo que significa que, en el ejemplo anterior, su valor es cero. Esto genera un desbordamiento por debajo de la capacidad: blocknr = blocknr - le32_to_cpu(es->s_first_data_block); La división opera entonces sobre -1: offset = do_div(blocknr, EXT4_BLOCKS_PER_GROUP(sb)) >> EXT4_SB(sb)->s_cluster_bits; De esta manera, se deja un número de grupo imposiblemente grande (2^32-1) en blocknr. ext4_getfsmap_check_keys verificó que keys[0 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: se omite la copia del último bloque en ice_get_module_eeprom(). ice_get_module_eeprom() no funciona desde el commit e9c9692c8a81 ("ice: Reimplementar las lecturas del módulo utilizadas por ethtool"). En esta refactorización, ice_get_module_eeprom() lee la EEPROM en bloques de tamaño 8. Sin embargo, la condición que debería proteger contra el desbordamiento del búfer ignora el último bloque. Este último bloque siempre contiene ceros. Error descubierto por el commit upstream de ethtool 9538f384b535 ("netlink: eeprom: Aplazar las solicitudes de página a analizadores individuales"). Después de esta confirmación, ethtool lee un bloque con longitud = 1; para leer el valor del identificador SFF-8024. controlador sin parchear: $ ethtool -m enp65s0f0np0 offset 0x90 length 8 Valores de desplazamiento ------ ------ 0x0090: 00 00 00 00 00 00 00 00 $ ethtool -m enp65s0f0np0 offset 0x90 length 12 Valores de desplazamiento ------ ------ 0x0090: 00 00 01 a0 4d 65 6c 6c 00 00 00 00 $ $ ethtool -m enp65s0f0np0 Valores de desplazamiento ------ ------ 0x0000: 11 06 06 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 01 08 00 0x0070: 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 controlador parcheado: $ ethtool -m enp65s0f0np0 offset 0x90 length 8 Valores de desplazamiento ------ ------ 0x0090: 00 00 01 a0 4d 65 6c 6c $ ethtool -m enp65s0f0np0 offset 0x90 length 12 Valores de desplazamiento ------ ------ 0x0090: 00 00 01 a0 4d 65 6c 6c 61 6e 6f 78 $ ethtool -m enp65s0f0np0 Identificador: 0x11 (QSFP28) Identificador extendido: 0x00 Descripción del identificador extendido: 1,5 W máx. Consumo de energía Descripción extendida del identificador: Sin CDR en TX, Sin CDR en RX Descripción extendida del identificador: Clase de alta potencia (> 3,5 W) no habilitada Conector: 0x23 (sin conector separable) Códigos del transceptor: 0x88 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Tipo de transceptor: Ethernet de 40 G: Base-CR4 de 40 G Tipo de transceptor: Ethernet de 25 G: Base-CR de 25 G Codificación CA-N: 0x05 (64B/66B) BR, nominal: 25500 Mbps Identificador de velocidad: 0x00 Longitud (SMF, km): 0 km Longitud (OM3 50 um): 0 m Longitud (OM2 50 um): 0 m Longitud (OM1 62,5 um): 0 m Longitud (cobre o cable activo): 1m Tecnología del transmisor: 0xa0 (cable de cobre sin ecualizar) Atenuación a 2,5 GHz: 4 db Atenuación a 5,0 GHz: 5 db Atenuación a 7,0 GHz: 7 db Atenuación a 12,9 GHz: 10 db ........ ....

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ila: no generar mensajes vacíos en ila_xlat_nl_cmd_get_mapping(). ila_xlat_nl_cmd_get_mapping() genera un skb vacío, lo que activa una comprobación de integridad reciente [1]. En su lugar, devuelve un código de error para que el espacio de usuario pueda obtenerlo. [1] skb_assert_len ADVERTENCIA: CPU: 0 PID: 5923 en include/linux/skbuff.h:2527 skb_assert_len include/linux/skbuff.h:2527 [en línea] ADVERTENCIA: CPU: 0 PID: 5923 en include/linux/skbuff.h:2527 __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156 Módulos vinculados: CPU: 0 PID: 5923 Comm: syz-executor269 No contaminado 6.2.0-syzkaller-18300-g2ebd1fbb946d #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 21/01/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_assert_len include/linux/skbuff.h:2527 [en línea] pc : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156 lr : skb_assert_len include/linux/skbuff.h:2527 [en línea] lr : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156 sp : ffff80001e0d6c40 x29: ffff80001e0d6e60 x28: dfff800000000000 x27: ffff0000c86328c0 x26: dfff800000000000 x25: ffff0000c8632990 x24: ffff0000c8632a00 x23: 0000000000000000 x22: 1fffe000190c6542 x21: ffff0000c8632a10 x20: ffff0000c8632a00 x19: ffff80001856e000 x18: ffff80001e0d5fc0 x17: 000000000000000 x16: ffff80001235d16c x15: 000000000000000 x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001 x11: ff80800008353a30 x10: 0000000000000000 x9: 21567eaf25bfb600 x8: 21567eaf25bfb600 x7: 000000000000001 x6: 000000000000001 x5: ffff80001e0d6558 x4: ffff800015c74760 x3: ffff800008596744 x2: 0000000000000001 x1 : 0000000100000000 x0 : 000000000000000e Rastreo de llamadas: skb_assert_len include/linux/skbuff.h:2527 [en línea] __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156 dev_queue_xmit include/linux/netdevice.h:3033 [en línea] __netlink_deliver_tap_skb net/netlink/af_netlink.c:307 [en línea] __netlink_deliver_tap+0x45c/0x6f8 net/netlink/af_netlink.c:325 netlink_deliver_tap+0xf4/0x174 net/netlink/af_netlink.c:338 __netlink_sendskb net/netlink/af_netlink.c:1283 [en línea] netlink_sendskb+0x6c/0x154 net/netlink/af_netlink.c:1292 netlink_unicast+0x334/0x8d4 net/netlink/af_netlink.c:1380 nlmsg_unicast include/net/netlink.h:1099 [en línea] genlmsg_unicast include/net/genetlink.h:433 [en línea] genlmsg_reply include/net/genetlink.h:443 [en línea] ila_xlat_nl_cmd_get_mapping+0x620/0x7d0 net/ipv6/ila/ila_xlat.c:493 genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [en línea] genl_family_rcv_msg net/netlink/genetlink.c:1048 [en línea] genl_rcv_msg+0x938/0xc1c net/netlink/genetlink.c:1065 netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2574 genl_rcv+0x38/0x50 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [en línea] netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x800/0xae0 net/netlink/af_netlink.c:1942 sock_sendmsg_nosec net/socket.c:714 [en línea] sock_sendmsg net/socket.c:734 [en línea] ____sys_sendmsg+0x558/0x844 net/socket.c:2479 ___sys_sendmsg net/socket.c:2533 [en línea] __sys_sendmsg+0x26c/0x33c net/socket.c:2562 __do_sys_sendmsg net/socket.c:2571 [en línea] __se_sys_sendmsg net/socket.c:2569 [en línea] __arm64_sys_sendmsg+0x80/0x94 net/socket.c:2569 __invoke_syscall arch/arm64/kernel/syscall.c:38 [en línea] invocar_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52 el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:142 do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193 el0_svc+0x58/0x168 arch/arm64/kernel/entry-common.c:637 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591 marca de evento irq: 136484 hardirqs habilitados por última vez en (136483): [] __up_console_sem+0x60/0xb4 kernel/printk/printk.c:345 hardirqs deshabilitados por última vez en (136484): [] el1_dbg+0x24/0x80 arch/arm6 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: Se corrige la posible corrupción al mover un directorio. Al renombrar un directorio, es necesario actualizar la entrada ".." en el directorio movido. Sin embargo, nada impide que el directorio movido se modifique e incluso se convierta del formato en línea al formato normal. Cuando esto ocurre, el código de renombrado se confunde y se produce un fallo. Solucione el problema bloqueando el directorio movido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: Eliminar el directorio /proc/scsi/${proc_name} antes. Eliminar el directorio /proc/scsi/${proc_name} antes para corregir una condición de ejecución entre la descarga y la recarga de módulos del kernel. Esto corrige un error introducido en 2009 por el commit 77c019768f06 ("[SCSI] corregir fuga de memoria de /proc en el núcleo SCSI"). Corrija la siguiente advertencia del kernel: proc_dir_entry 'scsi/scsi_debug' ya está registrado ADVERTENCIA: CPU: 19 PID: 27986 en fs/proc/generic.c:376 proc_register+0x27d/0x2e0 Seguimiento de llamadas: proc_mkdir+0xb5/0xe0 scsi_proc_hostdir_add+0xb5/0x170 scsi_host_alloc+0x683/0x6c0 sdebug_driver_probe+0x6b/0x2d0 [scsi_debug] really_probe+0x159/0x540 __driver_probe_device+0xdc/0x230 driver_probe_device+0x4f/0x120 __device_attach_driver+0xef/0x180 bus_for_each_drv+0xe5/0x130 __device_attach+0x127/0x290 device_initial_probe+0x17/0x20 bus_probe_device+0x110/0x130 device_add+0x673/0xc80 device_register+0x1e/0x30 sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug] scsi_debug_init+0x64f/0x1000 [scsi_debug] do_one_initcall+0xd7/0x470 do_init_module+0xe7/0x330 load_module+0x122a/0x12c0 __do_sys_finit_module+0x124/0x1a0 __x64_sys_finit_module+0x46/0x50 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: fdp: agregar comprobación nula de devm_kmalloc_array en fdp_nci_i2c_read_device_properties devm_kmalloc_array puede fallar, *fw_vsc_cfg puede ser nulo y provocar una escritura fuera de los límites en device_property_read_u8_array más adelante.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: caif: Se corrige el use-after-free en cfusbl_device_notify() syzbot informó el use-after-free en cfusbl_device_notify() [1]. Esto provoca un seguimiento de pila como el siguiente: ERROR: KASAN: use-after-free en cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138 Lectura de tamaño 8 en la dirección ffff88807ac4e6f0 por la tarea kworker/u4:6/1214 CPU: 0 PID: 1214 Comm: kworker/u4:6 No contaminado 5.19.0-rc3-syzkaller-00146-g92f20ff72066 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Cola de trabajo: netns cleanup_net Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xeb/0x467 mm/kasan/report.c:313 print_report mm/kasan/report.c:429 [inline] kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491 cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138 notifier_call_chain+0xb5/0x200 kernel/notifier.c:87 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1945 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10227 [inline] netdev_run_todo+0xbc0/0x10f0 net/core/dev.c:10341 default_device_exit_batch+0x44e/0x590 net/core/dev.c:11334 ops_exit_list+0x125/0x170 net/core/net_namespace.c:167 cleanup_net+0x4ea/0xb00 net/core/net_namespace.c:594 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 Al anular el registro de un dispositivo de red, unregister_netdevice_many_notify() establece el estado del dispositivo en NETREG_UNREGISTERING, llama a los notificadores con NETDEV_UNREGISTER y añade el dispositivo a la lista de tareas pendientes. Posteriormente, netdev_run_todo() procesa los dispositivos de la lista de tareas pendientes. netdev_run_todo() espera a que el recuento de referencias de los dispositivos llegue a 1 mientras retransmite la notificación NETDEV_UNREGISTER. Si se llama a cfusbl_device_notify() con NETDEV_UNREGISTER varias veces, el dispositivo principal podría liberarse. Esto podría causar un UAF. Procesar NETDEV_UNREGISTER varias veces también provoca un desequilibrio en el recuento de referencias del módulo. Este parche soluciona el problema aceptando solo la primera notificación NETDEV_UNREGISTER.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: se corrigen fugas de struct pid en la compatibilidad OOB. syzbot reportó una fuga de struct pid [1]. El problema radica en que queue_oob() llama a perhaps_add_creds(), que potencialmente contiene una referencia a un PID. Sin embargo, skb->destructor no está definido (ni directamente ni mediante la llamada a unix_scm_to_skb()). Esto significa que las posteriores operaciones kfree_skb() o consume_skb() filtrarían esta referencia. En esta corrección, opté por ofrecer compatibilidad total con scm, incluso para el mensaje OOB. [1] ERROR: pérdida de memoria, objeto no referenciado 0xffff8881053e7f80 (tamaño 128): comunicación "syz-executor242", pid 5066, jiffies 4294946079 (edad 13.220s), volcado hexadecimal (primeros 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] alloc_pid+0x6a/0x560 kernel/pid.c:180 [] copy_process+0x169f/0x26c0 kernel/fork.c:2285 [] kernel_clone+0xf7/0x610 kernel/fork.c:2684 [] __do_sys_clone+0x7c/0xb0 kernel/fork.c:2825 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd