Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

Vulnerabilidades

Con el objetivo de informar, advertir y ayudar a los profesionales sobre las ultimas vulnerabilidades de seguridad en sistemas tecnológicos, ponemos a disposición de los usuarios interesados en esta información una base de datos con información en castellano sobre cada una de las ultimas vulnerabilidades documentadas y conocidas.

Este repositorio con más de 75.000 registros esta basado en la información de NVD (National Vulnerability Database) – en función de un acuerdo de colaboración – por el cual desde INCIBE realizamos la traducción al castellano de la información incluida. En ocasiones este listado mostrará vulnerabilidades que aún no han sido traducidas debido a que se recogen en el transcurso del tiempo en el que el equipo de INCIBE realiza el proceso de traducción.

Se emplea el estándar de nomenclatura de vulnerabilidades CVE (Common Vulnerabilities and Exposures), con el fin de facilitar el intercambio de información entre diferentes bases de datos y herramientas. Cada una de las vulnerabilidades recogidas enlaza a diversas fuentes de información así como a parches disponibles o soluciones aportadas por los fabricantes y desarrolladores. Es posible realizar búsquedas avanzadas teniendo la opción de seleccionar diferentes criterios como el tipo de vulnerabilidad, fabricante, tipo de impacto entre otros, con el fin de acortar los resultados.

Mediante suscripción RSS o Boletines podemos estar informados diariamente de las ultimas vulnerabilidades incorporadas al repositorio.

Vulnerabilidad en kernel de Linux (CVE-2022-49077)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmmremap.c: evitar invalidate_range_start/end inútil en mremap(old_size=0) Si una llamada al sistema mremap() con old_size=0 termina en move_page_tables(), llamará a invalidate_range_start()/invalidate_range_end() innecesariamente, es decir, con un rango vacío. Esto provoca una ADVERTENCIA en mmu_notifier de KVM. En el pasado, se ha diagnosticado que los rangos vacíos eran errores con un desfase de uno, de ahí la ADVERTENCIA. Dado el bajo número (hasta ahora) de informes únicos, los beneficios de detectar más llamadores con errores parecen superar el costo de tener que arreglar casos como este, donde el espacio de usuario está haciendo algo tonto. En este caso particular, un retorno temprano de move_page_tables() es suficiente para solucionar el problema.
Gravedad CVSS v3.1: MEDIA
Última modificación:
14/10/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49079)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zoned: atravesar dispositivos bajo chunk_mutex en btrfs_can_activate_zone btrfs_can_activate_zone() se puede llamar con el device_list_mutex ya retenido, lo que provocará un bloqueo: insert_dev_extents() // Toma device_list_mutex `-> insert_dev_extent() `-> btrfs_insert_empty_item() `-> btrfs_insert_empty_items() `-> btrfs_search_slot() `-> btrfs_cow_block() `-> __btrfs_cow_block() `-> btrfs_alloc_tree_block() `-> btrfs_reserve_extent() `-> find_free_extent() `-> find_free_extent_update_loop() `-> can_allocate_chunk() `-> btrfs_can_activate_zone() // Toma device_list_mutex nuevamente En lugar de usar la RCU en fs_devices->device_list podemos usar fs_devices->alloc_list, protegido por chunk_mutex para recorrer la lista de dispositivos activos. Estamos en el hilo de asignación de fragmentos. La asignación de fragmentos más nueva ocurre desde los dispositivos en fs_device->alloc_list protegidos por chunk_mutex. btrfs_create_chunk() lockdep_assert_held(&info->chunk_mutex); gather_device_info list_for_each_entry(device, &fs_devices->alloc_list, dev_alloc_list) Además, un dispositivo que reaparece después del montaje no se unirá a alloc_list todavía y estará en dev_list, que no queremos considerar en el contexto de la asignación de fragmentos. [15.166572] ADVERTENCIA: se detectó un posible bloqueo recursivo [15.167117] 5.17.0-rc6-dennis #79 No contaminado [15.167487] -------------------------------------------- [15.167733] kworker/u8:3/146 está intentando adquirir el bloqueo: [15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, en: find_free_extent+0x15a/0x14f0 [btrfs] [15.167733] [15.167733] pero la tarea ya tiene el bloqueo: [15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, en: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs] [15.167733] [15.167733] otra información que podría ayudarnos a depurar esto: [15.167733] Posible escenario de bloqueo inseguro: [15.167733] [15.171834] CPU0 [15.171834] ---- [15.171834] lock(&fs_devs->device_list_mutex); [15.171834] lock(&fs_devs->device_list_mutex); [15.171834] [15.171834] *** BLOQUEO INTERMEDIO *** [15.171834] [15.171834] Puede deberse a la falta de notación de anidamiento de bloqueos [15.171834] [15.171834] 5 bloqueos retenidos por kworker/u8:3/146: [15.171834] #0: ffff888100050938 ((wq_completion)events_unbound){+.+.}-{0:0}, en: process_one_work+0x1c3/0x5a0 [15.171834] #1: ffffc9000067be80 ((work_completion)(&fs_info->async_data_reclaim_work)){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0 [15.176244] #2: ffff88810521e620 (sb_internal){.+.+}-{0:0}, at: flush_space+0x335/0x600 [btrfs] [15.176244] #3: ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs] [15.176244] #4: ffff8881152e4b78 (btrfs-dev-00){++++}-{3:3}, at: __btrfs_tree_lock+0x27/0x130 [btrfs] [15.179641] [15.179641] stack backtrace: [15.179641] CPU: 1 PID: 146 Comm: kworker/u8:3 Not tainted 5.17.0-rc6-dennis #79 [15.179641] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 01/04/2014 [15.179641] Cola de trabajo: events_unbound btrfs_async_reclaim_data_space [btrfs] [15.179641] Rastreo de llamadas: [15.179641] [15.179641] dump_stack_lvl+0x45/0x59 [15.179641] __lock_acquire.cold+0x217/0x2b2 [15.179641] lock_acquire+0xbf/0x2b0 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] __mutex_lock+0x8e/0x970 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? lock_is_held_type+0xd7/0x130 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? _raw_spin_unlock+0x24/0x40 [15.183838] ? btrfs_get_alloc_profile+0x106/0x230 [btrfs] [15.187601] btrfs_reserve_extent+0x131/0x260 [btrfs] [15. ---truncado---
Gravedad CVSS v3.1: MEDIA
Última modificación:
14/10/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49080)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/mempolicy: arregla la fuga de mpol_new en shared_policy_replace Si mpol_new se asigna pero no se usa en el bucle de reinicio, mpol_new se liberará a través de mpol_put antes de regresar al llamador. Pero refcnt aún no se ha inicializado, por lo que mpol_put no podría hacer las cosas correctas y podría filtrar el mpol_new no utilizado. Esto sucedería si mempolicy se actualizara en el archivo shmem compartido mientras se eliminaba sp->lock durante la asignación de memoria. Este problema se podría activar fácilmente con el siguiente fragmento de código si hay muchos procesos haciendo el siguiente trabajo al mismo tiempo: shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); shm = shmat(shmid, 0, 0); repetir muchas veces { mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, maxnode, 0); }
Gravedad CVSS v3.1: MEDIA
Última modificación:
23/09/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49081)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: highmem: se corrigen las comprobaciones en __kmap_local_sched_{in,out}. Cuando CONFIG_DEBUG_KMAP_LOCAL está habilitado, __kmap_local_sched_{in,out} comprueba que ni siquiera las ranuras en tsk->kmap_ctrl.pteval estén asignadas. Las ranuras se inicializan con el valor 0, pero la comprobación se realiza con pte_none. Sin embargo, 0 pte no significa necesariamente que pte_none devuelva verdadero. p. ej. en xtensa devuelve falso, lo que genera las siguientes advertencias de tiempo de ejecución: ADVERTENCIA: CPU: 0 PID: 101 en mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108 CPU: 0 PID: 101 Comm: touch No contaminado 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Seguimiento de llamadas: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_out+0x51/0x108 __schedule+0x71a/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7f ADVERTENCIA: CPU: 0 PID: 101 en mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0 CPU: 0 PID: 101 Comm: toque Contaminado: GW 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Seguimiento de llamadas: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_in+0x50/0xe0 Soluciónelo reemplazando !pte_none(pteval) con pte_val(pteval) != 0.
Gravedad CVSS v3.1: MEDIA
Última modificación:
14/10/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49082)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpt3sas: Se corrige el use-after-free en _scsih_expander_node_remove() La función mpt3sas_transport_port_remove() llamada en _scsih_expander_node_remove() libera el campo de puerto de la estructura sas_expander, lo que lleva al siguiente splat de use-after-free de KASAN cuando se ejecuta la llamada ioc_info() después de esa función (por ejemplo, al realizar rmmod del módulo del controlador): [ 3479.371167] ===================================================================== [ 3479.378496] ERROR: KASAN: use-after-free en _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.386936] Lectura de tamaño 1 en la dirección ffff8881c037691c por la tarea rmmod/1531 [ 3479.393524] [ 3479.395035] CPU: 18 PID: 1531 Comm: rmmod No contaminado 5.17.0-rc8+ #1436 [ 3479.401712] Nombre del hardware: Supermicro Super Server/H12SSL-NT, BIOS 2.1 06/02/2021 [ 3479.409263] Call Trace: [ 3479.411743] [ 3479.413875] dump_stack_lvl+0x45/0x59 [ 3479.417582] print_address_description.constprop.0+0x1f/0x120 [ 3479.423389] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.429469] kasan_report.cold+0x83/0xdf [ 3479.433438] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.439514] _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.445411] ? _raw_spin_unlock_irqrestore+0x2d/0x40 [ 3479.452032] scsih_remove+0x525/0xc90 [mpt3sas] [ 3479.458212] ? mpt3sas_expander_remove+0x1d0/0x1d0 [mpt3sas] [ 3479.465529] ? down_write+0xde/0x150 [ 3479.470746] ? up_write+0x14d/0x460 [ 3479.475840] ? kernfs_find_ns+0x137/0x310 [ 3479.481438] pci_device_remove+0x65/0x110 [ 3479.487013] __device_release_driver+0x316/0x680 [ 3479.493180] driver_detach+0x1ec/0x2d0 [ 3479.498499] bus_remove_driver+0xe7/0x2d0 [ 3479.504081] pci_unregister_driver+0x26/0x250 [ 3479.510033] _mpt3sas_exit+0x2b/0x6cf [mpt3sas] [ 3479.516144] __x64_sys_delete_module+0x2fd/0x510 [ 3479.522315] ? free_module+0xaa0/0xaa0 [ 3479.527593] ? __cond_resched+0x1c/0x90 [ 3479.532951] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 3479.539607] ? syscall_enter_from_user_mode+0x21/0x70 [ 3479.546161] ? trace_hardirqs_on+0x1c/0x110 [ 3479.551828] do_syscall_64+0x35/0x80 [ 3479.556884] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 3479.563402] RIP: 0033:0x7f1fc482483b ... [ 3479.943087] ======================================================================== Solucione esto introduciendo la variable local port_id para almacenar el valor del ID del puerto antes de ejecutar mpt3sas_transport_port_remove(). Luego, esta variable local se utiliza en la llamada a ioc_info() en lugar de desreferenciar la estructura del puerto liberado.
Gravedad CVSS v3.1: ALTA
Última modificación:
25/03/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49083)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/omap: Se corrige la regresión en la sonda para la desreferencia de puntero NULL. el commit 3f6634d997db ("iommu: Use la forma correcta de recuperar iommu_ops") comenzó a activar una desreferencia de puntero NULL para algunas variantes de omap: __iommu_probe_device de probe_iommu_group+0x2c/0x38 probe_iommu_group de bus_for_each_dev+0x74/0xbc bus_for_each_dev de bus_iommu_probe+0x34/0x2e8 bus_iommu_probe de bus_set_iommu+0x80/0xc8 bus_set_iommu de omap_iommu_init+0x88/0xcc omap_iommu_init de do_one_initcall+0x44/0x24 Esto se debe a que la sonda omap iommu devuelve 0 en lugar de ERR_PTR(-ENODEV), como lo señaló Jason Gunthorpe . Parece que la regresión ya ocurrió con una confirmación anterior 6785eb9105e3 ("iommu/omap: Convertir a devoluciones de llamada de probe/release_device()") que cambió el tipo de retorno de la función y no realizó la conversión en un lugar.
Gravedad CVSS v3.1: MEDIA
Última modificación:
23/09/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49084)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: qede: confirmar que skb está asignado antes de usar qede_build_skb() supone que build_skb() siempre funciona y pasa directamente a skb_reserve(). Sin embargo, build_skb() puede fallar bajo presión de memoria. Esto da como resultado un pánico del kernel porque el skb a reservar es NULL. Agregue una verificación en caso de que build_skb() no pueda asignar y devuelva NULL. El retorno NULL se maneja correctamente en los llamadores a qede_build_skb().
Gravedad CVSS v3.1: MEDIA
Última modificación:
23/09/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49085)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drbd: Arregla cinco errores de use-after-free en get_initial_state En get_initial_state, llama a notify_initial_state_done(skb,..) si cb->args[5]==1. Si genlmsg_put() falló en notify_initial_state_done(), el skb será liberado por nlmsg_free(skb). Entonces get_initial_state saldrá y el skb liberado será utilizado por el valor de retorno skb->len, que es un error de uaf. Lo que es peor, el mismo problema va aún más allá: skb también se puede liberar en las llamadas notify_*_state_change -> notify_*_state a continuación. Por lo tanto, ocurrieron 4 errores de uaf adicionales. Mi parche permite que las funciones llamadas al problema: notify_initial_state_done y notify_*_state_change devuelvan un código de error si ocurren errores. Para que los códigos de error se puedan propagar y los errores de uaf se puedan evitar, la v2 informa una advertencia de compilación. Esta v3 corrigió esta advertencia y se compiló correctamente en mi entorno local sin advertencias adicionales. v2: https://lore.kernel.org/patchwork/patch/1435218/
Gravedad CVSS v3.1: ALTA
Última modificación:
25/03/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49086)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: openvswitch: fix leak of nested shares Mientras analiza acciones proporcionadas por el usuario, el módulo openvswitch puede asignar memoria dinámicamente y almacenar punteros en la copia interna de las acciones. Por lo tanto, esta memoria debe liberarse mientras se destruyen las acciones. Actualmente solo hay dos acciones de este tipo: ct() y set(). Sin embargo, hay muchas acciones que pueden contener listas anidadas de acciones y ovs_nla_free_flow_actions() simplemente las salta, perdiendo la memoria. Por ejemplo, la eliminación del flujo con las siguientes acciones provocará una pérdida de la memoria asignada por nf_ct_tmpl_alloc(): shares:clone(ct(commit),0) La acción set() no liberada también puede perder la estructura 'dst' para la información del túnel, incluidas las referencias del dispositivo. Bajo ciertas condiciones con una alta tasa de rotación del flujo, esto puede causar un problema de pérdida de memoria significativo (2 MB por segundo en el caso del reportero). El problema también es difícil de mitigar, porque el usuario no tiene control directo sobre los flujos de rutas de datos generados por OVS. Solucione eso iterando sobre todas las acciones anidadas y liberando todo lo que se necesite liberar de forma recursiva. La nueva afirmación de tiempo de compilación debería protegernos de este problema si se agregan nuevas acciones en el futuro. Desafortunadamente, el módulo openvswitch no usa NLA_F_NESTED, por lo que todos los atributos deben verificarse explícitamente. Las acciones sample() y clone() mezclan atributos adicionales en la lista de acciones proporcionada por el usuario. Eso también evita cierta generalización del código.
Gravedad CVSS v3.1: MEDIA
Última modificación:
23/09/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49078)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: lz4: arreglar LZ4_decompress_safe_partial lectura fuera de límite Cuando se realiza una descodificación parcial, es EOF si hemos llenado el búfer de salida o no podemos continuar con la lectura de un desplazamiento para la siguiente coincidencia. En algunos casos extremos, cuando los datos comprimidos están adecuadamente dañados, se producirá UAF. Como informó KASAN [1], LZ4_decompress_safe_partial puede provocar un problema de lectura fuera de límite durante la descodificación. lz4 upstream lo ha solucionado [2] y este problema se ha discutido aquí [3] anteriormente. La rutina de descompresión actual se trasladó de lz4 v1.8.3, actualizar lib/lz4 a v1.9.+ es sin duda un gran trabajo por hacer más adelante, así que será mejor que lo solucionemos primero. [1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# [3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/
Gravedad CVSS v3.1: ALTA
Última modificación:
19/12/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49068)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: libera la cantidad correcta de delalloc en la ruta de escritura de E/S directa. La ejecución de generic/406 provoca la siguiente ADVERTENCIA en btrfs_destroy_inode() que indica que quedan extensiones pendientes. En btrfs_get_blocks_direct_write(), reservamos extensiones pendientes temporalmente con btrfs_delalloc_reserve_metadata() (o indirectamente desde btrfs_delalloc_reserve_space()). Luego, liberamos las extensiones pendientes con btrfs_delalloc_release_extents(). Sin embargo, la "longitud" se puede modificar en el caso de COW, que libera menos extensiones pendientes de lo esperado. Arréglelo llamando a btrfs_delalloc_release_extents() para la longitud original. Para reproducir la advertencia, el sistema de archivos debe ser de 1 GiB. Está activando una escritura corta, debido a que no se puede asignar una extensión grande y, en su lugar, se asigna una más pequeña. ADVERTENCIA: CPU: 0 PID: 757 en fs/btrfs/inode.c:8848 btrfs_destroy_inode+0x1e6/0x210 [btrfs] Módulos vinculados en: btrfs blake2b_generic xor lzo_compress lzo_decompress raid6_pq zstd zstd_decompress zstd_compress xxhash zram zsmalloc CPU: 0 PID: 757 Comm: umount No contaminado 5.17.0-rc8+ #101 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS d55cb5a 01/04/2014 RIP: 0010:btrfs_destroy_inode+0x1e6/0x210 [btrfs] RSP: 0018:ffffc9000327bda8 EFLAGS: 00010206 RAX: 000000000000000 RBX: ffff888100548b78 RCX: 0000000000000000 RDX: 0000000000026900 RSI: 0000000000000000 RDI: ffff888100548b78 RBP: ffff888100548940 R08: 0000000000000000 R09: ffff88810b48aba8 R10: 0000000000000001 R11: ffff8881004eb240 R12: ffff88810b48a800 R13: ffff88810b48ec08 R14: ffff88810b48ed00 R15: ffff888100490c68 FS: 00007f8549ea0b80(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f854a09e733 CR3: 000000010a2e9003 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: destroy_inode+0x33/0x70 dispose_list+0x43/0x60 evict_inodes+0x161/0x1b0 generic_shutdown_super+0x2d/0x110 kill_anon_super+0xf/0x20 btrfs_kill_super+0xd/0x20 [btrfs] deactivate_locked_super+0x27/0x90 cleanup_mnt+0x12c/0x180 task_work_run+0x54/0x80 exit_to_user_mode_prepare+0x152/0x160 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x42/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f854a000fb7
Gravedad CVSS v3.1: MEDIA
Última modificación:
14/10/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49069)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se solucionó agregando protección FPU para dcn30_internal_validate_bw [Por qué] Se observó una falla de protección general cuando WebGL Aquarium se ejecuta durante un período prolongado. Si los registros de depuración de drm están habilitados y configurados en 0x1f, el problema se observa dentro de los 10 minutos posteriores a la ejecución. [ 100.717056] Fallo de protección general, probablemente para la dirección no canónica 0x2d33302d32323032: 0000 [#1] PREEMPT SMP NOPTI [ 100.727921] CPU: 3 PID: 1906 Comm: DrmThread Tainted: GW 5.15.30 #12 d726c6a2d6ebe5cf9223931cbca6892f916fe18b [ 100.754419] RIP: 0010:CalculateSwathWidth+0x1f7/0x44f [ 100.767109] Código: 00 00 00 f2 42 0f 11 04 f0 48 8b 85 88 00 00 00 f2 42 0f 10 04 f0 48 8b 85 98 00 00 00 f2 42 0f 11 04 f0 48 8b 45 10 0f 57 c0 42 0f 2a 04 b0 0f 57 c9 f3 43 0f 2a 0c b4 e8 8c e2 f3 ff 48 8b [ 100.781269] RSP: 0018:ffffa9230079eeb0 EFLAGS: 00010246 [ 100.812528] RAX: 2d33302d32323032 RBX: 0000000000000500RCX: 00000000000000000 [ 100.819656] RDX: 00000000000000001 RSI: ffff99deb712c49c RDI: 0000000000000000 [ 100.826781] RBP: ffffa9230079ef50 R08: ffff99deb712460c R09: ffff99deb712462c [ 100.833907] R10: ffff99deb7124940 R11: ffff99deb7124d70 R12: ffff99deb712ae44 [ 100.841033] R13: 00000000000000001 R14: 00000000000000000 R15: ffffa9230079f0a0 [ 100.848159] FS: 00007af121212640(0000) GS:ffff99deba780000(0000) knlGS:0000000000000000 [ 100.856240] CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 [ 100.861980] CR2: 0000209000fe1000 CR3: 000000011b18c000 CR4: 0000000000350ee0 [ 100.869106] Seguimiento de llamadas: [ 100.871555] [ 100.873655] ? asm_sysvec_reschedule_ipi+0x12/0x20 [ 100.878449] CalculateSwathAndDETConfiguration+0x1a3/0x6dd [ 100.883937] dml31_ModeSupportAndSystemConfigurationFull+0x2ce4/0x76da [ 100.890467] ? kallsyms_lookup_buildid+0xc8/0x163 [ 100.895173] ? kallsyms_lookup_buildid+0xc8/0x163 [ 100.899874] ? __sprint_symbol+0x80/0x135 [ 100.903883] ? dm_update_plane_state+0x3f9/0x4d2 [ 100.908500] ? symbol_string+0xb7/0xde [ 100.912250] ? number+0x145/0x29b [ 100.915566] ? vsnprintf+0x341/0x5ff [ 100.919141] ? desc_read_finalized_seq+0x39/0x87 [ 100.923755] ? update_load_avg+0x1b9/0x607 [ 100.927849] ? compute_mst_dsc_configs_for_state+0x7d/0xd5b [ 100.933416] ? fetch_pipe_params+0xa4d/0xd0c [ 100.937686] ? dc_fpu_end+0x3d/0xa8 [ 100.941175] dml_get_voltage_level+0x16b/0x180 [ 100.945619] dcn30_internal_validate_bw+0x10e/0x89b [ 100.950495] ? dcn31_validate_bandwidth+0x68/0x1fc [ 100.955285] ? resource_build_scaling_params+0x98b/0xb8c [ 100.960595] ? dcn31_validate_bandwidth+0x68/0x1fc [ 100.965384] dcn31_validate_bandwidth+0x9a/0x1fc [ 100.970001] dc_validate_global_state+0x238/0x295 [ 100.974703] amdgpu_dm_atomic_check+0x9c1/0xbce [ 100.979235] ? _printk+0x59/0x73 [ 100.982467] drm_atomic_check_only+0x403/0x78b [ 100.986912] drm_mode_atomic_ioctl+0x49b/0x546 [ 100.991358] ? drm_ioctl+0x1c1/0x3b3 [ 100.994936] ? drm_atomic_set_property+0x92a/0x92a [ 100.999725] drm_ioctl_kernel+0xdc/0x149 [ 101.003648] drm_ioctl+0x27f/0x3b3 [ 101.007051] ? drm_atomic_set_property+0x92a/0x92a [ 101.011842] amdgpu_drm_ioctl+0x49/0x7d [ 101.015679] __se_sys_ioctl+0x7c/0xb8 [ 101.015685] do_syscall_64+0x5f/0xb8 [ 101.015690] ? __irq_exit_rcu+0x34/0x96 [Cómo] Se llama populate_dml_pipes, que utiliza dobles para inicializar. Agregar protección FPU evita el cambio de contexto y la probable pérdida del contexto de VBA, ya que existe una posible contención mientras los registros de depuración de DRM están habilitados.
Gravedad CVSS v3.1: MEDIA
Última modificación:
14/10/2025