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 kernel de Linux (CVE-2023-6606)
  Severidad: ALTA
  Fecha de publicación: 08/12/2023
  Fecha de última actualización: 25/10/2024
  Se encontró una vulnerabilidad de lectura fuera de los límites en smbCalcSize en fs/smb/client/netmisc.c en el kernel de Linux. Este problema podría permitir que un atacante local bloquee el sistema o filtre información interna del kernel.
  
• Vulnerabilidad en Intel(R) (CVE-2023-32646)
  Severidad: ALTA
  Fecha de publicación: 14/02/2024
  Fecha de última actualización: 25/10/2024
  El elemento de ruta de búsqueda no controlado en algunos software Intel(R) VROC anteriores a la versión 8.0.8.1001 puede permitir que un usuario autenticado potencialmente habilite la escalada de privilegios a través del acceso local.
  
• Vulnerabilidad en Intel(R) (CVE-2023-33870)
  Severidad: ALTA
  Fecha de publicación: 14/02/2024
  Fecha de última actualización: 25/10/2024
  Los permisos heredados inseguros en algunas herramientas Intel(R) Ethernet y software de instalación de controladores pueden permitir que un usuario autenticado potencialmente habilite la escalada de privilegios a través del acceso local.
  
• Vulnerabilidad en Roundcube Webmail (CVE-2024-37383)
  Severidad: MEDIA
  Fecha de publicación: 07/06/2024
  Fecha de última actualización: 25/10/2024
  Roundcube Webmail anterior a 1.5.7 y 1.6.x anterior a 1.6.7 permite XSS a través de atributos animados SVG.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-43848)
  Severidad: MEDIA
  Fecha de publicación: 17/08/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: mac80211: arreglar el trabajo de desmontaje de TTLM El trabajador calcula el puntero sdata incorrecto, por lo que si alguna vez se ejecuta, fallará. Arregla eso.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49867)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: esperar a los trabajadores de reparación antes de detener el kthread del limpiador durante el desmontaje Durante el desmontaje, en close_ctree(), tenemos los siguientes pasos en este orden: 1) Aparcar el kthread del limpiador - esto no destruye el kthread, básicamente detiene su ejecución (las reactivaciones contra él funcionan pero no hacen nada); 2) Detenemos el kthread del limpiador - esto da como resultado la liberación de la estructura respectiva task_struct; 3) Llamamos a btrfs_stop_all_workers() que espera a que se ejecuten trabajos en todas las colas de trabajo y luego libera las colas de trabajo. Syzbot informó de un caso en el que un trabajador de reparación provocó un bloqueo al realizar una entrada retrasada en su inodo mientras intentaba despertar al limpiador en btrfs_add_delayed_iput(), porque la estructura task_struct del kthread del limpiador ya estaba liberada. Esto puede suceder durante el desmontaje porque no esperamos a que haya ningún trabajador de reparación que aún esté en ejecución antes de llamar a kthread_stop() contra el kthread de limpieza, que se detiene y libera todos sus recursos. Solucione esto esperando a que haya algún trabajador de reparación en close_ctree() antes de llamar a kthread_stop() contra el kthread de limpieza y ejecutarlo en espera de entradas retrasadas. Los seguimientos de pila informados por syzbot fueron los siguientes: ERROR: KASAN: slab-use-after-free en __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Lectura de tamaño 8 en la dirección ffff8880272a8a18 por la tarea kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 No contaminado 6.12.0-rc1-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Cola de trabajo: btrfs-fixup btrfs_work_helper Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 imprimir_dirección_descripción mm/kasan/report.c:377 [en línea] imprimir_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave incluir/linux/spinlock_api_smp.h:110 [en línea] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 constructor de guardado de irq de clase_sin procesar spinlock include/linux/spinlock.h:551 [en línea] intento_de_activación+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 proceso_un_trabajo kernel/workqueue.c:3229 [en línea] proceso_trabajos_programados+0xa63/0x1850 kernel/workqueue.c:3310 subproceso_trabajador+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Asignado por la tarea 2: kasan_save_stack mm/kasan/common.c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [en línea] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [en línea] slab_post_alloc_hook mm/slub.c:4086 [en línea] slab_alloc_node mm/slub.c:4135 [en línea] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [en línea] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [en línea] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Liberado por la tarea 61: kasan_save_stack mm/kasan/common.c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/k---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49868)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige una desreferencia de puntero NULL cuando no se puede iniciar una nueva transacción [ERROR] Syzbot informó una desreferencia de puntero NULL con el siguiente bloqueo: FAULT_INJECTION: forzando un fallo. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... Información de BTRFS (dispositivo loop0): balance: finalizado con estado: -12 Vaya: error de protección general, probablemente para la dirección no canónica 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Seguimiento de llamadas: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [en línea] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSA] El fallo de asignación ocurre en start_transaction() dentro de prepare_to_relocate(), y durante el manejo de errores llamamos a unset_reloc_control(), lo que hace que fs_info->balance_ctl sea NULL. Luego continuamos con la limpieza de la ruta de error en btrfs_balance() llamando a reset_balance_state() que llamará a del_balance_item() para eliminar por completo el elemento de balance en el árbol raíz. Sin embargo, durante la pequeña ventana entre set_reloc_contrl() y unset_reloc_control(), podemos tener una actualización del árbol de subvolumen y crear un reloc_root para ese subvolumen. Luego pasamos a la btrfs_commit_transaction() final de del_balance_item() y a btrfs_update_reloc_root() dentro de commit_fs_roots(). Esa función verifica si fs_info->reloc_ctl está en la etapa merge_reloc_tree, pero dado que fs_info->reloc_ctl es NULL, da como resultado una desreferencia de puntero NULL. [SOLUCIÓN] Solo hay que añadir una comprobación adicional en fs_info->reloc_ctl dentro de btrfs_update_reloc_root(), antes de comprobar fs_info->reloc_ctl->merge_reloc_tree. El manejo de DEAD_RELOC_TREE sirve para evitar modificaciones adicionales del árbol de reubicación durante la etapa de fusión, pero como no hay ningún reloc_ctl, no tenemos que preocuparnos por eso.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49870)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: se corrige la pérdida de dentry en cachefiles_open_file(). Una pérdida de dentry puede producirse cuando una cookie de búsqueda y un cull son concurrentes: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // obtener dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true return false return false // Devuelve un error pero no coloca dentry Después de eso, se activará la siguiente ADVERTENCIA cuando se desmonte la carpeta del backend: ===================================================================== ERROR: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} todavía en uso (1) [desmontaje de ext4 sda] ADVERTENCIA: CPU: 4 PID: 359261 en fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount No contaminado 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Rastreo de llamadas: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ==================================================================== Independientemente de si cachefiles_open_file() devuelve verdadero o falso, el recuento de referencias obtenido por lookup_positive_unlocked() en cachefiles_look_up_object() debe liberarse. Por lo tanto, libere ese recuento de referencias en cachefiles_look_up_object() para solucionar el problema anterior y simplificar el código.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49880)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de un problema en alloc_flex_gd() Wesley informó de un problema: ======================================================================= EXT4-fs (dm-5): cambio de tamaño del sistema de archivos de 7168 a 786432 bloques ------------[ corte aquí ]------------ ¡ERROR del kernel en fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs No contaminado 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Rastreo de llamadas: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e == ... Tome n=0,flexbg_size=16 como ejemplo: last:15 |o---------------|--------------n-| o_group:0 redimensionar a n_group:30 El reproductor correspondiente es: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Elimine el problema más 1 para solucionar el problema y agregue un WARN_ON_ONCE() para evitar que el problema vuelva a ocurrir. [ Nota: otro reprocesador que esta confirmación corrige es: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49881)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: actualización de orig_path en ext4_find_extent() En ext4_find_extent(), si la ruta no es lo suficientemente grande, la liberamos y establecemos *orig_path en NULL. Pero después de reasignar e inicializar correctamente la ruta, no actualizamos *orig_path, en cuyo caso el llamador obtiene una ruta válida pero un ppath NULL, y esto puede causar una desreferencia de puntero NULL o una pérdida de memoria de ruta. Por ejemplo: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // ¡Desreferencia de puntero NULL! ===================================================================== ERROR: Desreferencia de puntero NULL del núcleo, dirección: 000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress No contaminado 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Rastreo de llamada: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ====================================================================== Por lo tanto, *orig_path se actualiza cuando la búsqueda de extensión tiene éxito, de modo que el llamador puede usar path o *ppath de forma segura.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49883)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evitar use-after-free en ext4_ext_insert_extent() Como mencionó Ojaswin en Link, en ext4_ext_insert_extent(), si la ruta se reasigna en ext4_ext_create_new_leaf(), usaremos la ruta obsoleta y causaremos UAF. A continuación, se muestra un seguimiento de muestra con valores ficticios: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* aquí la ruta sigue siendo 2000, UAF! */ eh = path[depth].p_hdr ===================================================================== ERROR: KASAN: slab-use-after-free en ext4_ext_insert_extent+0x26d4/0x3330 Lectura de tamaño 8 en la dirección ffff8881027bf7d0 por la tarea kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 No contaminado 6.11.0-rc2-dirty #866 Seguimiento de llamadas: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Asignado por la tarea 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Liberado por la tarea 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...]================================================================== Así que use *ppath para actualizar el path para evitar el problema de arriba
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49884)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de slab-use-after-free en ext4_split_extent_at() Nos topamos con el siguiente use after free: ====================================================================== ERROR: KASAN: slab-use-after-free en ext4_split_extent_at+0xba8/0xcc0 Lectura de tamaño 2 en la dirección ffff88810548ed08 por la tarea kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 No contaminado 6.9.0-dirty #724 Seguimiento de llamadas: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Asignado por la tarea 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Liberado por la tarea 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ==================================================================== El flujo de activación del problema es el siguiente: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // devuelve -ENOMEM o -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. Si err es -ENOMEM: ext4_ext_dirty(path + path->p_depth) // ¡¡¡path use after free!!! b. Si err es -EIO y tenemos EXT_DEBUG definido: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // ¡¡¡La ruta también es use after free!!! Por lo tanto, cuando intente poner a cero o corregir la longitud de la extensión, llame a ext4_find_extent() para actualizar la ruta. Además, usamos *ppath directamente como una entrada de ext4_ext_show_leaf() para evitar un posible use after free cuando se define EXT_DEBUG y para evitar actualizaciones de ruta innecesarias.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49889)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evitar use after free en ext4_ext_show_leaf() En ext4_find_extent(), path puede liberarse por error o reasignarse, por lo que el uso de un *ppath previamente guardado puede haberse liberado y, por lo tanto, puede activar el use after free, de la siguiente manera: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent no puede liberar path // pero la puesta a cero tiene éxito ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // use after free de path !!! De manera similar a ext4_split_extent_at(), usamos *ppath directamente como entrada para ext4_ext_show_leaf(). Por cierto, corrige un error ortográfico. El mismo problema en ext4_ext_handle_unwritten_extents(). Dado que 'path' solo se usa en ext4_ext_show_leaf(), elimine 'path' y use *ppath directamente. Este problema se activa solo cuando se define EXT_DEBUG y, por lo tanto, no afecta la funcionalidad.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49890)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: asegúrese de que fw_info no sea nulo antes de usarlo Esto resuelve la advertencia de valor de retorno nulo desreferenciado informada por Coverity.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49891)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Validar punteros hdwq antes de desreferenciar en rutas de reinicio/errata Cuando el HBA está experimentando un reinicio o está manejando un evento de erratas, pueden ocurrir fallos de desreferencia de ptr NULL en rutinas como lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk() o lpfc_abort_handler(). Agregue verificaciones de ptr NULL antes de desreferenciar punteros hdwq que pueden haberse liberado debido a operaciones que colisionan con un controlador de eventos de reinicio o erratas.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49892)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: inicializar el valor predeterminado de get_bytes_per_element en 1. Las variables, utilizadas como denominadores y que quizás no se asignen a otros valores, no deben ser 0. bytes_per_element_y y bytes_per_element_c se inicializan mediante get_bytes_per_element(), que nunca debe devolver 0. Esto corrige 10 problemas de DIVIDE_BY_ZERO informados por Coverity.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49893)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: comprobar stream_status antes de usarlo [QUÉ Y CÓMO] dc_state_get_stream_status puede devolver null y, por lo tanto, debe comprobarse null antes de usar stream_status. Esto soluciona 1 problema de NULL_RETURNS informado por Coverity.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49894)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Corrige el índice fuera de los límites en la traducción del formato de hardware degamma Corrige el problema del índice fuera de los límites en la función `cm_helper_translate_curve_to_degamma_hw_format`. El problema podría ocurrir cuando el índice 'i' excede el número de puntos de función de transferencia (TRANSFER_FUNC_POINTS). La corrección agrega una verificación para garantizar que 'i' esté dentro de los límites antes de acceder a los puntos de función de transferencia. Si 'i' está fuera de los límites, la función devuelve falso para indicar un error. Reportado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.blue' 1025 <= s32max
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49895)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se corrige el índice fuera de los límites en la traducción del formato de hardware degamma de DCN30. Esta confirmación aborda un posible problema de índice fuera de los límites en la función `cm3_helper_translate_curve_to_degamma_hw_format` en el módulo de administración de color DCN30. El problema podría ocurrir cuando el índice 'i' excede la cantidad de puntos de función de transferencia (TRANSFER_FUNC_POINTS). La corrección agrega una verificación para garantizar que 'i' esté dentro de los límites antes de acceder a los puntos de función de transferencia. Si 'i' está fuera de los límites, la función devuelve falso para indicar un error. Reportado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.blue' 1025 <= s32max
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49899)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Inicializar el valor predeterminado de los denominadores en 1 [QUÉ Y CÓMO] Las variables utilizadas como denominadores y que quizás no estén asignadas a otros valores, no deben ser 0. Cambie su valor predeterminado a 1 para que nunca sean 0. Esto corrige 10 problemas de DIVIDE_BY_ZERO informados por Coverity.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49900)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: Se corrige el acceso a uninit-value de new_ea en ea_buffer syzbot informa que lzo1x_1_do_compress está usando uninit-value: ========================================================= ERROR: KMSAN: uninit-value en lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit se almacenó en la memoria en: ea_put fs/jfs/xattr.c:639 [en línea] ... La variable local ea_buf se creó en: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ========================================================== El motivo es que ea_buf->new_ea no se inicializa correctamente. Solucione esto usando memset para vaciar su contenido al principio en ea_get().
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49901)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/adreno: Asignar msm_gpu->pdev antes para evitar nullptrs Hay algunos casos, como el descubierto por Commit 46d4efcccc68 ("drm/msm/a6xx: Evitar una desreferencia nullptr cuando fallo la configuración de speedbin") donde msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); se llama en gpu->pdev == NULL, ya que el dispositivo GPU aún no se ha inicializado por completo. Resulta que hay más que solo la ruta mencionada anteriormente que hace que esto suceda (por ejemplo, el caso cuando hay datos de speedbin en el catálogo, pero opp-supported-hw falta en DT). Asignar msm_gpu->pdev antes parece ser la solución menos dolorosa para esto, así que hazlo. Parche: https://patchwork.freedesktop.org/patch/602742/
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49903)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: Corrección de uaf en dbFreeBits [informado por syzbot] ====================================================================== ERROR: KASAN: slab-use-after-free en __mutex_lock_common kernel/locking/mutex.c:587 [en línea] ERROR: KASAN: slab-use-after-free en __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Lectura de tamaño 8 en la dirección ffff8880229254b0 por la tarea syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 No contaminado 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/06/2024 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 __mutex_lock_common kernel/locking/mutex.c:587 [en línea] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [en línea] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 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 Liberado por la tarea 5218: kasan_save_stack mm/kasan/common.c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [en línea] slab_free_hook mm/slub.c:2252 [en línea] slab_free mm/slub.c:4473 [en línea] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [en línea] vfs_fsconfig_locked fs/fsopen.c:292 [en línea] __do_sys_fsconfig fs/fsopen.c:473 [en línea] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Análisis] Hay dos rutas (dbUnmount y jfs_ioc_trim) que generan una condición de ejecución al acceder a bmap, lo que lleva a la ocurrencia de uaf. Utilice el bloqueo s_umount para sincronizarlas, a fin de evitar uaf causado por una condición de ejecución.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49904)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: agregar comprobación de lista vacía para evitar problemas de puntero nulo Agrega comprobación de lista vacía para evitar problemas de puntero nulo en algunos casos especiales. - list_for_each_entry_safe()
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49919)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Agregar comprobación NULL para head_pipe en dcn201_acquire_free_pipe_for_layer Esta confirmación soluciona un posible problema de desreferencia de puntero nulo en la función `dcn201_acquire_free_pipe_for_layer`. El problema podría ocurrir cuando `head_pipe` es nulo. La corrección agrega una comprobación para garantizar que `head_pipe` no sea nulo antes de confirmarlo. Si `head_pipe` es nulo, la función devuelve NULL para evitar una posible desreferencia de puntero nulo. Reportado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 Error de dcn201_acquire_free_pipe_for_layer(): anteriormente asumimos que 'head_pipe' podría ser nulo (ver línea 1010)
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49920)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: comprobar punteros nulos antes de múltiples usos [QUÉ Y CÓMO] Los punteros, como stream_enc y dc->bw_vbios, se comprueban como nulos previamente en la misma función, por lo que Coverity advierte "implica que stream_enc y dc->bw_vbios podrían ser nulos". Se utilizan varias veces en el código posterior y es necesario comprobarlos. Esto soluciona 10 problemas de FORWARD_NULL informados por Coverity.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49921)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: comprobar punteros nulos antes de usarlos [QUÉ Y CÓMO] Los punteros, como dc->clk_mgr, se comprueban antes en la misma función, por lo que Coverity advierte que "implica que "dc->clk_mgr" podría ser nulo". Como resultado, estos punteros deben comprobarse cuando se utilicen nuevamente. Esto soluciona 10 problemas de FORWARD_NULL informados por Coverity.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49922)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: comprobar punteros nulos antes de usarlos [QUÉ Y CÓMO] Estos punteros se comprobaron previamente en la misma función, lo que indica que podrían ser nulos, como informó Coverity. Como resultado, deben comprobarse cuando se vuelvan a utilizar. Esto soluciona el problema 3 FORWARD_NULL informado por Coverity.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49924)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: pxafb: Arregla posible use after free en pxafb_task() En la función pxafb_probe, llama a la función pxafb_init_fbinfo, después de lo cual &fbi->task se asocia con pxafb_task. Además, dentro de esta función pxafb_init_fbinfo, la función pxafb_blank dentro de la estructura &pxafb_ops es capaz de programar trabajo. Si eliminamos el módulo que llamará a pxafb_remove para hacer la limpieza, llamará a la función unregister_framebuffer que puede llamar a do_unregister_framebuffer para liberar fbi->fb a través de put_fb_info(fb_info), mientras que se utilizará el trabajo mencionado anteriormente. La secuencia de operaciones que pueden llevar a un error de UAF es la siguiente: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Solucione el problema asegurándose de cancelar el trabajo antes de continuar con la limpieza en pxafb_remove. Tenga en cuenta que solo el usuario root puede eliminar el controlador en tiempo de ejecución.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49928)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: evitar la lectura fuera de los límites al cargar elementos FW de potencia TX Debido a que loop-expression lo hará una vez más antes de obtener false de cond-expression, el código original copió un tamaño de entrada más allá de la región válida. Solucione el problema moviendo la copia de la entrada a loop-body.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49929)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: evitar la desreferencia del puntero NULL iwl_mvm_tx_skb_sta() e iwl_mvm_tx_mpdu() verifican que el puntero mvmvsta no sea NULL. Recupera este puntero utilizando iwl_mvm_sta_from_mac80211, que está desreferenciando el puntero ieee80211_sta. Si sta es NULL, iwl_mvm_sta_from_mac80211 desreferenciará un puntero NULL. Solucione esto comprobando el puntero sta antes de recuperar el mvmsta de él. Si sta no es NULL, entonces mvmsta tampoco lo es.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49930)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath11k: arreglo de acceso fuera de los límites a la matriz en las estadísticas de SoC Actualmente, la matriz ath11k_soc_dp_stats::hal_reo_error está definida con un tamaño máximo de DP_REO_DST_RING_MAX. Sin embargo, la función ath11k_dp_process_rx() accede a ath11k_soc_dp_stats::hal_reo_error utilizando el ID de anillo SRNG de destino REO, lo cual es incorrecto. El ID de anillo SRNG difiere del ID de anillo normal, y este uso conduce a un acceso a la matriz fuera de los límites. Para solucionar este problema, modifique ath11k_dp_process_rx() para utilizar el ID de anillo normal directamente en lugar del ID de anillo SRNG para evitar el acceso a la matriz fuera de los límites. Probado en: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49931)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: arreglo de acceso fuera de los límites a la matriz en las estadísticas de SoC Actualmente, la matriz ath12k_soc_dp_stats::hal_reo_error está definida con un tamaño máximo de DP_REO_DST_RING_MAX. Sin embargo, la función ath12k_dp_rx_process() accede a ath12k_soc_dp_stats::hal_reo_error utilizando el ID de anillo SRNG de destino REO, lo cual es incorrecto. El ID de anillo SRNG difiere del ID de anillo normal, y este uso conduce a un acceso a la matriz fuera de los límites. Para solucionar este problema, modifique ath12k_dp_rx_process() para utilizar el ID de anillo normal directamente en lugar del ID de anillo SRNG para evitar el acceso a la matriz fuera de los límites. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49936)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/xen-netback: evitar UAF en xenvif_flush_hash() Durante la llamada de iteración list_for_each_entry_rcu de xenvif_flush_hash, kfree_rcu no existe dentro de la sección crítica de lectura de rcu, por lo que si se llama a kfree_rcu cuando finaliza el período de gracia de rcu durante la iteración, se produce UAF al acceder a head->next después de que la entrada se libera. Por lo tanto, para resolver esto, debe cambiarlo a list_for_each_entry_safe.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49941)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpiolib: Corrige la posible desreferencia de puntero NULL en gpiod_get_label() En `gpiod_get_label()`, es posible que `srcu_dereference_check()` pueda devolver un puntero NULL, lo que lleva a un escenario en el que se accede a `label->str` sin verificar si `label` en sí es NULL. Este parche agrega una comprobación NULL adecuada para `label` antes de acceder a `label->str`. La comprobación para `label->str != NULL` se elimina porque `label->str` nunca puede ser NULL si `label` no es NULL. Esto corrige el problema en el que el nombre de la etiqueta se imprimía como `(efault)` al volcar el archivo GPIO de sysfs cuando `label == NULL`.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49942)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Impedir el acceso a puntero nulo en xe_migrate_copy xe_migrate_copy está diseñado para copiar el contenido de los recursos de TTM. Cuando el recurso de origen es nulo, activará una desreferencia de puntero NULL en xe_migrate_copy. Para evitar esta situación, actualice el indicador de origen a verdadero para este caso; el indicador activará xe_migrate_clear en lugar de xe_migrate_copy. Rastreo de problemas: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Paso 14, tamaños: 4194304 y 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Paso 15, tamaños: 4194304 y 4194304 <1> [317.128055] ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000010 <1> [317.128064] #PF: acceso de lectura del supervisor en modo núcleo <1> [317.128066] #PF: error_code(0x0000) - no presente página <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Ups: Ups: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Contaminado: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Contaminado: [U]=USUARIO, [N]=PRUEBA <4> [317.128080] Nombre del hardware: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 29/07/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Código: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] X: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 00000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Seguimiento de llamadas: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209]? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] +0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit]---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49981)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: se corrige el error de use after free en venus_remove debido a la condición de ejecución en venus_probe, core->work está vinculado con venus_sys_error_handler, que se usa para manejar el error. El código usa core->sys_err_done para que funcione la sincronización. El core->work se inicia en venus_event_notify. Si llamamos a venus_remove, puede haber un trabajo sin pescar. La secuencia posible es la siguiente: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queues_reinit |//use hdev Arréglelo cancelando el trabajo en venus_remove.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49982)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: aoe: soluciona el posible problema de use-after-free en más lugares Para solucionar CVE-2023-6270, f98364e92662 ("aoe: soluciona el posible problema de use-after-free en aoecmd_cfg_pkts") hace que tx() llame a dev_put() en lugar de hacerlo en aoecmd_cfg_pkts(). Esto evita que tx() se ejecute en use-after-free. Luego, Nicolai Stange encontró que más lugares en aoe tienen un posible problema de use-after-free con tx(). Por ejemplo, revalidate(), aoecmd_ata_rw(), resend(), probe() y aoecmd_cfg_rsp(). Esas funciones también usan aoenet_xmit() para enviar paquetes a la cola de tx. Por lo tanto, también deberían usar dev_hold() para aumentar el refcnt de skb->dev. Por otra parte, mover dev_put() a tx() hace que el refcnt de skb->dev se reduzca a un valor negativo, porque los dev_hold() correspondientes no se llaman en revalidate(), aoecmd_ata_rw(), resend(), probe() y aoecmd_cfg_rsp(). Este parche solucionó este problema.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49992)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/stm: Evite problemas de use after free con crtc y plane ltdc_load() llama a las funciones drm_crtc_init_with_planes(), drm_universal_plane_init() y drm_encoder_init(). Estas funciones no deben llamarse con parámetros asignados con devm_kzalloc() para evitar problemas de use after free [1]. Use asignaciones administradas por el marco DRM. Encontrado por Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49993)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Se corrige el bloqueo potencial si se llama a qi_submit_sync con un recuento de 0 Si se invoca qi_submit_sync() con 0 descriptores de invalidación (por ejemplo, para fines de vaciado de DMA), podemos encontrarnos con un error en el que un hilo de envío no detecta la finalización de invalidation_wait. Posteriormente, esto condujo a un bloqueo suave. Actualmente, este error no tiene impacto en los usuarios existentes porque ningún llamante está enviando invalidaciones con 0 descriptores. Esta corrección permitirá a los futuros usuarios (como DMA drain) llamar a qi_submit_sync() con un recuento de 0. Supongamos que el hilo T1 invoca qi_submit_sync() con descriptores distintos de cero, mientras que, al mismo tiempo, el hilo T2 llama a qi_submit_sync() con cero descriptores. Ambos hilos entran entonces en un bucle while, esperando a que se completen sus respectivos descriptores. T1 detecta su finalización (es decir, el estado invalidation_wait de T1 cambia a QI_DONE por HW) y procede a llamar a reclaim_free_desc() para recuperar todos los descriptores, incluyendo potencialmente los adyacentes de otros subprocesos que también están marcados como QI_DONE. Durante este tiempo, mientras T2 espera adquirir el qi->q_lock, el hardware IOMMU puede completar la invalidación para T2, estableciendo su estado en QI_DONE. Sin embargo, si la ejecución de reclaim_free_desc() por parte de T1 libera el descriptor invalidation_wait de T2 y cambia su estado a QI_FREE, T2 no observará el estado QI_DONE para su invalidation_wait y permanecerá bloqueado indefinidamente. Este bloqueo suave no ocurre cuando solo se envían descriptores distintos de cero. En tales casos, los descriptores de invalidación se intercalan entre los descriptores de espera con el estado QI_IN_USE, actuando como barreras. Estas barreras evitan que el código de recuperación libere por error descriptores que pertenecen a otros remitentes. Considere la siguiente línea de tiempo de ejemplo: T1 T2 ========================================= ID1 WD1 while(WD1!=QI_DONE) unlock lock WD1=QI_DONE* WD2 while(WD2!=QI_DONE) unlock lock WD1==QI_DONE? ID1=QI_DONE WD2=DONE* reclaim() ID1=FREE WD1=FREE WD2=FREE unlock soft lockup! T2 nunca ve QI_DONE en WD2 Donde: ID = descriptor de invalidación WD = descriptor de espera * Escrito por hardware La raíz del problema es que el indicador de estado del descriptor QI_DONE se usa para dos propósitos conflictivos: 1. señalar que un descriptor está listo para ser recuperado (para ser liberado) 2. señalar por el hardware que un descriptor de espera está completo La solución (en este parche) es la separación de estados mediante el uso del indicador QI_FREE para #1. Una vez que los descriptores de invalidación de un hilo están completos, su estado se establecería en QI_FREE. La función reclaim_free_desc() solo liberaría los descriptores marcados como QI_FREE en lugar de los marcados como QI_DONE. Este cambio asegura que T2 (del ejemplo anterior) observará correctamente la finalización de su invalidation_wait (marcada como QI_DONE).
  
• Vulnerabilidad en kernel de Linux (CVE-2024-49994)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corregir desbordamiento de entero en BLKSECDISCARD Descubrí de forma independiente el commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 bloque: corregir desbordamiento en blk_ioctl_discard() pero para borrado seguro. Mismo problema: uint64_t r[2] = {512, 18446744073709551104ULL}; ioctl(fd, BLKSECDISCARD, r); entrará en un bucle casi infinito dentro de blkdev_issue_secure_erase(): a.out: intento de acceso más allá del final del dispositivo loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 bio_check_eod: 3286214 devoluciones de llamadas suprimidas
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48970)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: Obtener user_ns de in_skb en unix_diag_get_exact(). Wei Chen informó una desreferencia NULL en sk_user_ns() [0][1], y Paolo diagnosticó la causa raíz: en unix_diag_get_exact(), el skb recién asignado no tiene sk. [2] Debemos obtener el user_ns de NETLINK_CB(in_skb).sk y pasarlo a sk_diag_fill(). [0]: ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000270 #PF: acceso de lectura del supervisor en modo núcleo #PF: error_code(0x0000) - página no presente PGD 12bbce067 P4D 12bbce067 PUD 12bc40067 PMD 0 Oops: 0000 [#1] PREEMPT SMP CPU: 0 PID: 27942 Comm: syz-executor.0 No contaminado 6.1.0-rc5-next-20221118 #2 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014 RIP: 0010:sk_user_ns include/net/sock.h:920 [en línea] RIP: 0010:sk_diag_dump_uid net/unix/diag.c:119 [en línea] RIP: 0010:sk_diag_fill+0x77d/0x890 net/unix/diag.c:170 Código: 89 ef e8 66 d4 2d fd c7 44 24 40 00 00 00 00 49 8d 7c 24 18 e8 54 d7 2d fd 49 8b 5c 24 18 48 8d bb 70 02 00 00 e8 43 d7 2d fd <48> 8b 9b 70 02 00 00 48 8d 7b 10 e8 33 d7 2d fd 48 8b 5b 10 48 8d RSP: 0018:ffffc90000d67968 EFLAGS: 00010246 RAX: ffff88812badaa48 RBX: 0000000000000000 RCX: ff840d481d RDX: 0000000000000465 RSI: 0000000000000000 RDI: 0000000000000270 RBP: ffffc90000d679a8 R08: 0000000000000277 R09: 0000000000000000 R10: 0001ffffffffffff R11: 0001c90000d679a8 R12: ffff88812ac03800 R13: ffff88812c87c400 R14: ffff88812ae42210 R15: ffff888103026940 FS: 00007f08b4e6f700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000270 CR3: 000000012c58b000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: unix_diag_get_exact net/unix/diag.c:285 [en línea] unix_diag_handler_dump+0x3f9/0x500 net/unix/diag.c:317 __sock_diag_cmd net/core/sock_diag.c:235 [en línea] sock_diag_rcv_msg+0x237/0x250 net/core/sock_diag.c:266 netlink_rcv_skb+0x13e/0x250 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x24/0x40 net/core/sock_diag.c:277 netlink_unicast_kernel net/netlink/af_netlink.c:1330 [en línea] netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1356 netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1932 sock_sendmsg_nosec net/socket.c:714 [en línea] sock_sendmsg net/socket.c:734 [en línea] ____sys_sendmsg+0x38f/0x500 net/socket.c:2476 ___sys_sendmsg net/socket.c:2530 [en línea] __sys_sendmsg+0x197/0x230 net/socket.c:2559 __do_sys_sendmsg net/socket.c:2568 [en línea] __se_sys_sendmsg net/socket.c:2566 [en línea] __x64_sys_sendmsg+0x42/0x50 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4697f9 Código: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 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 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f08b4e6ec48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000077bf80 RCX: 00000000004697f9 RDX: 000000000000000 RSI: 00000000200001c0 RDI: 000000000000003 RBP: 00000000004d29e9 R08: 0000000000000000 R09: 000000000000000 R10: 00000000000000000 R11: 0000000000000246 R12: 000000000077bf80 R13: 0000000000000000 R14: 000000000077bf80 R15: 00007ffdb36bc6c0 Módulos vinculados en: CR2: 0000000000000270 [1]: https://lore.kernel.org/netdev/CAO4mrfdvyjFpokhNsiwZiP-wpdSD0AStcJwfKcKQdAALQ9_2Qw@mail.gmail.com/ [2]: https://lore.kernel.org/netdev/e04315e7c90d9a75613f3993c2baf2d344eef7eb.camel@redhat.com/
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48971)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: Se solucionó el problema de no limpiar el led cuando bt_init fallo bt_init() llama a bt_leds_init() para registrar el led, pero si falla más tarde, no se llama a bt_leds_cleanup() para anular su registro. Esto puede causar pánico si se libera el argumento "bluetooth-power" en el texto y luego otro led_trigger_register() intenta acceder a él: ERROR: no se puede manejar el error de página para la dirección: ffffffffc06d3bc0 RIP: 0010:strcmp+0xc/0x30 Seguimiento de llamadas: led_trigger_register+0x10d/0x4f0 led_trigger_register_simple+0x7d/0x100 bt_init+0x39/0xf7 [bluetooth] do_one_initcall+0xd0/0x4e0
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48972)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mac802154: se corrige el INIT_LIST_HEAD faltante en ieee802154_if_add(). La prueba de inyección de errores del kernel informa null-ptr-deref de la siguiente manera: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000008 RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114 Seguimiento de llamadas: raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87 call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944 unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982 unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879 register_netdevice+0x9a8/0xb90 net/core/dev.c:10083 ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659 ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229 mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316 ieee802154_if_add() asigna wpan_dev como datos privados de netdev, pero No inicializa la lista en la estructura wpan_dev. cfg802154_netdev_notifier_call() administra la lista cuando se registra o cancela el registro del dispositivo y puede generar una desreferencia de PTR nula. Use INIT_LIST_HEAD() para inicializarla correctamente.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48973)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: amd8111: Se solucionó la fuga de recuento de referencia del dispositivo PCI. for_each_pci_dev() se implementa mediante pci_get_device(). El comentario de pci_get_device() dice que aumentará el recuento de referencia para el pci_dev devuelto y también disminuirá el recuento de referencia para el pci_dev de entrada @from si no es NULL. Si interrumpimos el bucle for_each_pci_dev() con pdev no NULL, debemos llamar a pci_dev_put() para disminuir el recuento de referencia. Agregue el pci_dev_put() faltante después de la etiqueta 'out'. Dado que pci_dev_put() puede manejar el parámetro de entrada NULL, no hay ningún problema para la rama 'Dispositivo no encontrado'. Para la ruta normal, agregue pci_dev_put() en amd_gpio_exit().
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48974)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: conntrack: corrección al usar __this_cpu_add en preemptible Actualmente en nf_conntrack_hash_check_insert(), cuando fallo en nf_ct_ext_valid_pre/post(), se llamará a NF_CT_STAT_INC() en el contexto preemptible, se puede activar un seguimiento de llamada: ERROR: uso de __this_cpu_add() en preemptible [00000000] código: conntrack/1636 el llamador es nf_conntrack_hash_check_insert+0x45/0x430 [nf_conntrack] Seguimiento de llamada: dump_stack_lvl+0x33/0x46 check_preemption_disabled+0xc3/0xf0 Este parche es para solucionarlo cambiando para usar NF_CT_STAT_INC_ATOMIC() para la comprobación de nf_ct_ext_valid_pre/post() en nf_conntrack_hash_check_insert(), así como nf_ct_ext_valid_post() en __nf_conntrack_confirm(). Tenga en cuenta que la comprobación de nf_ct_ext_valid_pre() en __nf_conntrack_confirm() es segura para usar NF_CT_STAT_INC(), ya que se encuentra bajo local_bh_disable().
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48983)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: Se corrige un null-ptr-deref en io_tctx_exit_cb() Syzkaller informa un error de desreferencia NULL de la siguiente manera: ERROR: KASAN: null-ptr-deref en io_tctx_exit_cb+0x53/0xd3 Lectura de tamaño 4 en la dirección 0000000000000138 por la tarea file1/1955 CPU: 1 PID: 1955 Comm: file1 No contaminado 6.1.0-rc7-00103-gef4d3ea40565 #75 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Seguimiento de llamadas: nivel_pila_volcado+0xcd/0x134 ? io_tctx_salir_cb+0x53/0xd3 informe_kasan+0xbb/0x1f0 ? io_tctx_salir_cb+0x53/0xd3 rango_comprobación_kasan+0x140/0x190 io_tctx_salir_cb+0x53/0xd3 ejecución_trabajo_tarea+0x164/0x250 ? cancelación_trabajo_tarea+0x30/0x30 obtener_señal+0x1c3/0x2440 ? degradación_bloqueo+0x6e0/0x6e0 ? degradación_bloqueo+0x6e0/0x6e0 ? señales_salida+0x8b0/0x8b0 ? desbloqueo_lectura_sin_datos+0x3b/0x70 ? obtener_sigframe_size+0x10/0x10 ? bloquear_hardirqs_on+0x79/0x100 ? poner_nombre+0xfe/0x140 ? do_execveat_common.isra.0+0x238/0x710 exit_to_user_mode_prepare+0x15f/0x250 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x42/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0023:0x0 Código: No se puede acceder a los bytes del código de operación en 0xffffffffffffffd6. RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000b RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000000 RDI: 000000000000000 RBP: 000000000000000 R08: 0000000000000000 R09: 00000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Pánico del kernel: no se sincroniza: panic_on_warn establecido ... Esto sucede porque la adición de task_work desde io_ring_exit_work() no está sincronizada con la cancelación de todos los elementos de trabajo, por ejemplo, de exec. La ejecución de los dos está ordenada de manera que ambos son ejecutados por la propia tarea, pero si io_tctx_exit_cb() está en cola mientras cancelamos todos los elementos de trabajo de exec Y se ejecuta cuando la tarea sale al espacio de usuario en lugar de en el bucle principal en io_uring_cancel_generic(), entonces podemos encontrar current->io_uring == NULL y alcanzar el bloqueo anterior. Es seguro agregar esta verificación NULL aquí, porque la ejecución de las dos rutas las realiza la propia tarea. [axboe: agregue un comentario de código y también coloque una explicación en el mensaje de confirmación]
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48984)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: slcan: fix freed work crash La prueba LTP pty03 está provocando un fallo en slcan: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 01/04/2014 Cola de trabajo: 0x0 (eventos) RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) Código: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 RAX: 000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 FS: 000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 Seguimiento de llamadas: worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436) kthread (/home/rich/kernel/linux/kernel/kthread.c:376) ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312) Aparentemente, el tx_work de slcan se libera mientras se programa. Mientras que slcan_netdev_close() (lado netdev) llama a flush_work(&sl->tx_work), slcan_close() (lado tty) no lo hace. Entonces, cuando el netdev nunca se configura, pero el tty está lleno de bytes y se lo obliga a activar la escritura, el trabajo se programa, pero nunca se vacía. Por lo tanto, agregue un flush_work() adicional a slcan_close() para asegurarse de que el trabajo se vacía en todas las circunstancias. el commit de correcciones a continuación movió flush_work() de slcan_close() a slcan_netdev_close(). ¿Cuál fue la razón detrás de esto? ¿Quizás podamos eliminar el que está en slcan_netdev_close()? Veo el mismo patrón en can327. Entonces, tal vez necesite la misma corrección.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48989)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fscache: Corregir oops debido a ejecución con cookie_lru y use_cookie Si una cookie caduca desde la LRU y el indicador LRU_DISCARD está configurado, pero la máquina de estado aún no se ha ejecutado, es posible que otro hilo pueda llamar a fscache_use_cookie y comenzar a usarlo. Cuando finalmente se ejecuta cookie_worker, verá el indicador LRU_DISCARD configurado, hará la transición de cookie->state a LRU_DISCARDING, que luego retirará la cookie. Una vez que se retira la cookie, se elimina el objeto, se producirán los siguientes oops porque el objeto asociado con la cookie ahora es NULL. Corrija los oops borrando el bit LRU_DISCARD si otro hilo usa la cookie antes de que se ejecute cookie_worker. ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000008 ... CPU: 31 PID: 44773 Comm: kworker/u130:1 Contaminado: GE 6.0.0-5.dneg.x86_64 #1 Nombre del hardware: Google Compute Engine/Google Compute Engine, BIOS Google 26/08/2022 Cola de trabajo: events_unbound netfs_rreq_write_to_cache_work [netfs] RIP: 0010:cachefiles_prepare_write+0x28/0x90 [cachefiles] ... Seguimiento de llamadas: netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs] process_one_work+0x217/0x3e0 worker_thread+0x4a/0x3b0 hilo+0xd6/0x100
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48990)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corregir el use after free durante la recuperación de la GPU [Por qué] [ 754.862560] refcount_t: desbordamiento; use after free. [ 754.862898] Seguimiento de llamadas: [ 754.862903] [ 754.862913] amdgpu_job_free_cb+0xc2/0xe1 [amdgpu] [ 754.863543] drm_sched_main.cold+0x34/0x39 [amd_sched] [Cómo] Es posible que fw_fence no se inicialice, verifique si dma_fence_init se realiza antes de la liberación del trabajo
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48992)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: soc-pcm: Agregar comprobación NULL en la reparentalización de BE Agregar comprobación NULL en la API dpcm_be_reparent para manejar el error de desreferencia de puntero NULL del kernel. El problema se produjo en la prueba de fuzzing.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48995)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: raydium_ts_i2c - arregla pérdida de memoria en raydium_i2c_send() Hay una pérdida de kmem cuando se prueba raydium_i2c_ts con bpf mock device: unreferenced object 0xffff88812d3675a0 (size 8): comm "python3", pid 349, jiffies 4294741067 (age 95.695s) hex dump (first 8 bytes): 11 0e 10 c0 01 00 04 00 ........ backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000006e631aee>] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] dispositivo_de_sonda_de_controlador+0x49/0x120 [<00000000264fe082>] __controlador_de_adjuntar_dispositivo+0xf7/0x150 [<00000000f919423c>] bus_para_cada_unidad+0x114/0x180 [<00000000e067feca>] __adjuntar_dispositivo+0x1e5/0x2d0 [<0000000054301fc2>] dispositivo_de_sonda_de_bus+0x126/0x140 [<00000000aad93b22>] dispositivo_agregar+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 objeto sin referencia 0xffff88812d3675c8 (tamaño 8): comm "python3", pid 349, jiffies 4294741070 (antigüedad 95,692 s) volcado hexadecimal (primeros 8 bytes): 22 00 36 2d 81 88 ff ff ".6-.... traza inversa: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000001d5c9620>] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] realmente_sondeo+0x17c/0x3f0 [<00000000096ba499>] __dispositivo_de_sonda_de_controlador+0xe3/0x170 [<00000000c5acb4d9>] dispositivo_de_sonda_de_controlador+0x49/0x120 [<00000000264fe082>] __dispositivo_adjunto_controlador+0xf7/0x150 [<00000000f919423c>] bus_para_cada_unidad+0x114/0x180 [<00000000e067feca>] __dispositivo_adjunto+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 Después del comando BANK_SWITCH del BUS i2c, sin importar si se produjo un éxito o un error, se debe liberar el tx_buf.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49002)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Se corrige la pérdida de recuento de referencias del dispositivo PCI en dmar_dev_scope_init(). for_each_pci_dev() se implementa mediante pci_get_device(). El comentario de pci_get_device() dice que aumentará el recuento de referencias para el pci_dev devuelto y también disminuirá el recuento de referencias para el pci_dev de entrada @from si no es NULL. Si interrumpimos el bucle for_each_pci_dev() con pdev no NULL, debemos llamar a pci_dev_put() para disminuir el recuento de referencias. Agregue el pci_dev_put() faltante para la ruta de error para evitar la pérdida del recuento de referencias.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49003)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme: se corrige la protección SRCU de la lista nvme_ns_head El recorrido por la lista de hermanos nvme_ns_head está protegido por el srcu del cabezal en nvme_ns_head_submit_bio() pero no por nvme_mpath_revalidate_paths(). La eliminación de espacios de nombres de la lista también fallo al sincronizar el srcu. Por lo tanto, el trabajo de escaneo simultáneo puede causar use-after-free. Mantenga el bloqueo del srcu del cabezal en nvme_mpath_revalidate_paths() y sincronice con el srcu, no con el RCU global, en nvme_ns_remove(). Se observó el siguiente pánico al realizar conexiones NVMe/RDMA con multipath nativo en el kernel Rocky Linux 8.6 (parece que el kernel ascendente tiene la misma condición de ejecución). El desensamblaje muestra que la instrucción que fallo es cmp 0x50(%rdx),%rcx; capacidad de cómputo != get_capacity(ns->disk). La dirección 0x50 está desreferenciada porque ns->disk es NULL. El disco NULL parece ser el resultado de un trabajo de escaneo simultáneo que libera el espacio de nombres (observe la línea de registro en el medio del pánico). [37314.206036] ERROR: no se puede manejar la desreferencia del puntero NULL del núcleo en 0000000000000050 [37314.206036] nvme0n3: se detectó un cambio de capacidad de 0 a 11811160064 [37314.299753] PGD 0 P4D 0 [37314.299756] Oops: 0000 [#1] SMP PTI [37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: cargado Tainted: GWX --------- - - 4.18.0-372.32.1.el8test86.x86_64 #1 [37314.299762] Nombre del hardware: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 23/05/2018 [37314.299763] Cola de trabajo: nvme-wq nvme_scan_work [nvme_core] [37314.299783] RIP: 0010:nvme_mpath_revalidate_paths+0x26/0xb0 [nvme_core] [37314.299790] Código: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 <48> 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3 [37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202 [37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000 [37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800 [37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff [37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 000000000000000 [37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000 [37315.548286] FS: 0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000 [37315.645111] CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 [37315.713871] CR2: 000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0 [37315.799267] Seguimiento de llamadas: [37315.828515] nvme_update_ns_info+0x1ac/0x250 [núcleo_nvme] [37315.892075] nvme_validate_or_alloc_ns+0x2ff/0xa00 [núcleo_nvme] [37315.961871] ? __blk_mq_free_request+0x6b/0x90 [37316.015021] nvme_scan_work+0x151/0x240 [núcleo_nvme] [37316.073371] process_one_work+0x1a7/0x360 [37316.121318] ? crear_trabajador+0x1a0/0x1a0 [37316.168227] subproceso_trabajador+0x30/0x390 [37316.212024] ? crear_trabajador+0x1a0/0x1a0 [37316.258939] kthread+0x10a/0x120 [37316.297557] ? Módulos vinculados en: nvme_rdma nvme_tcp(X) nvme_fabrics nvme_core netconsole iscsi_tcp libiscsi_tcp dm_queue_length dm_service_time nf_conntrack_netlink br_netfilter bridge stp llc superposición nft_chain_nat ipt_MASQUERADE nf_nat xt_addrtype xt_CT nft_counter xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment xt_multiport nft_compat nf_tables libcrc32c nfnetlink dm_multipath tg3 rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm intel_rapl_msr iTCO_wdt iTCO_vendor_support dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm irqbypass crct10dif_pclmul crc32_pclmul mlx5_ib ghash_clmulni_intel ib_uverbs rapl intel_cstate intel_uncore ib_core ipmi_si joydev mei_me---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49004)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: Sincronizar las asignaciones de kernel de la tabla de páginas efi antes de cambiar La tabla de páginas efi se crea inicialmente como una copia de la tabla de páginas del kernel. Con VMAP_STACK habilitado, las pilas del kernel se asignan en el área vmalloc: si la pila se asigna en un nuevo PGD (uno que no estaba presente en el momento de la creación de la tabla de páginas efi o no se sincronizó en un error vmalloc anterior), el kernel tomará una trampa al cambiar a la tabla de páginas efi cuando se accede a la pila del kernel vmalloc, lo que resulta en un pánico del kernel. Solucione eso actualizando las asignaciones de kernel efi antes de cambiar a la tabla de páginas efi.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49005)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: ops: Fix bounds check for _sx controls Para los controles _sx, la semántica del campo max no es la habitual, max es el número de pasos en lugar del valor máximo. Esto significa que nuestra comprobación en snd_soc_put_volsw_sx() solo debe comprobarse con el valor máximo.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49006)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: Búferes libres cuando se elimina un evento dinámico usado Después de que se hayan agregado y eliminado 65536 eventos dinámicos, el campo "tipo" del evento usa el primer número de tipo que está disponible (no usado actualmente por otros eventos). Un número de tipo es el identificador de los blobs binarios en el búfer de anillo de rastreo (conocidos como eventos) para mapearlos a la lógica que puede analizar el blob binario. El problema es que si se rastrea un evento dinámico (como un evento kprobe) y está en el búfer de anillo, y luego ese evento se elimina (porque es dinámico, lo que significa que se puede crear y destruir), si se crea otro evento dinámico que tenga el mismo número, se usará la lógica de ese nuevo evento al analizar el blob binario. Para mostrar cómo esto puede ser un problema, lo siguiente puede bloquear el kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; Para cada iteración de lo anterior, la escritura en kprobe_events eliminará el evento anterior y creará uno nuevo (con el mismo formato) y aumentará el número de tipo al siguiente disponible hasta que el número de tipo alcance más de 65535, que es el número máximo para el tipo de 16 bits. Después de que alcanza ese número, la lógica para asignar un nuevo número simplemente busca el siguiente número disponible. Cuando se elimina un evento dinámico, ese número está disponible para ser reutilizado por el próximo evento dinámico creado. Es decir, una vez que lo anterior alcanza el número máximo, el número asignado al evento en ese bucle seguirá siendo el mismo. Ahora, eso significa que eliminar un evento dinámico y crear otro reutilizará el número de tipo de eventos anteriores. Aquí es donde pueden suceder cosas malas. Después de que finaliza el bucle anterior, el evento kprobes/foo que lee el primer parámetro de la llamada a la función do_sys_openat2 como un entero. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat seguimiento cat-2211 [005] .... 2007.849603: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Ahora si borramos el kprobe y creamos uno nuevo que lea una cadena: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events Y ahora podemos hacer el trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1="????????????????????????????????????????????? ????????????????????????????????????????????????????????????????" cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1="????????????????????????????????????????????? ??????????????????????????????????????????????????????????????????" cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1="????????????????????????????????????????????? ??????????????????????????????????????????????????" cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1="????????????????????????????????????????? ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49007)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige la desreferencia de puntero NULL en nilfs_palloc_commit_free_entry() Syzbot informó un error de desreferencia de puntero nulo: NILFS (loop0): segctord iniciando. Intervalo de construcción = 5 segundos, frecuencia de CP < 30 segundos. fallo de protección general, probablemente para dirección no canónica 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en rango [0x000000000000010-0x0000000000000017] CPU: 1 PID: 3603 Comm: segctord No contaminado 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Nombre del hardware: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0 fs/nilfs2/alloc.c:608 Código: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 05 00 00 49 8b 46 10 ser a6 00 00 00 48 c7 c7 RSP: 0018:ffffc90003dff830 EFLAGS: 00010212 RAX: dffffc00000000000 RBX: ffff88802594e218 RCX: 000000000000000d RDX: 00000000000000002 RSI: 0000000000002000 RDI: 0000000000000010 RBP: ffff888071880222 R08: 000000000000005 R09: 000000000000003f R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158 R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004 FS: 000000000000000(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0 Seguimiento de llamadas: nilfs_dat_commit_free fs/nilfs2/dat.c:114 [en línea] nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193 nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236 nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940 nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [en línea] nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [en línea] nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088 nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337 nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568 nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018 nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [en línea] nilfs_segctor_collect fs/nilfs2/segment.c:1503 [en línea] nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045 nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [en línea] nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 ... Si el archivo de metadatos DAT está dañado en el disco, existe un caso en el que req->pr_desc_bh es NULL y blocknr es 0 en nilfs_dat_commit_end() durante una operación de árbol b que actualiza en cascada los nodos ancestros del árbol b, porque nilfs_dat_commit_alloc() para un bloque de nivel inferior puede inicializar el blocknr en la misma entrada DAT entre nilfs_dat_prepare_end() y nilfs_dat_commit_end(). Si esto sucede, nilfs_dat_commit_end() llama a nilfs_dat_commit_free() sin encabezados de búfer válidos en req->pr_desc_bh y req->pr_bitmap_bh, y provoca la desreferencia del puntero NULL anterior en la función nilfs_palloc_commit_free_entry(), lo que provoca un bloqueo. Solucione este problema agregando una comprobación NULL en req->pr_desc_bh y req->pr_bitmap_bh antes de nilfs_palloc_commit_free_entry() en nilfs_dat_commit_free(). Esto también llama a nilfs_error() en ese caso para notificar que hay un fallo fatal en los metadatos del sistema de archivos y evitar operaciones futuras.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49008)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: can327: can327_feed_frame_to_netdev(): corrige una posible fuga de skb cuando netdev está inactivo En can327_feed_frame_to_netdev(), no liberaba el skb cuando netdev estaba inactivo, y todos los que llamaban a can327_feed_frame_to_netdev() tampoco liberaban el skb asignado. Eso desencadenaría una fuga de skb. Arréglelo añadiendo kfree_skb() en can327_feed_frame_to_netdev() cuando netdev esté inactivo. No probado, solo compilado.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50019)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kthread: unpark solo kthread aparcado Llamar a kthread unparking incondicionalmente es mayormente inofensivo cuando el kthread ya está desestacionado. Luego, la activación simplemente se ignora porque el objetivo no está en estado TASK_PARKED. Sin embargo, si el kthread es por CPU, la activación está precedida por una llamada a kthread_bind() que espera que la tarea esté inactiva y en estado TASK_PARKED, lo que obviamente no es el caso si está desestacionada. Como resultado, llamar a kthread_stop() en un kthread por CPU no estacionado activa esta advertencia: ADVERTENCIA: CPU: 0 PID: 11 en kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 kthread_stop+0x17a/0x630 kernel/kthread.c:707 destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 ops_exit_list net/core/net_namespace.c:178 [en línea] cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 process_one_work kernel/workqueue.c:3231 [en línea] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Solucione esto omitiendo el desestacionamiento innecesario mientras Detener un kthread.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50020)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: Se corrige el manejo incorrecto de refcount en ice_sriov_set_msix_vec_count() Este parche soluciona un problema con el manejo incorrecto del recuento de referencias en la función ice_sriov_set_msix_vec_count(). Primero, la función llama a ice_get_vf_by_id(), que incrementa el recuento de referencias del puntero vf. Si la llamada posterior a ice_get_vf_vsi() fallo, la función actualmente devuelve un error sin disminuir el recuento de referencias del puntero vf, lo que lleva a una pérdida del recuento de referencias. El comportamiento correcto, como se implementó en este parche, es disminuir el recuento de referencias usando ice_put_vf(vf) antes de devolver un error cuando vsi es NULL. En segundo lugar, la función llama a ice_sriov_get_irqs(), que establece vf->first_vector_idx. Si esta llamada devuelve un valor negativo, lo que indica un error, la función devuelve un error sin disminuir el recuento de referencia del puntero vf, lo que genera otra pérdida de recuento de referencia. El parche soluciona este problema agregando una llamada a ice_put_vf(vf) antes de devolver un error cuando vf->first_vector_idx < 0. Este error fue identificado por una herramienta de análisis estático experimental desarrollada por nuestro equipo. La herramienta se especializa en analizar operaciones de recuento de referencia e identificar posibles errores de administración de los recuentos de referencia. En este caso, la herramienta marcó la operación de disminución faltante como un problema potencial, lo que llevó a este parche.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50021)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: Se corrige el manejo incorrecto de refcount en ice_dpll_init_rclk_pins() Este parche soluciona un problema de manejo de recuento de referencias en la función ice_dpll_init_rclk_pins(). La función llama a ice_dpll_get_pins(), que incrementa el recuento de referencias de los recursos relevantes. Sin embargo, si se cumple la condición WARN_ON((!vsi || !vsi->netdev)), la función actualmente devuelve un error sin liberar correctamente los recursos adquiridos por ice_dpll_get_pins(), lo que lleva a una pérdida de recuento de referencias. Para resolver esto, la comprobación se ha movido a la parte superior de la función. Esto garantiza que la función verifique el estado antes de que se adquieran recursos, lo que evita la necesidad de una gestión de recursos adicional en la ruta de error. Este error fue identificado por una herramienta de análisis estático experimental desarrollada por nuestro equipo. La herramienta se especializa en analizar operaciones de recuento de referencias y detectar posibles problemas donde los recursos no se administran correctamente. En este caso, la herramienta marcó la operación de liberación faltante como un problema potencial, lo que llevó al desarrollo de este parche.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50022)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: device-dax: alineación correcta de pgoff en dax_set_mapping() pgoff debe alinearse usando ALIGN_DOWN() en lugar de ALIGN(). De lo contrario, vmf->address no alineado con fault_size se alineará con la siguiente alineación, lo que puede provocar que El fallo de memoria obtenga la dirección incorrecta. Es una situación sutil que solo se puede observar en page_mapped_in_vma() después de que dev_dax_huge_fault gestione El fallo de página. Generalmente, hay pocas posibilidades de realizar page_mapped_in_vma en la página de dev-dax a menos que se trate de una inyección de error específica en el dispositivo dax para activar un MCE (fallo de memoria). En ese caso, se activará page_mapped_in_vma() para determinar qué tarea está accediendo a la dirección de fallo y matar esa tarea al final. Usamos un dispositivo dax desarrollado por nosotros mismos (que es un mapeo alineado de 2M) para realizar una inyección de error en una dirección aleatoria. Resultó que el error inyectado en una dirección no alineada a 2M estaba causando un MCE interminable hasta que surgió el pánico. Debido a que page_mapped_in_vma() seguía generando una dirección incorrecta y la tarea que accedía a la dirección fallida nunca se finalizaba correctamente: [3783.719419] Error de memoria: 0x200c9742: acción de recuperación para la página dax: recuperada [3784.049006] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [3784.049190] Error de memoria: 0x200c9742: acción de recuperación para la página dax: recuperada [3784.448042] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [3784.448186] Error de memoria: 0x200c9742: acción de recuperación para la página dax: recuperada [3784.792026] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [3784.792179] Error de memoria: 0x200c9742: acción de recuperación para la página dax: Recuperado [3785.162502] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [3785.162633] Error de memoria: 0x200c9742: acción de recuperación para la página dax: Recuperado [3785.461116] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [3785.461247] Error de memoria: 0x200c9742: acción de recuperación para la página dax: Recuperado [3785.764730] mce: Error de memoria de hardware sin corregir en acceso de usuario en 200c9742380 [3785.764859] Error de memoria: 0x200c9742: acción de recuperación para la página dax: Recuperado [3786.042128] mce: Error de memoria de hardware sin corregir en acceso de usuario en 200c9742380 [3786.042259] Error de memoria: 0x200c9742: acción de recuperación para la página dax: Recuperado [3786.464293] mce: Error de memoria de hardware sin corregir en acceso de usuario en 200c9742380 [3786.464423] Error de memoria: 0x200c9742: acción de recuperación para la página dax: Recuperado [3786.818090] mce: Error de memoria de hardware sin corregir en acceso de usuario en 200c9742380 [ 3786.818217] Error de memoria: 0x200c9742: acción de recuperación para la página dax: Recuperado [ 3787.085297] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [ 3787.085424] Error de memoria: 0x200c9742: acción de recuperación para la página dax: Recuperado Nos llevó varias semanas localizar este problema, pero finalmente usamos bpftrace para rastrear El fallo de página y la dirección mce e identificamos el problema con éxito. Joao agregó: ; Es probable que nunca lo reproduzcamos en producción porque siempre fijamos : las regiones device-dax en la alineación de región que proporcionan (Qemu hace : de manera similar con prealloc en la memoria respaldada por hugetlb/archivo). Creo que este error requiere que toquemos regiones del dispositivo DAX *no fijadas* que no estén alineadas con la alineación seleccionada del dispositivo DAX (tamaño de página, es decir, 4K/2M/1G)
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50023)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: Eliminar la entrada LED de la lista de LED al anular el registro El commit c938ab4da0eb ("net: phy: Eliminar manualmente los LED para garantizar el orden correcto") corrigió correctamente un problema con el uso de devm_ pero no eliminó la entrada LED de la lista de LED. Esto causa pánico del kernel en un escenario específico donde el puerto para el PHY se desactiva y activa y se elimina el kmod para el PHY. Al desactivar el puerto la primera vez, los LED asociados se anulan correctamente el registro. El kmod asociado para el PHY ahora se elimina. El kmod ahora se agrega nuevamente y el puerto ahora se activa, los LED asociados se registran nuevamente. Al desactivar el puerto nuevamente por segunda vez después de estos pasos, la lista de LED ahora tiene 4 elementos. Con los primeros 2 ya anulados previamente y los 2 nuevos registrados nuevamente. Esto causa un pánico del kernel ya que los primeros 2 elementos deberían haberse eliminado. Arregle esto eliminando correctamente el elemento cuando el LED no está registrado.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50024)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: Corrige un bucle inseguro en la lista El kernel puede bloquearse al eliminar una familia genetlink si aún hay oyentes para esa familia: Oops: Acceso al kernel al área incorrecta, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Rastreo de llamadas: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Cambia el bucle inseguro en la lista a uno seguro, porque dentro del bucle hay una eliminación de elementos de esta lista.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50025)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: fnic: mover la inicialización de flush_work fuera del bloque if Después de el commit 379a58caa199 ("scsi: fnic: mover fnic_fnic_flush_tx() a una cola de trabajo"), puede suceder que un elemento de trabajo se envíe a una cola de trabajo no inicializada. Esto puede tener el efecto de que el elemento que se está poniendo en cola nunca se ponga en cola y cualquier acción posterior que dependa de él no se lleve a cabo. Se observa la siguiente advertencia mientras se carga el controlador fnic: kernel: ADVERTENCIA: CPU: 11 PID: 0 en ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: Se ha observado que esto puede interrumpir el redescubrimiento de dispositivos Fibre Channel después de un fallo temporal de la estructura. Este parche lo soluciona moviendo la inicialización de la cola de trabajo fuera de un bloque if en fnic_probe().
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50026)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: wd33c93: No usar valor scsi_pointer obsoleto Se introdujo una regresión con el commit dbb2da557a6a ("scsi: wd33c93: Mover el puntero SCSI a datos de comando privados") que da como resultado un error en wd33c93_intr(). Esa confirmación agregó la variable scsi_pointer y la inicializó desde hostdata->connected. Sin embargo, durante la selección, hostdata->connected aún no es válido. Solucione esto obteniendo el scsi_pointer actual desde hostdata->selecting.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50027)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: thermal: core: copia libre de tzp junto con la zona térmica. Aún se puede acceder al objeto al que apunta tz->tzp después de liberarlo en thermal_zone_device_unregister(), por lo que debe mover su liberación al punto después de que se haya completado la eliminación en el que ya no se pueda acceder a él.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50028)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: thermal: core: recuento de referencia de la zona en thermal_zone_get_by_id() Hay lugares en el código de netlink térmico donde nada impide que el objeto de zona térmica desaparezca mientras se accede a él después de que thermal_zone_get_by_id() lo haya devuelto. Para solucionar esto, haga que thermal_zone_get_by_id() obtenga una referencia en el objeto de dispositivo de zona térmica que se devolverá con la ayuda de get_device(), bajo thermal_list_lock, y ajuste todos sus llamadores a este cambio con la ayuda de la infraestructura cleanup.h.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50029)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_conn: Fix UAF en hci_enhanced_setup_sync Esto verifica si la conexión ACL sigue siendo válida, ya que podría destruirse mientras hci_enhanced_setup_sync está pendiente de cmd_sync, lo que genera el siguiente seguimiento: ERROR: KASAN: slab-use-after-free en hci_enhanced_setup_sync+0x91b/0xa60 Lectura de tamaño 1 en la dirección ffff888002328ffd por la tarea kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 No contaminado 6.11.0-rc6-01300-g810be445d8d6 #7099 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 01/04/2014 Cola de trabajo: hci0 hci_cmd_sync_work Seguimiento de llamadas: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? asignar_trabajo+0x167/0x240 subproceso_trabajador+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? Asignado por la tarea 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entrada_SYSCALL_64_after_hwframe+0x76/0x7e Liberado por la tarea 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_de_la_bifurcación+0x2f/0x70 ret_de_la_bifurcación_asm+0x1a/0x30
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50030)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/ct: evitar UAF en send_recv() Asegurarnos de que serializamos con el lado de finalización para evitar que UAF con valla salga del ámbito en la pila, ya que no tenemos ni idea de si se activará después del tiempo de espera antes de que podamos borrar del xa. También tenemos algunas cargas y almacenamientos dependientes para los que necesitamos el orden correcto, y carecemos de las barreras necesarias. Arregla esto tomando el ct->lock después de la espera, que también está retenido por el lado de finalización. v2 (Badal): - También se imprime después de adquirir el bloqueo y ver el tiempo de espera. (seleccionado de el commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50031)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/v3d: Detener el perfmon activo antes de ser destruido Al ejecutar `kmscube` con uno o más monitores de rendimiento habilitados a través de `GALLIUM_HUD`, puede ocurrir el siguiente pánico del kernel: [ 55.008324] No se puede manejar la solicitud de paginación del kernel en la dirección virtual 00000000052004a4 [ 55.008368] Información de aborto de memoria: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (EL actual), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: error de traducción de nivel 1 [ 55.008434] Información de interrupción de datos: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] pgtable de usuario: páginas de 4k, VA de 39 bits, pgdp=00000001046c6000 [ 55.008497] [000000000052004a4] pgd=0000000000000000, p4d=00000000000000000, pud=0000000000000000 [ 55.008525] Error interno: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Módulos vinculados en: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Contaminado: GC 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Nombre del hardware: Raspberry Pi 4 Modelo B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9: ffffffda1bd04d04 [55.011162] x8: ffffff8102097b80 x7: 0000000000000000 x6: 00000000030a5857 [55.011880] x5: 00ffffffffffffff x4: 0300000005200470 x3: 0300000005200470 [55.012598] x2: ffffff8101238000 x1: 0000000000000021 x0 : 0300000005200470 [ 55.013292] Rastreo de llamadas: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Código: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ fin del seguimiento 000000000000000 ]--- [ 55.020411] nota: v3d_bin[166] salió con preempt_count 1 Este problema surge porque, al cerrar el descriptor de archivo (lo que sucede cuando interrumpimos `kmscube`), el monitor de rendimiento activo no se detiene. Aunque todos los monitores de rendimiento se destruyen en `v3d_perfmon_close_file()`, el puntero del monitor de rendimiento activo (`v3d->active_perfmon`) aún se conserva. Si se ejecuta de nuevo `kmscube`, el controlador intentará detener el monitor de rendimiento activo utilizando el puntero obsoleto en `v3d->active_perfmon`. Sin embargo, este puntero ya no es válido porque el proceso anterior ya ha finalizado y todos los monitores de rendimiento asociados con él se han destruido y liberado. Para solucionar esto, cuando el monitor de rendimiento activo pertenece a un proceso determinado, deténgalo explícitamente antes de destruirlo y liberarlo.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50032)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rcu/nocb: Se ha corregido la activación de rcuog desde un softirq sin conexión. Después de que una CPU se haya desconectado y antes de que finalmente llame a rcutree_report_cpu_dead(), aún hay oportunidades para que se pongan en cola devoluciones de llamadas, por ejemplo, desde un softirq. Cuando eso sucede en NOCB, la activación de rcuog se pospone a través de una IPI a una CPU en línea para no llamar al programador y correr el riesgo de armar el ancho de banda RT después de que los temporizadores hr se hayan migrado y deshabilitado. Pero realizar una IPI sincronizada desde un softirq tiene errores, como se informa en el siguiente escenario: ADVERTENCIA: CPU: 1 PID: 26 en kernel/smp.c:633 smp_call_function_single Módulos vinculados en: rcutorture torture CPU: 1 UID: 0 PID: 26 Comm: immigration/1 No contaminado 6.11.0-rc1-00012-g9139f93209d1 #1 Detenedor: multi_cpu_stop+0x0/0x320 <- __stop_cpus+0xd0/0x120 RIP: 0010:smp_call_function_single swake_up_one_online __call_rcu_nocb_wake __call_rcu_common ? rcu_torture_one_read call_timer_fn __run_timers run_timer_softirq handle_softirqs irq_exit_rcu ? tick_handle_periodic sysvec_apic_timer_interrupt Solucione esto forzando la activación diferida de rcuog a través del temporizador NOCB cuando la CPU esté fuera de línea. La activación real se realizará desde rcutree_report_cpu_dead().
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50036)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: no retrasar dst_entries_add() en dst_release() dst_entries_add() usa datos por CPU que podrían liberarse en el desmantelamiento de netns de ip6_route_net_exit() llamando a dst_entries_destroy() Antes de que se pueda llamar a ip6_route_net_exit(), liberamos todos los dst asociados con este netns, a través de llamadas a dst_release(), que espera un período de gracia de rcu antes de llamar a dst_destroy() El uso de dst_entries_add() en dst_destroy() es arriesgado, porque dst_entries_destroy() ya podría haberse llamado. La disminución del número de dst debe ocurrir antes. Notas: 1) en el caso de CONFIG_XFRM, dst_destroy() puede llamar a dst_release_immediate(child), lo que también podría causar UAF si el hijo no tiene DST_NOCOUNT configurado. Los encargados del mantenimiento de IPSEC podrían echar un vistazo y ver cómo solucionar esto. 2) También se está discutiendo sobre la eliminación de este recuento de dst, lo que podría suceder en kernels futuros.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50037)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/fbdev-dma: Solo limpiar la E/S diferida si es necesario el commit 5a498d4d06d6 ("drm/fbdev-dma: Solo instalar la E/S diferida si es necesario") inicializa la E/S diferida solo si se usa. Sin embargo, drm_fbdev_dma_fb_destroy() llama a fb_deferred_io_cleanup() incondicionalmente con struct fb_info.fbdefio == NULL. KASAN con el controlador de pantalla de silicio de Apple fuera del árbol publica la siguiente advertencia de __flush_work() de una estructura aleatoria work_struct en lugar de las derefs de puntero NULL esperadas. [ 22.053799] ------------[ cortar aquí ]------------ [ 22.054832] ADVERTENCIA: CPU: 2 PID: 1 en kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Módulos vinculados en: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow No contaminado 6.11.2-asahi+ #asahi-dev [ 22.075612] Nombre del hardware: Apple MacBook Pro (13 pulgadas, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ [22.080345] sp: ffffc000836ef820 [22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [22.082678] x26: dfffc0000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [22.084263] x23: ffff80004b7862b8 x22: dfffc0000000000 x21: ffff80005aa1d470 [22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9: 1ffff800106ddf0e [22.092206] x8: 0000000000000000 x7: aaaaaaaaaaaaaaaa x6: 0000000000000001 [22.093790] x5: 00836ef728 x4: 0000000000000000 x3: 0000000000000020 [22.095368] x2: 00000000000000008 x1: 00000000000000aa x0: 00000000000000000 [ 22.096955] Rastreo de llamadas: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] anular registro de búfer de fotogramas+0x210/0x2f0 [ 22.102575] drm_fb_helper_anular registro de información+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] apagado_dispositivo+0x368/0x4d8 [ 22.112095] reinicio_kernel+0x6c/0x1d0 [ 22.112946] reinicio_del_sistema_arm64+0x1c8/0x328 [ 22.113868] invocar_llamada_al_sistema+0x78/0x1a8 [ 22.114703] hacer_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] controlador_sincronización_el0t_64+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ fin de seguimiento 0000000000000000 ]---
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50038)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: xtables: evita NFPROTO_UNSPEC donde sea necesario syzbot logró llamar a xt_cluster match a través de ebtables: ADVERTENCIA: CPU: 0 PID: 11 en net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 El módulo se registra en NFPROTO_UNSPEC, pero asume el procesamiento de paquetes ipv4/ipv6. Como esto solo es útil para restringir el tráfico TCP/UDP que termina localmente, regístrelo solo para la familia ipv4 e ipv6. Pablo señala que este es un problema general, los usuarios directos de la interfaz set/getsockopt pueden llamar a destinos/coincidencias que solo estaban destinados a usarse con tablas ip(6). Compruebe todas las coincidencias y objetivos UNSPEC para ver si hay problemas similares: - las coincidencias y los objetivos están bien excepto si asumen que skb_network_header() es válido - esto solo es cierto cuando se llama desde la capa inet: la pila ip(6) extrae el encabezado ip/ipv6 en el área de datos lineales. - los objetivos que devuelven XT_CONTINUE u otros veredictos de xtables también deben restringirse, son incompatibles con el traverser de ebtables, por ejemplo, EBT_CONTINUE es un valor completamente diferente de XT_CONTINUE. La mayoría de las coincidencias/objetivos se cambian para registrarse para NFPROTO_IPV4/IPV6, ya que se proporcionan para su uso por ip(6)tables. El objetivo MARK también lo usan arptables, así que regístrese también para NFPROTO_ARP. Mientras tanto, abandone si connbytes no puede habilitar la familia conntrack correspondiente. Este cambio pasa las autopruebas en iptables.git.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50039)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: acepta TCA_STAB solo para qdisc raíz La mayoría de las qdisc mantienen su lista de espera utilizando qdisc_pkt_len(skb) asumiendo que es invariable entre los controladores enqueue() y dequeue(). Desafortunadamente, syzbot puede hacer que un host se bloquee con bastante facilidad utilizando una combinación TBF + SFQ, con un STAB en SFQ [1] No podemos admitir TCA_STAB en un nivel arbitrario, esto requeriría mantener el almacenamiento por qdisc. [1] [ 88.796496] ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000000 [ 88.798611] #PF: acceso de lectura del supervisor en modo núcleo [ 88.799014] #PF: error_code(0x0000) - página no presente [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 No contaminado 6.12.0-rc1-virtme #1117 [ 88.801107] Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Código: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 Todo el código ======== 0: 0f b7 50 12 movzwl 0x12(%rax),%edx 4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax b: 00 c: 48 89 d6 mov %rdx,%rsi f: 48 29 d0 sub %rdx,%rax 12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx 19: 48 c1 e0 03 shl $0x3,%rax 1d: 48 01 c2 suma %rax,%rdx 20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx) 25: 7e c0 jle 0xffffffffffffffe7 27: 48 8b 3a mov (%rdx),%rdi 2a:* 4c 8b 07 mov (%rdi),%r8 <-- instrucción de captura 2d: 4c 89 02 mov %r8,(%rdx) 30: 49 89 50 08 mov %rdx,0x8(%r8) 34: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 3b: 00 3c: 48 rex.W 3d: c7 .byte 0xc7 3e: 07 (malo) ... Código que comienza con la instrucción que fallo ============================================= 0: 4c 8b 07 mov (%rdi),%r8 3: 4c 89 02 mov %r8,(%rdx) 6: 49 89 50 08 mov %rdx,0x8(%r8) a: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 11: 00 12: 48 rex.W 13: c7 .byte 0xc7 14: 07 (malo) ... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.8 04560] RDX: ffff9a1f81bc1440 RSI: 00000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Seguimiento de llamadas: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2024-50040)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igb: No encender el dispositivo después de un error no fatal el commit 004d25060c78 ("igb: Reparar igb_down colgado en eliminación sorpresa") cambió igb_io_error_detected() para ignorar los errores pcie no fatales con el fin de evitar que la tarea se cuelgue que puede suceder cuando se llama a igb_down() varias veces. Esto causó un problema al procesar errores transitorios no fatales. igb_io_resume(), que se llama después de igb_io_error_detected(), asume que el dispositivo es derribado por igb_io_error_detected() si la interfaz está activa. Esto resultó en un pánico con el seguimiento de pila a continuación. [ T3256] igb 0000:09:00.0 haeth0: igb: el enlace NIC haeth0 está inactivo [ T292] pcieport 0000:00:1c.5: AER: Error no corregido (no fatal) recibido: 0000:09:00.0 [ T292] igb 0000:09:00.0: Error de bus PCIe: gravedad=No corregido (no fatal), tipo=Capa de transacción, (ID del solicitante) [ T292] igb 0000:09:00.0: dispositivo [8086:1537] estado/máscara de error=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: Encabezado TLP: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: mensaje de transmisión error_detected [ T292] igb 0000:09:00.0: Se informó un error no fatal y no corregible. [ T292] pcieport 0000:00:1c.5: AER: mensaje de transmisión mmio_enabled [ T292] pcieport 0000:00:1c.5: AER: mensaje de transmisión de reanudación [ T292] ------------[ cortar aquí ]------------ [ T292] ¡ERROR del kernel en net/core/dev.c:6539! [ T292] código de operación no válido: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Seguimiento de llamadas: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] ? igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? informe_congelado_detectado+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? deshabilitar_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? Para solucionar este problema, igb_io_resume() verifica si la interfaz está ejecutándose y si el dispositivo no está inactivo, esto significa que igb_io_error_detected() no inactivó el dispositivo y no es necesario activarlo.
  
• Vulnerabilidad en Mitel MiCollab (CVE-2024-30157)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  Una vulnerabilidad en el componente Suite Applications Services de Mitel MiCollab hasta la versión 9.7.1.110 podría permitir que un atacante autenticado con privilegios administrativos realice un ataque de inyección SQL debido a una validación insuficiente de la entrada del usuario. Una explotación exitosa podría permitir que un atacante ejecute operaciones arbitrarias de administración y base de datos.
  
• Vulnerabilidad en Mitel MiCollab (CVE-2024-30158)
  Severidad: ALTA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  Una vulnerabilidad en el componente de conferencias web de Mitel MiCollab hasta la versión 9.7.1.110 podría permitir que un atacante autenticado con privilegios administrativos realice un ataque de inyección SQL debido a una validación insuficiente de la entrada del usuario. Una explotación exitosa podría permitir que un atacante ejecute operaciones arbitrarias de administración y base de datos.
  
• Vulnerabilidad en Mitel MiCollab (CVE-2024-30159)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  Una vulnerabilidad en el componente de conferencias web de Mitel MiCollab hasta la versión 9.7.1.110 podría permitir que un atacante autenticado con privilegios administrativos realice un ataque de Cross Site Scripting (XSS) almacenado debido a una validación insuficiente de la entrada del usuario. Una explotación exitosa podría permitir que un atacante ejecute secuencias de comandos arbitrarias.
  
• Vulnerabilidad en Mitel MiCollab (CVE-2024-30160)
  Severidad: MEDIA
  Fecha de publicación: 21/10/2024
  Fecha de última actualización: 25/10/2024
  Una vulnerabilidad en el componente Suite Applications Services de Mitel MiCollab hasta la versión 9.7.1.110 podría permitir que un atacante autenticado con privilegios administrativos realice un ataque de Cross Site Scripting (XSS) Almacenado debido a una validación insuficiente de la entrada del usuario. Una explotación exitosa podría permitir que un atacante ejecute secuencias de comandos arbitrarias.
  
• Vulnerabilidad en IBM Concert (CVE-2024-43173)
  Severidad: BAJA
  Fecha de publicación: 22/10/2024
  Fecha de última actualización: 25/10/2024
  IBM Concert 1.0.0 y 1.0.1 son vulnerables a ataques que se basan en el uso de cookies sin el atributo SameSite.
  
• Vulnerabilidad en IBM Concert (CVE-2024-43177)
  Severidad: CRÍTICA
  Fecha de publicación: 22/10/2024
  Fecha de última actualización: 25/10/2024
  IBM Concert 1.0.0 y 1.0.1 son vulnerables a ataques que se basan en el uso de cookies sin el atributo SameSite.
  
• Vulnerabilidad en Umbraco (CVE-2024-47819)
  Severidad: ALTA
  Fecha de publicación: 22/10/2024
  Fecha de última actualización: 25/10/2024
  Umbraco, un sistema de gestión de contenido .NET gratuito y de código abierto, tiene una vulnerabilidad de cross-site scripting a partir de la versión 14.0.0 y anteriores a las versiones 14.3.1 y 15.0.0. Esto se puede aprovechar para obtener acceso a endpoints con privilegios más altos, por ejemplo, si consigue que un usuario con privilegios de administrador ejecute el código, puede elevar potencialmente a todos los usuarios y otorgarles privilegios de administrador o acceder a contenido protegido. Las versiones 14.3.1 y 15.0.0 contienen un parche. Como workaround, asegúrese de que el acceso a la sección Diccionario solo se conceda a usuarios de confianza.
  
• Vulnerabilidad en Umbraco (CVE-2024-48925)
  Severidad: MEDIA
  Fecha de publicación: 22/10/2024
  Fecha de última actualización: 25/10/2024
  Umbraco, un sistema de gestión de contenido .NET gratuito y de código abierto, tiene un problema de control de acceso incorrecto a partir de la versión 14.0.0 y anteriores a la versión 14.3.0. El problema permite que los usuarios con pocos privilegios accedan a la API de webhook y recuperen información que debería estar restringida a los usuarios con acceso a la sección de configuración. La versión 14.3.0 contiene un parche.
  
• Vulnerabilidad en Umbraco (CVE-2024-48926)
  Severidad: BAJA
  Fecha de publicación: 22/10/2024
  Fecha de última actualización: 25/10/2024
  Umbraco, un sistema de gestión de contenido .NET gratuito y de código abierto, tiene un problema de caducidad de sesión insuficiente en las versiones de la rama 13.x anteriores a la 13.5.2, 10.x anteriores a la 10.8.7 y 8.x anteriores a la 8.18.15. El Backoffice muestra la página de cierre de sesión con un mensaje de tiempo de espera de sesión antes de que la sesión del servidor haya caducado por completo, lo que hace que los usuarios crean que se ha cerrado la sesión aproximadamente 30 segundos antes de lo que realmente ocurre. Las versiones 13.5.2, 10.8.7 y 8.18.15 contienen un parche para el problema.
  
• Vulnerabilidad en Umbraco (CVE-2024-48927)
  Severidad: MEDIA
  Fecha de publicación: 22/10/2024
  Fecha de última actualización: 25/10/2024
  Umbraco, un sistema de gestión de contenido .NET gratuito y de código abierto, tiene un problema de ejecución de código remoto en las versiones de la rama 13.x anteriores a la 13.5.2, 10.x anteriores a la 10.8.7 y 8.x anteriores a la 8.18.15. Existe un riesgo potencial de ejecución de código para los usuarios de Backoffice cuando "obtienen una vista previa" de los archivos SVG en modo de pantalla completa. Las versiones 13.5.2, 10.8.7 y 8.18.15 contienen un parche para el problema. Como workaround, está disponible la validación de archivos del lado derver para eliminar las etiquetas de script del contenido del archivo durante el proceso de carga del archivo.
  
• Vulnerabilidad en Umbraco (CVE-2024-48929)
  Severidad: MEDIA
  Fecha de publicación: 22/10/2024
  Fecha de última actualización: 25/10/2024
  Umbraco es un sistema de gestión de contenido .NET gratuito y de código abierto. En las versiones de la rama 13.x anteriores a la 13.5.2 y en las versiones de la rama 10.x anteriores a la 10.8.7, durante un cierre de sesión explícito, la sesión del servidor no finaliza por completo. Las versiones 13.5.2 y 10.8.7 contienen un parche para solucionar este problema.
  
• Vulnerabilidad en Trend Micro Antivirus One (CVE-2024-45334)
  Severidad: ALTA
  Fecha de publicación: 22/10/2024
  Fecha de última actualización: 25/10/2024
  Trend Micro Antivirus One versiones 3.10.4 y anteriores (Consumidor) son vulnerables a una actualización de configuración arbitraria que podría permitir el acceso no autorizado a las configuraciones y funciones del producto.
  
• Vulnerabilidad en Trend Micro Antivirus One (CVE-2024-45335)
  Severidad: MEDIA
  Fecha de publicación: 22/10/2024
  Fecha de última actualización: 25/10/2024
  Trend Micro Antivirus One, versión 3.10.4 y anteriores contiene una vulnerabilidad que podría permitir a un atacante utilizar un virus específicamente manipulado para poder omitir y evadir la detección de un análisis de virus.
  
• Vulnerabilidad en Trend Micro Deep Discovery Inspector (DDI) (CVE-2024-46903)
  Severidad: MEDIA
  Fecha de publicación: 22/10/2024
  Fecha de última actualización: 25/10/2024
  Una vulnerabilidad en Trend Micro Deep Discovery Inspector (DDI) versiones 5.8 y posteriores podría permitir a un atacante divulgar información confidencial de las instalaciones afectadas. Tenga en cuenta que un atacante primero debe obtener la capacidad de ejecutar código con pocos privilegios en el sistema de destino para poder aprovechar esta vulnerabilidad.
  
• Vulnerabilidad en Trend Micro Deep Discovery Inspector (DDI) (CVE-2024-46902)
  Severidad: CRÍTICA
  Fecha de publicación: 22/10/2024
  Fecha de última actualización: 25/10/2024
  Una vulnerabilidad en Trend Micro Deep Discovery Inspector (DDI) versiones 5.8 y posteriores podría permitir a un atacante divulgar información confidencial de las instalaciones afectadas. Tenga en cuenta que un atacante primero debe obtener la capacidad de ejecutar código con privilegios elevados (derechos de usuario administrador) en el sistema de destino para aprovechar esta vulnerabilidad.
  
• Vulnerabilidad en Online Complaint Site v.1.0 (CVE-2024-44812)
  Severidad: CRÍTICA
  Fecha de publicación: 22/10/2024
  Fecha de última actualización: 25/10/2024
  La vulnerabilidad de inyección SQL en Online Complaint Site v.1.0 permite a un atacante remoto escalar privilegios a través de los parámetros username y password en el componente /admin.index.php.
  
• Vulnerabilidad en itsourcecode Loan Management System v1.0 (CVE-2024-48415)
  Severidad: MEDIA
  Fecha de publicación: 22/10/2024
  Fecha de última actualización: 25/10/2024
  itsourcecode Loan Management System v1.0 es vulnerable a cross-site scripting (XSS) a través de un payload manipulado para los parámetros lastname, firstname, middlename, address, contact_no, email y tax_id en la funcionalidad de nuevos prestatarios en la página Prestatarios.
  
• Vulnerabilidad en camaleon-cms v.2.7.5 (CVE-2024-48652)
  Severidad: MEDIA
  Fecha de publicación: 22/10/2024
  Fecha de última actualización: 25/10/2024
  La vulnerabilidad de cross-site scripting en camaleon-cms v.2.7.5 permite a un atacante remoto ejecutar código arbitrario a través del campo de group name de contenido.
  
• Vulnerabilidad en WooCommerce Order Proposal para WordPress (CVE-2024-9927)
  Severidad: ALTA
  Fecha de publicación: 23/10/2024
  Fecha de última actualización: 25/10/2024
  El complemento WooCommerce Order Proposal para WordPress es vulnerable a la escalada de privilegios a través de la propuesta de pedido en todas las versiones hasta la 2.0.5 incluida. Esto se debe a la implementación incorrecta de la función allow_payment_without_login. Esto hace posible que atacantes autenticados, con acceso de nivel de administrador de tienda y superior, inicien sesión en WordPress con una cuenta de usuario arbitraria, incluidos los administradores.
  
• Vulnerabilidad en Download Plugin para WordPress (CVE-2024-9829)
  Severidad: MEDIA
  Fecha de publicación: 23/10/2024
  Fecha de última actualización: 25/10/2024
  El complemento Download Plugin para WordPress es vulnerable al acceso no autorizado a los datos debido a la falta de comprobaciones de capacidad en las funciones 'dpwap_handle_download_user' y 'dpwap_handle_download_comment' en todas las versiones hasta la 2.2.0 incluida. Esto permite que atacantes autenticados, con acceso de nivel de suscriptor o superior, descarguen cualquier comentario y metadatos de cualquier usuario, incluida información de identificación personal del usuario e información confidencial, como nombre de usuario, correo electrónico, contraseñas cifradas y contraseñas de aplicaciones, información de token de sesión y más, según la configuración y los complementos adicionales instalados.
  
• Vulnerabilidad en RSS Aggregator – RSS Import, News Feeds, Feed to Post, and Autoblogging para WordPress (CVE-2024-9583)
  Severidad: MEDIA
  Fecha de publicación: 23/10/2024
  Fecha de última actualización: 25/10/2024
  El complemento RSS Aggregator – RSS Import, News Feeds, Feed to Post, and Autoblogging para WordPress es vulnerable al uso no autorizado de su funcionalidad debido a una falta de comprobación de capacidad en la función wprss_ajax_send_premium_support en todas las versiones hasta la 4.23.12 incluida. Esto permite que atacantes autenticados, con acceso de nivel de suscriptor y superior, envíen solicitudes de soporte premium con una línea de asunto y una dirección de correo electrónico controladas por el atacante para suplantar la identidad del propietario del sitio. También se puede filtrar información de la licencia.
  
• Vulnerabilidad en ProfilePress Pro para WordPress (CVE-2024-9947)
  Severidad: CRÍTICA
  Fecha de publicación: 23/10/2024
  Fecha de última actualización: 25/10/2024
  El complemento ProfilePress Pro para WordPress es vulnerable a la omisión de la autenticación en todas las versiones hasta la 4.11.1 incluida. Esto se debe a una verificación insuficiente del usuario que devuelve el token de inicio de sesión social. Esto hace posible que atacantes no autenticados inicien sesión como cualquier usuario existente en el sitio, como un administrador, si tienen acceso al correo electrónico y el usuario no tiene una cuenta ya existente para el servicio que devuelve el token.
  
• Vulnerabilidad en WP Shortcodes Plugin — Shortcodes Ultimate plugin for WordPress (CVE-2024-8500)
  Severidad: MEDIA
  Fecha de publicación: 23/10/2024
  Fecha de última actualización: 25/10/2024
  El complemento WP Shortcodes Plugin — Shortcodes Ultimate plugin for WordPress es vulnerable a cross site scripting almacenado a través de varios parámetros en todas las versiones hasta la 7.2.2 incluida, debido a una limpieza de entrada y un escape de salida insuficiente. Esto hace posible que atacantes autenticados, con acceso de nivel de colaborador y superior, inyecten scripts web arbitrarios en páginas que se ejecutarán cada vez que un usuario acceda a una página inyectada.
  
• Vulnerabilidad en Nioland para WordPress (CVE-2024-10250)
  Severidad: MEDIA
  Fecha de publicación: 23/10/2024
  Fecha de última actualización: 25/10/2024
  El tema Nioland para WordPress es vulnerable a ataques de cross-site scripting reflejado a través del parámetro 's' en todas las versiones hasta la 1.2.6 incluida, debido a una desinfección de entrada y un escape de salida insuficientes. Esto permite que atacantes no autenticados inyecten secuencias de comandos web arbitrarias en páginas que se ejecutan si logran engañar a un usuario para que realice una acción, como hacer clic en un enlace.