Instituto Nacional de ciberseguridad. Sección Incibe

017 - Ir a la línea de ayuda en Ciberseguridad    Ir a Agenda     Ir a Sala de prensa     Ir a suscripción de boletines

Ir al buscador

Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

No hay vulnerabilidades nuevas para los productos a los que está suscrito.



Otras vulnerabilidades de los productos a los que usted está suscrito, y cuya información ha sido actualizada recientemente:

  • Vulnerabilidad en Barangay Population Monitoring System 1.0 (CVE-2024-25209)
    Severidad: CRÍTICA
    Fecha de publicación: 14/02/2024
    Fecha de última actualización: 23/10/2024
    Se descubrió que Barangay Population Monitoring System 1.0 contenía una vulnerabilidad de inyección SQL a través del parámetro residente en /endpoint/delete-resident.php.
  • Vulnerabilidad en Simple Expense Tracker v1.0 (CVE-2024-25210)
    Severidad: CRÍTICA
    Fecha de publicación: 14/02/2024
    Fecha de última actualización: 23/10/2024
    Se descubrió que Simple Expense Tracker v1.0 contiene una vulnerabilidad de inyección SQL a través del parámetro de gastos en /endpoint/delete_expense.php.
  • Vulnerabilidad en Simple Expense Tracker v1.0 (CVE-2024-25211)
    Severidad: CRÍTICA
    Fecha de publicación: 14/02/2024
    Fecha de última actualización: 23/10/2024
    Se descubrió que Simple Expense Tracker v1.0 contiene una vulnerabilidad de inyección SQL a través del parámetro de categoría en /endpoint/delete_category.php.
  • Vulnerabilidad en Online Medicine Ordering System v1.0 (CVE-2024-25217)
    Severidad: CRÍTICA
    Fecha de publicación: 14/02/2024
    Fecha de última actualización: 23/10/2024
    Se descubrió que Online Medicine Ordering System v1.0 contiene una vulnerabilidad de inyección SQL a través del parámetro id en /omos/?p=products/view_product.
  • Vulnerabilidad en Simple Admin Panel v1.0 (CVE-2024-25224)
    Severidad: MEDIA
    Fecha de publicación: 14/02/2024
    Fecha de última actualización: 23/10/2024
    Una vulnerabilidad de Cross-Site Scripting (XSS) en la aplicación Simple Admin Panel v1.0 permite a los atacantes script web o HTML arbitrario a través de un payload manipulado inyectado en el parámetro Número de tamaño en la función Agregar tamaño.
  • Vulnerabilidad en Simple Admin Panel v1.0 (CVE-2024-25225)
    Severidad: MEDIA
    Fecha de publicación: 14/02/2024
    Fecha de última actualización: 23/10/2024
    Una vulnerabilidad de Cross-Site Scripting (XSS) en la aplicación Simple Admin Panel v1.0 permite a los atacantes script web o HTML arbitrario a través de un payload manipulado inyectado en el parámetro Nombre de categoría en la función Agregar categoría.
  • Vulnerabilidad en PEAP (CVE-2023-52160)
    Severidad: MEDIA
    Fecha de publicación: 22/02/2024
    Fecha de última actualización: 23/10/2024
    La implementación de PEAP en wpa_supplicant hasta la versión 2.10 permite omitir la autenticación. Para un ataque exitoso, se debe configurar wpa_supplicant para no verificar el certificado TLS de la red durante la autenticación de la Fase 1, y luego se puede abusar de una vulnerabilidad eap_peap_decrypt para omitir la autenticación de la Fase 2. El vector de ataque envía un paquete de éxito EAP-TLV en lugar de iniciar la Fase 2. Esto permite a un adversario hacerse pasar por redes Wi-Fi empresariales.
  • Vulnerabilidad en v (CVE-2024-47670)
    Severidad: ALTA
    Fecha de publicación: 09/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: agregar comprobación de los límites a ocfs2_xattr_find_entry() Agregue una comprobación de paranoia para asegurarse de que no se desvíe más allá de la región de memoria válida que contiene entradas xattr de ocfs2 al escanear en busca de una coincidencia. Esto evitará el acceso fuera de los límites en caso de imágenes manipuladas.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47671)
    Severidad: MEDIA
    Fecha de publicación: 09/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: usbtmc: prevent kernel-usb-infoleak El syzbot informó una kernel-usb-infoleak en usbtmc_write, debemos borrar la estructura antes de completar los campos.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47672)
    Severidad: MEDIA
    Fecha de publicación: 09/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: no espere colas de transmisión si el firmware está muerto Hay una ADVERTENCIA en iwl_trans_wait_tx_queues_empty() (que se convirtió recientemente de solo un mensaje), que puede verse afectada si esperamos a que las colas de transmisión se vacíen después de que el firmware haya muerto. Claramente, no podemos esperar nada del firmware después de que se declare muerto. No llame a iwl_trans_wait_tx_queues_empty() en este caso. Si bien podría ser una buena idea detener el flujo antes, las funciones de vaciado realizan un trabajo de mantenimiento que no está relacionado con el firmware, así que mantenga esa parte del código en ejecución incluso cuando el firmware no se esté ejecutando. [editar mensaje de confirmación]
  • Vulnerabilidad en kernel de Linux (CVE-2024-47673)
    Severidad: MEDIA
    Fecha de publicación: 09/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: pausar TCM cuando el firmware está detenido. No hacerlo hará que enviemos un comando de host al transporte mientras el firmware no esté vivo, lo que activará una ADVERTENCIA. estado incorrecto = 0 WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] Call Trace: iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm] iwl_mvm_config_scan+0x198/0x260 [iwlmvm] iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm] iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm] process_one_work+0x29e/0x640 worker_thread+0x2df/0x690 ? rescuer_thread+0x540/0x540 kthread+0x192/0x1e0 ? set_kthread_struct+0x90/0x90 ret_from_fork+0x22/0x30
  • Vulnerabilidad en jsbroks COCO Annotator 0.11.1 (CVE-2024-10141)
    Severidad: MEDIA
    Fecha de publicación: 19/10/2024
    Fecha de última actualización: 23/10/2024
    Se ha encontrado una vulnerabilidad clasificada como problemática en jsbroks COCO Annotator 0.11.1. Afecta a una parte desconocida del componente Session Handler. La manipulación del argumento SECRET_KEY hace que el estado sea predecible y no observable. Es posible iniciar el ataque de forma remota. La complejidad del ataque es bastante alta. Se dice que la explotación es difícil. El exploit se ha hecho público y puede utilizarse.
  • Vulnerabilidad en Piyushmca Shipyaari Shipping Management (CVE-2024-49626)
    Severidad: CRÍTICA
    Fecha de publicación: 20/10/2024
    Fecha de última actualización: 23/10/2024
    La vulnerabilidad de deserialización de datos no confiables en Piyushmca Shipyaari Shipping Management permite la inyección de objetos. Este problema afecta a Shipyaari Shipping Management: desde n/a hasta 1.2.
  • Vulnerabilidad en HT Plugins WP Education (CVE-2024-49630)
    Severidad: MEDIA
    Fecha de publicación: 20/10/2024
    Fecha de última actualización: 23/10/2024
    Vulnerabilidad de neutralización incorrecta de la entrada durante la generación de páginas web (XSS o 'Cross-site Scripting') en HT Plugins WP Education permite XSS almacenado. Este problema afecta a WP Education: desde n/a hasta 1.2.8.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47690)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: deshacerse de la reparación en línea en un directorio dañado syzbot informa un error de f2fs como el siguiente: ¡ERROR del kernel en fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Seguimiento de llamadas: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [en línea] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [en línea] ptrace_report_syscall_exit include/linux/ptrace.h:477 [en línea] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_salir_a_modo_usuario_prepare kernel/entry/common.c:200 [en línea] __syscall_salir_a_modo_usuario_work kernel/entry/common.c:205 [en línea] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 La reparación en línea en un directorio dañado en f2fs_lookup() puede generar datos/meta sucios mientras se corre con el remontaje de solo lectura, puede dejar un inodo sucio después de que el sistema de archivos se vuelva de solo lectura, sin embargo, checkpoint() omitirá la limpieza del inodo sucio en un estado de modo de solo lectura, lo que dará como resultado el pánico mencionado anteriormente. Deshagámonos de la reparación en línea en f2fs_lookup() y dejemos el trabajo a fsck.f2fs.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47691)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar el use after free en f2fs_stop_gc_thread() syzbot informa un error de f2fs como el siguiente: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [en línea] atomic_fetch_add_relaxed incluir/linux/atomic/atomic-instrumented.h:252 [en línea] __refcount_add incluir/linux/refcount.h:184 [en línea] __refcount_inc incluir/linux/refcount.h:241 [en línea] refcount_inc incluir/linux/refcount.h:258 [en línea] obtener_estructura_de_tareas incluir/linux/sched/task.h:118 [en línea] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [en línea] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:907 [en línea] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f La causa raíz está a continuación de la condición de ejecución, puede causar un problema de use after free en el puntero sbi->gc_th. - remontar - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) - f2fs_ioc_shutdown - f2fs_do_shutdown - f2fs_stop_gc_thread - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; Llamaremos a f2fs_do_shutdown() en dos rutas: - para la ruta f2fs_ioc_shutdown(), debemos tomar el semáforo sb->s_umount para arreglarlo. - para la ruta f2fs_shutdown(), es seguro ya que el llamador ya ha tomado el semáforo sb->s_umount.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47692)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: devuelve -EINVAL cuando namelen es 0 Cuando tenemos un main.sqlite dañado en /var/lib/nfs/nfsdcld/, puede resultar en que namelen sea 0, lo que hará que memdup_user() devuelva ZERO_SIZE_PTR. Cuando accedemos al name.data al que se le ha asignado el valor ZERO_SIZE_PTR en nfs4_client_to_reclaim(), se activa la desreferencia de puntero nulo. [ T1205] ========================================================================= [ T1205] ERROR: KASAN: null-ptr-deref en nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Lectura de tamaño 1 en la dirección 0000000000000010 por la tarea nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld No contaminado 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware nombre: PC estándar QEMU (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 01/04/2014 [ T1205] Seguimiento de llamadas: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Código: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 000000000000000 R09: 00000000000000001 [ T1205] R10: 00000000000000000 R11: 00000000000000246 R12: 0000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ========================================================================= Arréglelo comprobando namelen.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47693)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/core: Arreglar la limpieza del flujo de error ib_cache_setup_one Cuando ib_cache_update devuelve un error, salimos de ib_cache_setup_one instantáneamente sin una limpieza adecuada, aunque antes de esto ya habíamos realizado con éxito gid_table_setup_one, que da como resultado la siguiente ADVERTENCIA del kernel. Realice una limpieza adecuada utilizando gid_table_cleanup_one antes de devolver el error para solucionar el problema. ADVERTENCIA: CPU: 4 PID: 922 en drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Módulos vinculados: CPU: 4 UID: 0 PID: 922 Comm: c_repro No contaminado 6.11.0-rc1+ #3 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Código: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000000400 Seguimiento de llamadas: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? Obtener tarea pid+0xb0/0xd0 ? error_proc_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 hacer_syscall_64+0x50/0x110 entrada_SYSCALL_64_después_hwframe+0x76/0x7e
  • Vulnerabilidad en kernel de Linux (CVE-2024-47694)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/mlx5: Corregir limpieza de pd de UMR en flujo de error de inicialización del controlador el commit citada mueve la asignación de pd de la función mlx5r_umr_resource_cleanup() a una nueva función mlx5r_umr_cleanup(). Por lo tanto, la corrección en el commit [1] no funciona. En el flujo de error, se activará el pánico [2]. Corríjalo comprobando el puntero pd para evitar el pánico si es NULL; [1] RDMA/mlx5: Se corrige la limpieza de UMR en el flujo de error del inicio del controlador [2] [ 347.567063] infiniband mlx5_0: No se pudo registrar el dispositivo con el modelo del controlador [ 347.591382] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000020 [ 347.593438] #PF: acceso de lectura del supervisor en modo kernel [ 347.595176] #PF: error_code(0x0000) - página no presente [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 000000000000000 RDI: 000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Seguimiento de llamadas: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? kernfs_add_one+0x107/0x150 [347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] sonda_de_bus_auxiliar+0x3e/0x90 [ 347.620448] sonda_realmente+0xc5/0x3a0 [ 347.620857] __dispositivo_de_sonda_del_controlador+0x80/0x160 [ 347.621325] dispositivo_de_sonda_del_controlador+0x1e/0x90 [ 347.621770] __dispositivo_de_sonda_del_controlador+0xec/0x1c0 [ 347.622213] ? __controlador_de_conexión_de_dispositivo+0x100/0x100 [ 347.622724] bus_para_cada_dispositivo+0x71/0xc0 [ 347.623151] bus_agregar_controlador+0xed/0x240 [ 347.623570] registro_del_controlador+0x58/0x100 [ 347.623998] __registro_del_controlador_auxiliar+0x6a/0xc0 [ 347.624499] ? registro_del_controlador+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] hacer_una_llamada_inicia+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] hacer_init_module+0x8a/0x260 [ 347.627126] iniciar_módulo_desde_archivo+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] hacer_syscall_64+0x4c/0x100
  • Vulnerabilidad en kernel de Linux (CVE-2024-47695)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/rtrs-clt: Restablecer cid a con_num - 1 para permanecer dentro de los límites En la función init_conns(), después del bucle for create_con() y create_cm() si algo falla. En el bucle for de limpieza después de la etiqueta destroy, accedemos a memoria fuera de los límites porque cid está configurado en clt_path->s.con_num. Esta confirmación restablece el cid a clt_path->s.con_num - 1, para permanecer dentro de los límites en el bucle de limpieza más tarde.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47696)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency En el commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs"), se invoca la función flush_workqueue para vaciar la cola de trabajo iwcm_wq. Pero en ese momento, la cola de trabajo iwcm_wq se creó a través de la función alloc_ordered_workqueue sin el indicador WQ_MEM_RECLAIM. Debido a que el proceso actual está intentando vaciar todo iwcm_wq, si iwcm_wq no tiene el indicador WQ_MEM_RECLAIM, verifique que el proceso actual no esté recuperando memoria o ejecutándose en una cola de trabajo que no tenga el indicador WQ_MEM_RECLAIM, ya que eso puede romper la garantía de progreso hacia adelante y provocar un bloqueo. El seguimiento de la llamada es el siguiente: [ 125.350876][ T1430] Seguimiento de la llamada: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminador 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminador 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminador 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (núcleo/bloqueo/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (controladores/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (controladores/nvme/host/rdma.c:656 controladores/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (controladores/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] proceso_uno_trabajo (kernel/workqueue.c:3231) [ 125.515122][ T1430] subproceso_de_trabajo (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_subproceso_de_trabajo (kernel/workqueue.c:3339) [ 125.531837][ T1430] subproceso_de_trabajo (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ fin de seguimiento 000000000000000 ]---
  • Vulnerabilidad en kernel de Linux (CVE-2024-47697)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: media: dvb-frontends/rtl2830: corrige un error de escritura fuera de los límites Asegúrate de que el índice en rtl2830_pid_filter no supere 31 para evitar el acceso fuera de los límites. dev->filters es un valor de 32 bits, por lo que las funciones set_bit y clear_bit solo deben funcionar en índices de 0 a 31. Si el índice es 32, intentará acceder a un bit 33 inexistente, lo que provocará un acceso fuera de los límites. Cambia la comprobación de límites de índice > 32 a índice >= 32 para resolver este problema.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47698)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: media: dvb-frontends/rtl2832: corrige un error de escritura fuera de los límites Asegúrate de que el índice en rtl2832_pid_filter no supere 31 para evitar el acceso fuera de los límites. dev->filters es un valor de 32 bits, por lo que las funciones set_bit y clear_bit solo deben funcionar en índices de 0 a 31. Si el índice es 32, intentará acceder a un bit 33 inexistente, lo que provocará un acceso fuera de los límites. Cambia la comprobación de límites de índice > 32 a índice >= 32 para resolver este problema. [hverkuil: se agregó la etiqueta de correcciones, rtl2830_pid_filter -> rtl2832_pid_filter en logmsg]
  • Vulnerabilidad en kernel de Linux (CVE-2024-47699)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: soluciona una posible desreferencia de puntero nulo en nilfs_btree_insert() Serie de parches "nilfs2: soluciona posibles problemas con nodos de árbol b vacíos". Esta serie aborda tres posibles problemas con nodos de árbol b vacíos que pueden ocurrir con imágenes de sistema de archivos dañadas, incluido uno descubierto recientemente por syzbot. Este parche (de 3): Si un árbol b está roto en el dispositivo y la altura del árbol b es mayor que 2 (el nivel del nodo raíz es mayor que 1) incluso si el número de nodos secundarios de la raíz del árbol b es 0, se produce una desreferencia de puntero NULL en nilfs_btree_prepare_insert(), que se llama desde nilfs_btree_insert(). Esto se debe a que, cuando el número de nodos secundarios de la raíz del árbol b es 0, nilfs_btree_do_lookup() no establece el encabezado del búfer de bloque en ninguno de los path[x].bp_bh, dejándolo como el valor inicial de NULL, pero si el nivel del nodo raíz del árbol b es mayor que 1, se llama a nilfs_btree_get_nonroot_node(), que accede a la memoria del búfer de path[x].bp_bh. Solucione este problema agregando una verificación a nilfs_btree_root_broken(), que realiza verificaciones de cordura al leer el nodo raíz desde el dispositivo, para detectar esta inconsistencia. Gracias a Lizhi Xu por intentar resolver el error y aclarar la causa desde el principio.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47700)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: comprobar la compatibilidad del tamaño de la franja al volver a montar también Deshabilitamos el tamaño de la franja en __ext4_fill_super si no es un múltiplo de la relación del clúster; sin embargo, esta comprobación se omite al intentar volver a montar. Esto puede dejarnos con casos en los que stripe < cluster_ratio después de remount:set, lo que hace que EXT4_B2C(sbi->s_stripe) se convierta en 0, lo que puede causar algunos errores imprevistos como dividir por 0. Solucione eso agregando la comprobación en la ruta de montaje también.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47701)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evitar OOB cuando system.data xattr cambia debajo del sistema de archivos Al buscar una entrada en un directorio en línea, si e_value_offs se cambia debajo del sistema de archivos por algún cambio en el dispositivo de bloque, conducirá a un acceso fuera de los límites que KASAN detecta como un UAF. EXT4-fs (loop0): sistema de archivos montado 00000000-0000-0000-0000-00000000000 r/w sin diario. Modo de cuota: ninguno. loop0: se detectó un cambio de capacidad de 2048 a 2047 ======================================================================= ERROR: KASAN: use after free en ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Lectura de tamaño 1 en la dirección ffff88803e91130f por la tarea syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 No contaminado 6.11.0-rc4-syzkaller #0 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:93 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [en línea] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [en línea] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [en línea] __se_sys_symlinkat fs/namei.c:4607 [en línea] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Llamada ext4_xattr_ibody_find justo después de leer el inodo con ext4_get_inode_loc conducirá a una verificación de la validez de los xattrs, evitando este problema.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47720)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Agregar comprobación nula para set_output_gamma en dcn30_set_output_transfer_func Esta confirmación agrega una comprobación nula para el puntero de función set_output_gamma en la función dcn30_set_output_transfer_func. Anteriormente, se estaba comprobando la nulidad de set_output_gamma en la línea 386, pero luego se estaba desreferenciando sin ninguna comprobación de nulidad en la línea 401. Esto podría conducir potencialmente a un error de desreferencia de puntero nulo si set_output_gamma es de hecho nulo. Para solucionar esto, ahora nos aseguramos de que set_output_gamma no sea nulo antes de desreferenciarlo. Hacemos esto agregando una comprobación de nulidad para set_output_gamma antes de la llamada a set_output_gamma en la línea 401. Si set_output_gamma es nulo, registramos un mensaje de error y no llamamos a la función. Esta corrección evita un posible error de desreferencia de puntero nulo. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 error de dcn30_set_output_transfer_func(): anteriormente asumimos que 'mpc->funcs->set_output_gamma' podría ser nulo (ver línea 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* programa OGAM o 3DLUT solo para la tubería superior*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*programa rmu shaper y 3dlut en MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 si (ret == falso && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Si esto es NULL 387 si (flujo->out_transfer_func.type == TF_TYPE_HWPWL) 388 parámetros = &flujo->out_transfer_func.pwl; 389 de lo contrario si (pipe_ctx->flujo->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &flujo->out_transfer_func, 393 &mpc->blender_params, falso)) 394 parámetros = &mpc->blender_params; 395 /* no hay LUT de ROM en OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Entonces se bloqueará 402 return ret; 403 }
  • Vulnerabilidad en kernel de Linux (CVE-2024-47721)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: eliminar el ID de evento C2H no utilizado RTW89_MAC_C2H_FUNC_READ_WOW_CAM para evitar la lectura fuera de los límites El controlador del evento C2H del firmware RTW89_MAC_C2H_FUNC_READ_WOW_CAM no está implementado, pero el controlador espera que el número de controladores sea NUM_OF_RTW89_MAC_C2H_FUNC_WOW, lo que provoca un acceso fuera de los límites. Solucione el problema eliminando el ID. Addresses-Coverity-ID: 1598775 ("Lectura fuera de los límites")
  • Vulnerabilidad en kernel de Linux (CVE-2024-47724)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath11k: usar cola de trabajo para procesar evento beacon tx el commit 3a415daa3e8b ("wifi: ath11k: agregar P2P IE en plantilla beacon") del 28 de febrero de 2024 (linux-next) genera la siguiente advertencia del verificador estático de Smatch: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: durmiendo en contexto atómico La razón es que ath11k_bcn_tx_status_event() llamará directamente a la función de suspensión ath11k_wmi_cmd_send() durante las secciones críticas del lado de lectura de RCU. El seguimiento de la llamada es así: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() -> ath11k_mac_setup_bcn_tmpl() …… -> ath11k_wmi_bcn_tmpl() -> ath11k_wmi_cmd_send() -> rcu_read_unlock() el commit 886433a98425 ("ath11k: agregar soporte para cambio de color BSS") agregó ath11k_mac_bcn_tx_event(), el commit 01e782c89108 ("ath11k: corregir advertencia de uso de RCU para ath11k_mac_get_arvif_by_vdev_id()") agregó el bloqueo de RCU para evitar advertencias pero también introdujo este ERROR. Utilice la cola de trabajo para evitar llamar directamente a ath11k_mac_bcn_tx_event() durante las secciones críticas de RCU. No es necesario preocuparse por la eliminación de vif porque cancel_work_sync() descartará el trabajo si no comienza o bloqueará la eliminación de vif hasta que finalice el trabajo en ejecución. Probado en: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
  • Vulnerabilidad en kernel de Linux (CVE-2024-47727)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/tdx: Se corrige la comprobación "MMIO en el kernel" TDX solo admite operaciones MMIO iniciadas por el kernel. La función handle_mmio() comprueba si la excepción #VE se produjo en el kernel y rechaza la operación si no fue así. Sin embargo, el espacio de usuario puede engañar al kernel para que realice MMIO en su nombre. Por ejemplo, si el espacio de usuario puede apuntar una llamada al sistema a una dirección MMIO, la llamada al sistema realiza get_user() o put_user() en ella, lo que activa MMIO #VE. El kernel tratará el #VE como MMIO en el kernel. Asegúrese de que la dirección MMIO de destino esté dentro del kernel antes de decodificar la instrucción.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47728)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: cero antiguos argumentos ARG_PTR_TO_{LONG,INT} en caso de error Para todos los ayudantes que no son de seguimiento que anteriormente tenían ARG_PTR_TO_{LONG,INT} como argumentos de entrada, ponga a cero el valor en caso de error, ya que de lo contrario podría perder memoria. Para el seguimiento, no es necesario dado que CAP_PERFMON ya puede leer toda la memoria del kernel de todos modos, por lo tanto, bpf_get_func_arg() y bpf_get_func_ret() se omiten aquí. Además, el valor del puntero mtu_len de los ayudantes de MTU se escribe pero también se lee. Técnicamente, MEM_UNINIT no debería estar allí para forzar siempre la inicialización. Sin embargo, eliminar MEM_UNINIT necesita más reelaboración del verificador: MEM_UNINIT en este momento implica dos cosas en realidad: i) escribir en la memoria, ii) la memoria no tiene que ser inicializada. Si eliminamos MEM_UNINIT, se convierte en: i) lectura en memoria, ii) la memoria debe inicializarse. Esto significa que para bpf_*_check_mtu() estamos agregando nuevamente el problema que estamos tratando de solucionar, es decir, entonces podría volver a escribir en cosas como mapas BPF .rodata. El trabajo de seguimiento reelaborará la semántica de MEM_UNINIT de modo que la intención pueda expresarse mejor. Por ahora, simplemente borre *mtu_len en la ruta de error que se puede eliminar nuevamente más tarde.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47729)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Utilizar un motor de copia reservada para los enlaces de usuario en dispositivos con fallos Los enlaces de usuario se asignan a motores con fallos, los fallos dependen de que se completen los enlaces de usuario, por lo que podemos bloquear. Evite esto utilizando un motor de copia reservada para los enlaces de usuario en dispositivos con fallos. Mientras estamos aquí, normalice la creación de colas de enlaces con un asistente. v2: - Pasar extensiones para la creación de colas de enlaces (CI) v3: - s/resevered/reserved (Lucas) - Reparar la comprobación de hwe NULL (Jonathan)
  • Vulnerabilidad en kernel de Linux (CVE-2024-47735)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/hns: Se corrige el error spin_unlock_irqrestore() llamado con IRQ habilitadas Se corrige el uso incorrecto de spin_lock_irq()/spin_unlock_irq() cuando spin_lock_irqsave()/spin_lock_irqrestore() estaba retenido. Esto se descubrió a través de la depuración de bloqueo, y el registro correspondiente es el siguiente: raw_local_irq_restore() llamado con IRQs habilitados ADVERTENCIA: CPU: 96 PID: 2074 en kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Rastreo de llamada: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_r_cocereate_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]
  • Vulnerabilidad en kernel de Linux (CVE-2024-47736)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: manejar pclusters superpuestos fuera de imágenes manipuladas correctamente syzbot informó un problema de bloqueo de tareas debido a un caso de interbloqueo donde está esperando el bloqueo de folio de un folio en caché que se usará para E/S de caché. Después de mirar la imagen difusa creada, encontré que está formada con varios pclusters grandes superpuestos como se muestra a continuación: Ext: desplazamiento lógico | longitud: desplazamiento físico | longitud 0: 0.. 16384 | 16384: 151552.. 167936 | 16384 1: 16384.. 32768 | 16384: 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Aquí, las extensiones 0/1 están físicamente superpuestas, aunque es completamente _impossible_ para las imágenes de sistemas de archivos normales generadas por mkfs. Primero, los folios administrados que contienen datos comprimidos se marcarán como actualizados y luego se desbloquearán inmediatamente (a diferencia de los folios locales) cuando se completen las E/S comprimidas. Si los bloques físicos no se envían en el orden incremental, debe haber BIO separados para evitar problemas de dependencia. Sin embargo, el código actual organiza mal z_erofs_fill_bio_vec() y el envío de BIO, lo que causa esperas inesperadas de BIO. En segundo lugar, los folios administrados se conectarán a sus propios pclusters para realizar consultas entre consultas eficientes. Sin embargo, esto es algo difícil de implementar fácilmente si existen pclusters grandes superpuestos. Nuevamente, estos solo aparecen en imágenes difusas, por lo que simplemente retrocedamos a páginas temporales de corta duración para que sean correctas. Además, justifica que los folios administrados referenciados no se pueden truncar por ahora y revierte parte de el commit 2080ca1ed3e4 ("erofs: ordenar `struct z_erofs_bvec`") para simplificar, aunque no debería haber ninguna diferencia.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47738)
    Severidad: BAJA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: tampoco use máscara de velocidad para TX fuera de canal Al igual que el commit ab9177d83c04 ("wifi: mac80211: no use máscara de velocidad para escanear"), ignore las configuraciones incorrectas para evitar la advertencia de velocidad no admitida informada por syzbot. El syzbot dividió y encontró la causa en el commit 9df66d5b9f45 ("cfg80211: corrige la máscara de velocidad de bits de transmisión HE predeterminada en la banda 2G"), que sin embargo corrige la máscara de bits de HE MCS y reconoce correctamente las configuraciones de la velocidad heredada vacía más la velocidad de HE MCS en lugar de devolver -EINVAL. Como sugerencias [1], siga el cambio de SCAN TX para considerar también este caso de TX fuera de canal. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024
  • Vulnerabilidad en kernel de Linux (CVE-2024-47741)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: arreglo de ejecución que establece el archivo privado en lseek concurrente usando el mismo fd Al realizar llamadas al sistema lseek(2) concurrentes contra el mismo descriptor de archivo, usando múltiples subprocesos que pertenecen al mismo proceso, tenemos una ventana de tiempo corta donde ocurre una ejecución y puede resultar en una pérdida de memoria. La ejecución ocurre así: 1) Un programa abre un descriptor de archivo para un archivo y luego genera dos subprocesos (con la biblioteca pthreads por ejemplo), llamémoslos tarea A y tarea B; 2) La tarea A llama a lseek con SEEK_DATA o SEEK_HOLE y termina en file.c:find_desired_extent() mientras mantiene un bloqueo de lectura en el inodo; 3) Al comienzo de find_desired_extent(), extrae el puntero private_data del archivo en una variable local llamada 'private', que tiene un valor de NULL; 4) La tarea B también llama a lseek con SEEK_DATA o SEEK_HOLE, bloquea el inodo en modo compartido e ingresa a file.c:find_desired_extent(), donde también extrae file->private_data en su variable local 'private', que tiene un valor NULL; 5) Debido a que vio un archivo privado NULL, la tarea A asigna una estructura privada y la asigna a la estructura de archivo; 6) La tarea B también vio un archivo privado NULL, por lo que también asigna su propio archivo privado y luego lo asigna a la misma estructura de archivo, ya que ambas tareas están usando el mismo descriptor de archivo. En este punto filtramos la estructura privada asignada por la tarea A. Además de la fuga de memoria, también está el detalle de que ambas tareas terminan usando el mismo registro de estado en caché en la estructura privada (struct btrfs_file_private::llseek_cached_state), lo que puede resultar en un problema de use after free, ya que una tarea puede liberarlo mientras la otra todavía lo está usando (solo una tarea tomó un recuento de referencia en él). Además, compartir el estado en caché no es una buena idea, ya que podría resultar en resultados incorrectos en el futuro; en este momento no debería ser un problema porque termina siendo utilizado solo en extended-io-tree.c:count_range_bits() donde realizamos la validación de rango antes de usar el estado en caché. Solucione esto protegiendo la asignación privada y la verificación de un archivo mientras mantiene el spinlock del inodo y realice un seguimiento de la tarea que asignó el privado, de modo que solo lo use esa tarea para evitar problemas de use after free con el registro de estado en caché, así como potencialmente usarlo incorrectamente en el futuro.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47742)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 23/10/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware_loader: Block path traversal La mayoría de los nombres de firmware son cadenas codificadas o se construyen a partir de cadenas de formato bastante restringidas donde las partes dinámicas son solo algunos números hexadecimales o algo así. Sin embargo, hay un par de rutas de código en el kernel donde los nombres de archivo de firmware contienen componentes de cadena que se pasan desde un dispositivo o un espacio de usuario semiprivilegiado; los que pude encontrar (sin contar las interfaces que requieren privilegios de root) son: - lpfc_sli4_request_firmware_update() parece construir el nombre de archivo de firmware a partir de "ModelName", una cadena que se analizó previamente a partir de algún descriptor ("Vital Product Data") en lpfc_fill_vpd() - nfp_net_fw_find() parece construir un nombre de archivo de firmware a partir de un nombre de modelo que proviene de nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), que creo que analiza algún descriptor que se leyó desde el dispositivo. (Pero este caso probablemente no sea explotable porque la cadena de formato se parece a "netronome/nic_%s", y no debería haber ninguna *carpeta* que comience con "netronome/nic_". El caso anterior era diferente porque allí, el "%s" está *al comienzo* de la cadena de formato). - module_flash_fw_schedule() es accesible desde el comando netlink ETHTOOL_MSG_MODULE_FW_FLASH_ACT, que está marcado como GENL_UNS_ADMIN_PERM (lo que significa que CAP_NET_ADMIN dentro de un espacio de nombres de usuario es suficiente para pasar la verificación de privilegios), y toma un nombre de firmware provisto por el espacio de usuario. (Pero creo que para llegar a este caso, necesita tener CAP_NET_ADMIN sobre un espacio de nombres de red en el que se asigna un tipo especial de dispositivo Ethernet, por lo que creo que esta no es una ruta de ataque viable en la práctica). Arréglelo rechazando cualquier nombre de firmware que contenga componentes de ruta ".." Por si sirve de algo, he buscado y no he encontrado ningún controlador de dispositivo USB que utilice el cargador de firmware de forma peligrosa.