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 una petición web en un servidor de Microsoft Dynamics 365 (sobre instalaciones) (CVE-2020-0656)
Severidad: MEDIA
Fecha de publicación: 14/01/2020
Fecha de última actualización: 14/11/2025
Se presenta una vulnerabilidad de tipo cross site scripting cuando Microsoft Dynamics 365 (sobre instalaciones) no sanea apropiadamente una petición web especialmente diseñada para un servidor de Dynamics afectado, también se conoce como "Microsoft Dynamics 365 (On-Premise) Cross Site Scripting Vulnerability".
Vulnerabilidad en codesiddhant Jasmin Ransomware v.1.0.1 (CVE-2024-30851)
Severidad: MEDIA
Fecha de publicación: 03/05/2024
Fecha de última actualización: 14/11/2025
Vulnerabilidad de Directory Traversal en codesiddhant Jasmin Ransomware v.1.0.1 permite a un atacante obtener información confidencial a través del componente download_file.php.
Vulnerabilidad en kernel de Linux (CVE-2021-47247)
Severidad: ALTA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: se corrigió el use after free de la entrada encap en el controlador de actualización cercano. La función mlx5e_rep_neigh_update() no se actualizó para permitir la eliminación del bloqueo rtnl de la ruta de actualización del filtro TC y manejar adecuadamente inserción/eliminación simultánea de entradas encapsuladas que pueden conducir al siguiente use after free: [23827.464923] ================================ ==================================== [23827.469446] BUG: KASAN: use after free en mlx5e_encap_take +0x72/0x140 [mlx5_core] [23827.470971] Lectura de tamaño 4 en la dirección ffff8881d132228c por tarea kworker/u20:6/21635 [23827.472251] [23827.472615] CPU: 9 PID: 21635 kworker/u20 :6 No contaminado 5.13.0 -rc3+ #5 [23827.473788] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 [23827.475639] Cola de trabajo: mlx5e mlx5e_rep_neigh_update [ mlx5_core] [23827.476731] Seguimiento de llamadas: [23827.477260] dump_stack+0xbb/0x107 [23827.477906] print_address_description.constprop.0+0x18/0x140 [23827.478896]? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.479879] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.480905] kasan_report.cold+0x7c/0xd8 [23827.481701] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.482744] kasan_check_range+0x145/0x1a0 [23827.493112] mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.494054] ? mlx5e_tc_tun_encap_info_equal_generic+0x140/0x140 [mlx5_core] [23827.495296] mlx5e_rep_neigh_update+0x41e/0x5e0 [mlx5_core] [23827.496338] ? mlx5e_rep_neigh_entry_release+0xb80/0xb80 [mlx5_core] [23827.497486] ? read_word_at_a_time+0xe/0x20 [23827.498250] ? strscpy+0xa0/0x2a0 [23827.498889] process_one_work+0x8ac/0x14e0 [23827.499638] ? lockdep_hardirqs_on_prepare+0x400/0x400 [23827.500537]? pwq_dec_nr_in_flight+0x2c0/0x2c0 [23827.501359] ? rwlock_bug.part.0+0x90/0x90 [23827.502116] worker_thread+0x53b/0x1220 [23827.502831]? Process_one_work+0x14e0/0x14e0 [23827.503627] kthread+0x328/0x3f0 [23827.504254] ? _raw_spin_unlock_irq+0x24/0x40 [23827.505065] ? __kthread_bind_mask+0x90/0x90 [23827.505912] ret_from_fork+0x1f/0x30 [23827.506621] [23827.506987] Asignado por tarea 28248: [23827.507694] 0 [23827.508476] __kasan_kmalloc+0x7c/0x90 [23827.509197] mlx5e_attach_encap+0xde1/0x1d40 [mlx5_core ] [23827.510194] mlx5e_tc_add_fdb_flow+0x397/0xc40 [mlx5_core] [23827.511218] __mlx5e_add_fdb_flow+0x519/0xb30 [mlx5_core] [23827.512234] 191c/0x4870 [mlx5_core] [23827.513298] tc_setup_cb_add+0x1d5/0x420 [23827.514023] fl_hw_replace_filter+0x382/0x6a0 [cls_flower] [23827.514975] fl_change+0x2ceb/0x4a51 [cls_flower] [23827.515821] tc_new_tfilter+0x89a/0x2070 [23827.516548] rtnetlink_rcv_msg+0x644/0x8c0 [23827.51 7300] netlink_rcv_skb+0x11d/0x340 [23827.518021] netlink_unicast+0x42b/0x700 [23827.518742] netlink_sendmsg +0x743/0xc20 [23827.519467] sock_sendmsg+0xb2/0xe0 [23827.520131] ____sys_sendmsg+0x590/0x770 [23827.520851] ___sys_sendmsg+0xd8/0x160 [23827. 521552] __sys_sendmsg+0xb7/0x140 [23827.522238] do_syscall_64+0x3a/0x70 [23827.522907] Entry_SYSCALL_64_after_hwframe+0x44 /0xae [23827.523797] [23827.524163] Liberado por la tarea 25948: [23827.524780] kasan_save_stack+0x1b/0x40 [23827.525488] kasan_set_track+0x1c/0x30 [23827.526187] _free_info+0x20/0x30 [23827.526968] __kasan_slab_free+0xed/0x130 [23827.527709] slab_free_freelist_hook+ 0xcf/0x1d0 [23827.528528] kmem_cache_free_bulk+0x33a/0x6e0 [23827.529317] kfree_rcu_work+0x55f/0xb70 [23827.530024] Process_one_work+0x8ac/0x14e0 [23827.530770 ] work_thread+0x53b/0x1220 [23827.531480] kthread+0x328/0x3f0 [23827.532114] ret_from_fork+0x1f/ 0x30 [23827.532785] [23827.533147] Última creación de trabajo potencialmente relacionado: [23827.534007] kasan_save_stack+0x1b/0x40 [23827.534710] kasan_record_aux_stack+0xab/0xc0 [23827.535492] _rcu+0x31/0x7b0 [23827.536206] mlx5e_tc_del ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2021-47352)
Severidad: ALTA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: virtio-net: Agregar validación para la longitud utilizada. Esto agrega validación para la longitud utilizada (puede provenir de un dispositivo que no es de confianza) para evitar la corrupción o pérdida de datos.
Vulnerabilidad en QDOCS Smart School 7.0.0 (CVE-2024-34240)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 14/11/2025
QDOCS Smart School 7.0.0 es vulnerable a Cross Site Scripting (XSS), lo que resulta en la ejecución de código arbitrario en funciones administrativas relacionadas con la adición o actualización de registros.
Vulnerabilidad en kernel de Linux (CVE-2024-36913)
Severidad: ALTA
Fecha de publicación: 30/05/2024
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Controladores: hv: vmbus: páginas de fuga si falla set_memory_encrypted() En máquinas virtuales CoCo, es posible que el host que no es de confianza provoque que set_memory_encrypted() o set_memory_decrypted() falle de manera que se produzca un error se devuelve y la memoria resultante se comparte. Las personas que llaman deben tener cuidado al manejar estos errores para evitar devolver memoria descifrada (compartida) al asignador de páginas, lo que podría provocar problemas funcionales o de seguridad. El código VMBus podría liberar páginas descifradas si falla set_memory_encrypted()/decrypted(). Filtre las páginas si esto sucede.
Vulnerabilidad en Microsoft Dynamics 365 (CVE-2024-38182)
Severidad: CRÍTICA
Fecha de publicación: 31/07/2024
Fecha de última actualización: 14/11/2025
La autenticación débil en Microsoft Dynamics 365 permite que un atacante no autenticado eleve los privilegios en una red.
Vulnerabilidad en CodeChecker (CVE-2024-10081)
Severidad: CRÍTICA
Fecha de publicación: 06/11/2024
Fecha de última actualización: 14/11/2025
CodeChecker es una herramienta de análisis, una base de datos de defectos y una extensión de visualización para Clang Static Analyzer y Clang Tidy. La omisión de autenticación se produce cuando la URL de la API termina con Autenticación. Esta omisión permite el acceso de superusuario a todos los endpoints de la API excepto Autenticación. Estos endpoints incluyen la capacidad de agregar, editar y eliminar productos, entre otras cosas. Todos los endpoints, excepto /Authentication, se ven afectados por la vulnerabilidad. Este problema afecta a CodeChecker: hasta la versión 6.24.1.
Vulnerabilidad en CodeChecker (CVE-2024-10082)
Severidad: ALTA
Fecha de publicación: 06/11/2024
Fecha de última actualización: 14/11/2025
CodeChecker es una herramienta de análisis, una base de datos de defectos y una extensión de visualización para Clang Static Analyzer y Clang Tidy. La confusión del método de autenticación permite iniciar sesión como el usuario root integrado desde un servicio externo. El usuario root integrado hasta la versión 6.24.1 se genera de forma débil, no se puede deshabilitar y tiene acceso universal. Esta vulnerabilidad permite a un atacante que puede crear una cuenta en un servicio de autenticación externo habilitado iniciar sesión como el usuario root y acceder y controlar todo lo que se puede controlar a través de la interfaz web. El atacante necesita adquirir el nombre de usuario del usuario root para tener éxito. Este problema afecta a CodeChecker: hasta la versión 6.24.1.
Vulnerabilidad en CodeChecker (CVE-2024-53829)
Severidad: ALTA
Fecha de publicación: 21/01/2025
Fecha de última actualización: 14/11/2025
CodeChecker es una herramienta de análisis, una base de datos de defectos y una extensión de visualización para Clang Static Analyzer y Clang Tidy. Cross-site request forgery permite a un atacante no autenticado secuestrar la autenticación de un usuario conectado y usar la API web con los mismos permisos, incluidos, entre otros, agregar, eliminar o editar productos. El atacante necesita saber el ID de los productos disponibles para modificarlos o eliminarlos. El atacante no puede exfiltrar datos directamente (ver) desde CodeChecker, debido a que está limitado a CSRF basado en formularios. Este problema afecta a CodeChecker: hasta 6.24.4.
Vulnerabilidad en CodeChecker (CVE-2025-1300)
Severidad: MEDIA
Fecha de publicación: 28/02/2025
Fecha de última actualización: 14/11/2025
CodeChecker es una herramienta de análisis, una base de datos de defectos y una extensión de visualización para Clang Static Analyzer y Clang Tidy. El servidor web CodeChecker contiene una vulnerabilidad de redireccionamiento abierto debido a la falta de protecciones contra múltiples barras después del nombre del producto en la URL. Esto hace que se evadan las protecciones contra CVE-2021-28861, lo que conduce a la misma vía de redireccionamiento abierto. Este problema afecta a CodeChecker: hasta la versión 6.24.5.
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-31357)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Un atacante no autenticado puede obtener la lista de plantas de un usuario conociendo el nombre de usuario.
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-31933)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Un atacante no autenticado puede comprobar la existencia de nombres de usuario en el sistema consultando una API.
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-31941)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Un atacante no autenticado puede obtener una lista de dispositivos inteligentes conociendo un nombre de usuario válido.
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-31949)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Un atacante autenticado puede obtener cualquier nombre de planta conociendo el ID de la planta.
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-24297)
Severidad: CRÍTICA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Debido a la falta de validación de entrada del lado del servidor, los atacantes pueden inyectar código JavaScript malicioso en los espacios personales de los usuarios del portal web.
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-24315)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Los atacantes no autenticados pueden agregar dispositivos de otros usuarios a sus escenas (o escenas arbitrarias de otros usuarios arbitrarios).
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-24850)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Un atacante puede exportar información de la planta de otros usuarios.
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-25276)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Un atacante no autenticado puede secuestrar los dispositivos de otros usuarios y potencialmente controlarlos.
Vulnerabilidad en Growatt (CVE-2025-26857)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Los atacantes no autenticados pueden cambiar el nombre de dispositivos arbitrarios de usuarios arbitrarios (es decir, cargadores de vehículos eléctricos).
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-27561)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Los atacantes no autenticados pueden cambiar el nombre de las "salas" de usuarios arbitrarios.
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-27565)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Un atacante no autenticado puede eliminar las "salas" de cualquier usuario al conocer los identificadores del usuario y de la sala.
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-27575)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Un atacante no autenticado puede obtener la versión del cargador EV y el historial de actualización del firmware conociendo el ID del cargador.
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-27719)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Los atacantes no autenticados pueden consultar un endpoint de API y obtener detalles del dispositivo.
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-27927)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Un atacante no autenticado puede obtener una lista de dispositivos inteligentes conociendo un nombre de usuario válido a través de una API desprotegida.
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-27929)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Los atacantes no autenticados pueden recuperar la lista completa de usuarios asociados con cuentas arbitrarias.
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-30257)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Los atacantes no autenticados pueden recuperar el número de serie de los medidores inteligentes asociados a una cuenta de usuario específica.
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-30510)
Severidad: CRÍTICA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Un atacante puede cargar un archivo arbitrario en lugar de una imagen de planta.
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-30512)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Los atacantes no autenticados pueden enviar configuraciones al dispositivo y posiblemente realizar acciones físicas de forma remota (por ejemplo, encendido/apagado).
Vulnerabilidad en Growatt Cloud Applications (CVE-2025-31147)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 14/11/2025
Los atacantes no autenticados pueden consultar información sobre la energía total consumida por los cargadores de vehículos eléctricos de usuarios arbitrarios.
Vulnerabilidad en kernel de Linux (CVE-2025-22039)
Severidad: ALTA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: corrección de desbordamiento en la comprobación de los límites de dacloffset. El campo dacloffset se tipificó originalmente como int y se usó en una adición sin comprobar, lo que podría desbordarse y omitir la comprobación de los límites existente tanto en smb_check_perm_dacl() como en smb_inherit_dacl(). Esto podría provocar un acceso a memoria fuera de los límites y un fallo del kernel al desreferenciar el puntero DACL. Este parche convierte dacloffset a unsigned int y utiliza check_add_overflow() para validar el acceso a la DACL.
Vulnerabilidad en kernel de Linux (CVE-2025-22043)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: agregar verificación de los límites para el contexto de identificador duradero. Agregar verificación de los límites faltante para el contexto de identificador duradero.
Vulnerabilidad en kernel de Linux (CVE-2025-22074)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige la discrepancia entre r_count decrement y decrement. r_count solo aumenta cuando hay una espera de interrupción de oplock, por lo que r_count inc/decrement no se empareja. Esto puede provocar que r_count sea negativo, lo que puede provocar un problema donde el subproceso ksmbd no termina.
Vulnerabilidad en kernel de Linux (CVE-2025-37776)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige el error "use-after-free" en smb_break_all_levII_oplock(). Existe una zona en smb_break_all_levII_oplock que puede causar problemas de velocidad al desbloquear en medio del bucle. Este parche utiliza un bloqueo de lectura para proteger todo el bucle.
Vulnerabilidad en kernel de Linux (CVE-2025-37777)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige el error "use-after-free" en __smb2_lease_break_noti(). Se mueve tcp_transport libre a ksmbd_conn_free. Si se hace referencia a la conexión ksmbd al finalizar el subproceso del servidor ksmbd, no se liberará, pero sí se liberará conn->tcp_transport. __smb2_lease_break_noti puede ejecutarse asincrónicamente cuando se desconecta la conexión. __smb2_lease_break_noti llama a ksmbd_conn_write, lo que puede causar un error "use-after-free" cuando conn->ksmbd_transport ya está liberado.
Vulnerabilidad en kernel de Linux (CVE-2025-37828)
Severidad: MEDIA
Fecha de publicación: 08/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: mcq: Agregar comprobación NULL en ufshcd_mcq_abort() Puede ocurrir una ejecución entre la ruta de finalización de MCQ y el controlador de aborto: una vez que se completa una solicitud, __blk_mq_free_request() establece rq->mq_hctx en NULL, lo que significa que la llamada ufshcd_mcq_req_to_hwq() posterior en ufshcd_mcq_abort() puede devolver un puntero NULL. Si se desreferencia este puntero NULL, el kernel se bloqueará. Agregue una comprobación NULL para el puntero hwq devuelto. Si hwq es NULL, registre un error y devuelva FAILED, lo que evita una posible desreferencia de puntero NULL. Como sugirió Bart, se elimina la comprobación ufshcd_cmd_inflight(). Esto es similar a la corrección en el commit 74736103fb41 ("scsi: ufs: core: Fix ufshcd_abort_one racing issue"). Esta corrección la encontró nuestra herramienta de análisis estático Knighter.
Vulnerabilidad en kernel de Linux (CVE-2025-37833)
Severidad: MEDIA
Fecha de publicación: 08/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/niu: Niu requiere que los campos ENTRY_DATA de MSIX se toquen antes de leer la entrada. Corrija niu_try_msix() para que no cause una trampa fatal en sistemas sparc. Establezca PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST en la estructura pci_dev para solucionar un error en el hardware o firmware. Para cada entrada de vector en la tabla msix, los chips niu causarán una trampa fatal si se lee algún registro en esa entrada antes de que se escriba en el registro ENTRY_DATA de esa entrada. Las pruebas indican que las escrituras en otros registros no son suficientes para evitar la trampa fatal; sin embargo, el valor no parece importar. Esto solo necesita suceder una vez después del encendido, por lo que simplemente reiniciar en un kernel que no tenga esta corrección NO causará la trampa. ERROR NO REANUDABLE: Informe de CPU 64 ERROR NO REANUDABLE: TPC [0x00000000005f6900] ERROR NO REANUDABLE: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffff ERROR NO REANUDABLE: 0000000800000000:00000000000000000:00000000000000000:00000000000000000] ERROR NO REANUDABLE: handle [0x4010000000000016] stick [0x00000e37f93e32ff] ERROR NO REANUDABLE: tipo [precise nonresumable] ERROR NO REANUDABLE: attrs [0x02000080] < ASI sp-faulted priv > ERROR NO REANUDABLE: raddr [0xffffffffffffffff] ERROR NO REANUDABLE: dirección efectiva insn [0x000000c50020000c] ERROR NO REANUDABLE: tamaño [0x8] ERROR NO REANUDABLE: asi [0x00] CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 No contaminado 6.11.5 #63 Cola de trabajo: eventos work_for_cpu_fn TSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 No contaminado TPC: g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100 g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000 o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620 o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128 RPC: <__pci_enable_msix_range+0x3cc/0x460> l0: 00000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020 l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734 i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000d i4: 000000000000000000000000000000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0 I7: Rastreo de llamadas: [<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu] [<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu] [<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu] [<00000000005ef3e4>] local_pci_probe+0x28/0x74 [<0000000000469240>] work_for_cpu_fn+0x8/0x1c [<000000000046b008>] process_scheduled_works+0x144/0x210 [<000000000046b518>] workers_thread+0x13c/0x1c0 [<00000000004710e0>] kthread+0xb8/0xc8 [<00000000004060c8>] ret_from_fork+0x1c/0x2c [<0000000000000000>] 0x0 Pánico del kernel: no se sincroniza: Error no reanudable.
Vulnerabilidad en kernel de Linux (CVE-2025-37834)
Severidad: MEDIA
Fecha de publicación: 08/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vmscan: no intente reclamar el folio hwpoison Syzkaller informa un error de la siguiente manera: Error de inyección de memoria para pfn 0x18b00e en la dirección virtual del proceso 0x20ffd000 Error de memoria: 0x18b00e: 2 usuarios aún hacen referencia a la página de swapcache sucia Error de memoria: 0x18b00e: acción de recuperación para la página de swapcache sucia: Página con errores: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(bloqueado|sucio|arch_1|swapbacked|hwpoison|nodo=0|zona=2|lastcpupid=0xfffff) sin procesar: 005ffffe00482011 muerto000000000100 muerto000000000122 ffff0000e232a7c9 sin procesar: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 página volcada porque: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) ------------[ cortar aquí ]------------ ¡ERROR del kernel en mm/swap_state.c:184! Error interno: Ups - BUG: 00000000f2000800 [#1] Módulos SMP vinculados: CPU: 0 PID: 60 Comm: kswapd0 No contaminado 6.6.0-gcb097e7de84e #3 Nombre del hardware: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : add_to_swap+0xbc/0x158 lr : add_to_swap+0xbc/0x158 sp : ffff800087f37340 x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19: fffffc00052c0380 x18: 000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9: dfff800000000000 x8: 00009fffc9274686 x7: ffff0001b6c5cbd3 x6: 000000000000001 x5: ffff0000c25896c0 x4: 0000000000000000 x3: 00000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Rastreo de llamadas: add_to_swap+0xbc/0x158 shrink_folio_list+0x12ac/0x2648 shrink_inactive_list+0x318/0x948 shrink_lruvec+0x450/0x720 shrink_node_memcgs+0x280/0x4a8 shrink_node+0x128/0x978 balance_pgdat+0x4f0/0xb20 kswapd+0x228/0x438 kthread+0x214/0x230 ret_from_fork+0x10/0x20 Puedo reproducir este problema con los siguientes pasos: 1) Cuando una página de caché de intercambio sucia es aislada por el proceso de recuperación y la página no está bloqueada, se inyecta un fallo de memoria para la página. me_swapcache_dirty() borra el indicador de actualización e intenta eliminarla de la unidad de recuperación (LRU), pero falla. El proceso de recuperación devolverá la página contaminada a la LRU. 2) El proceso que asigna la página contaminada sale, la página se elimina, la página nunca se liberará y permanecerá en la LRU para siempre. 3) Si activamos una recuperación de nuevo e intentamos recuperar la página, add_to_swap() activará VM_BUG_ON_FOLIO debido a que el indicador de actualización está borrado. Para solucionarlo, omita la página contaminada en la lista de recuperación (shrink_folio_list()). Además, es posible que el folio hwpoison aún no esté desasignado por hwpoison_user_mappings(), desasignelo en shrink_folio_list(), de lo contrario el folio no podrá ser desasignado por hwpoison_user_mappings() ya que el folio no está en la lista lru.
Vulnerabilidad en kernel de Linux (CVE-2025-37836)
Severidad: MEDIA
Fecha de publicación: 09/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: Se corrige una fuga de referencia en pci_register_host_bridge(). Si device_register() falla, se llama a put_device() para ceder la referencia y evitar una fuga de memoria, según el comentario en device_register(). Encontrado mediante revisión de código. [bhelgaas: squash la corrección doblemente gratuita de Dan Carpenter desde https://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain]
Vulnerabilidad en kernel de Linux (CVE-2025-37837)
Severidad: MEDIA
Fecha de publicación: 09/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/tegra241-cmdqv: Se corrigen las advertencias debido a dmam_free_coherent() Se observan dos ADVERTENCIAS cuando el controlador SMMU se revierte tras un error: arm-smmu-v3.9.auto: No se pudo registrar iommu arm-smmu-v3.9.auto: La sonda con el controlador arm-smmu-v3 falló con el error -22 ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 5 PID: 1 en kernel/dma/mapping.c:74 dmam_free_coherent+0xc0/0xd8 Rastreo de llamadas: dmam_free_coherent+0xc0/0xd8 (P) tegra241_vintf_free_lvcmdq+0x74/0x188 tegra241_cmdqv_remove_vintf+0x60/0x148 tegra241_cmdqv_remove+0x48/0xc8 arm_smmu_impl_remove+0x28/0x60 devm_action_release+0x1c/0x40 ------------[ cortar aquí ]------------ ¡128 páginas aún están en uso! ADVERTENCIA: CPU: 16 PID: 1 en mm/page_alloc.c:6902 free_contig_range+0x18c/0x1c8 Rastreo de llamadas: free_contig_range+0x18c/0x1c8 (P) cma_release+0x154/0x2f0 dma_free_contiguous+0x38/0xa0 dma_direct_free+0x10c/0x248 dma_free_attrs+0x100/0x290 dmam_free_coherent+0x78/0xd8 tegra241_vintf_free_lvcmdq+0x74/0x160 tegra241_cmdqv_remove+0x98/0x198 arm_smmu_impl_remove+0x28/0x60 devm_action_release+0x1c/0x40 Esto se debe a que devres gestiona la memoria de la cola LVCMDQ, mientras que dmam_free_coherent() se llama en el contexto de devm_action_release(). Jason señaló que "arm_smmu_impl_probe() ha ordenado incorrectamente las devoluciones de llamada de devres si ops->device_remove() va a liberar manualmente los recursos asignados por la sonda": https://lore.kernel.org/linux-iommu/20250407174408.GB1722458@nvidia.com/ De hecho, tegra241_cmdqv_init_structures() solo asigna recursos de memoria, lo que significa que cualquier fallo que genere sería similar a -ENOMEM, por lo que no tiene sentido recurrir a la rutina SMMU estándar, ya que es probable que la SMMU estándar tampoco asigne memoria. Elimine la parte de desenrollado en tegra241_cmdqv_init_structures() y devuelva un código de error adecuado para solicitar al controlador SMMU que llame a tegra241_cmdqv_remove() mediante impl_ops->device_remove(). Luego, elimine tegra241_vintf_free_lvcmdq(), ya que devres se encargará de ello.
Vulnerabilidad en kernel de Linux (CVE-2025-37839)
Severidad: ALTA
Fecha de publicación: 09/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jbd2: eliminar la comprobación incorrecta de sb->s_sequence. El vacío del diario no se determina por sb->s_sequence == 0, sino por sb->s_start == 0 (que se establece unas líneas más arriba). Además, 0 es un ID de transacción válido, por lo que la comprobación puede activarse falsamente. Eliminar el WARN_ON no válido.
Vulnerabilidad en kernel de Linux (CVE-2025-37840)
Severidad: ALTA
Fecha de publicación: 09/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: rawnand: brcmnand: fix PM resume WARNING Advertencia fija en la reanudación de PM como se muestra a continuación causada por una estructura nand_operation no inicializada que verifica el campo de selección de chip: WARN_ON(op->cs >= nanddev_ntargets(&chip->base) [ 14.588522] ------------[ cortar aquí ]------------ [ 14.588529] ADVERTENCIA: CPU: 0 PID: 1392 en drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8 [ 14.588553] Módulos vinculados en: bdc udc_core [ 14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: GW 6.14.0-rc4-g5394eea10651 #16 [ 14.588590] Contaminado: [W]=WARN [ 14.588593] Nombre del hardware: Broadcom STB (árbol de dispositivos aplanado) [ 14.588598] Rastreo de llamadas: [ 14.588604] dump_backtrace de show_stack+0x18/0x1c [ 14.588622] r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c [ 14.588625] show_stack de dump_stack_lvl+0x70/0x7c [ 14.588639] dump_stack_lvl de dump_stack+0x18/0x1c [14.588653] r5:c08d40b0 r4:c1003cb0 [14.588656] dump_stack de __warn+0x84/0xe4 [14.588668] __warn de warn_slowpath_fmt+0x18c/0x194 [14.588678] r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000 [14.588681] warn_slowpath_fmt de nand_reset_op+0x1e0/0x1f8 [14.588695] r8:70c40dff r7:89705f41 r6:36b4a597 r5:c26c9444 r4:c26b0048 [ 14.588697] nand_reset_op de brcmnand_resume+0x13c/0x150 [ 14.588714] r9:00000000 r8:00000000 r7:c24f8010 r6:c228a3f8 r5:c26c94bc r4:c26b0040 [ 14.588717] brcmnand_resume de platform_pm_resume+0x34/0x54 [ 14.588735] r5:00000010 r4:c0840a50 [ 14.588738] reanudación_pm_plataforma desde dpm_run_callback+0x5c/0x14c [ 14.588757] reanudación_pm_plataforma desde dispositivo_reanudación+0xc0/0x324 [ 14.588776] r9:c24f8054 r8:c24f80a0 r7:00000000 r6:00000000 r5:00000010 r4:c24f8010 [ 14.588779] reanudación_dispositivo desde dpm_resume+0x130/0x160 [ 14.588799] r9:c22539e4 r8:00000010 r7:c22bebb0 r6:c24f8010 r5:c22539dc r4:c22539b0 [ 14.588802] dpm_resume de dpm_resume_end+0x14/0x20 [ 14.588822] r10:c2204e40 r9:00000000 r8:c228a3fc r7:00000000 r6:00000003 r5:c228a414 [ 14.588826] r4:00000010 [ 14.588828] dpm_resume_end de suspender_dispositivos_e_entrar+0x274/0x6f8 [ 14.588848] r5:c228a414 r4:00000000 [ 14.588851] suspender_dispositivos_e_entrar desde pm_suspend+0x228/0x2bc [ 14.588868] r10:c3502910 r9:c3501f40 r8:00000004 r7:c228a438 r6:c0f95e18 r5:00000000 [ 14.588871] r4:00000003 [ 14.588874] pm_suspend desde state_store+0x74/0xd0 [ 14.588889] r7:c228a438 r6:c0f934c8 r5:00000003 r4:00000003 [ 14.588892] almacén de estado de kobj_attr_store+0x1c/0x28 [ 14.588913] r9:00000000 r8:00000000 r7:f09f9f08 r6:00000004 r5:c3502900 r4:c0283250 [ 14.588916] kobj_attr_store de sysfs_kf_write+0x40/0x4c [ 14.588936] r5:c3502900 r4:c0d92a48 [ 14.588939] sysfs_kf_write de kernfs_fop_write_iter+0x104/0x1f0 [14.588956] r5:c3502900 r4:c3501f40 [14.588960] kernfs_fop_write_iter de vfs_write+0x250/0x420 [14.588980] r10:c0e14b48 r9:00000000 r8:c25f5780 r7:00443398 r6:f09f9f68 r5:c34f7f00 [14.588983] r4:c042a88c [14.588987] vfs_write de ksys_write+0x74/0xe4 [ 14.589005] r10:00000004 r9:c25f5780 r8:c02002fA0 r7:00000000 r6:00000000 r5:c34f7f00 [ 14.589008] r4:c34f7f00 [ 14.589011] escritura del sistema desde escritura del sistema+0x10/0x14 [ 14.589029] r7:00000004 r6:004421c0 r5:00443398 r4:00000004 [ 14.589032] escritura del sistema desde llamada al sistema ret_fast+0x0/0x5c [ 14.589044] Pila de excepciones (0xf09f9fa8 a 0xf09f9ff0) [ 14.589050] 9fa0: 00000004 00443398 00000004 00443398 00000004 00000001 [ 14.589056] 9fc0: 00000004 00443398 004421c0 00000004 b6ecbd58 00000008 bebfbc38 0043eb78 [ 14.589062] 9fe0: 00440eb0 bebfbaf8 b6de18a0 b6e579e8 [ 14.589065] ---[ fin de traza 0000000000000000 ]--- La corrección utiliza el nivel superior nand_reset(chip, chipnr); donde chipnr = 0, al realizar la operación de reanudación de PM, de acuerdo con la compatibilidad del controlador con chips NAND de una sola matriz. Cambio de nand_reset_op() a nan ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2025-37954)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: Evitar la competencia en open_cached_dir con interrupciones de arrendamiento. Un cfid válido preexistente devuelto desde find_or_create_cached_dir podría competir con una interrupción de arrendamiento, lo que significa que open_cached_dir no lo considera válido y cree que es de nueva construcción. Esto filtra una referencia de dentry si la asignación ocurre antes de que se ejecute el trabajo de interrupción de arrendamiento en cola. Evite la competencia extendiendo la retención de cfid_list_lock a través de find_or_create_cached_dir y cuando se comprueba el resultado.
Vulnerabilidad en v (CVE-2025-37955)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio-net: xsk_buffs libres en caso de error en virtnet_xsk_pool_enable() Las autopruebas añadidas a nuestra CI por Bui Quang Minh revelan recientemente que hay una fuga de memoria en la ruta de error de virtnet_xsk_pool_enable(): objeto sin referencia 0xffff88800a68a000 (tamaño 2048): comm "xdp_helper", pid 318, jiffies 4294692778 volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ seguimiento inverso (crc 0): __kvmalloc_node_noprof+0x402/0x570 virtnet_xsk_pool_enable+0x293/0x6a0 (drivers/net/virtio_net.c:5882) xp_assign_dev+0x369/0x670 (net/xdp/xsk_buff_pool.c:226) xsk_bind+0x6a5/0x1ae0 __sys_bind+0x15e/0x230 __x64_sys_bind+0x72/0xb0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Vulnerabilidad en kernel de Linux (CVE-2025-37956)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: impide renombrar con una cadena vacía. El cliente puede enviar una cadena vacía de nombre nuevo al servidor ksmbd. Esto provocará un error de kernel desde d_alloc. Este parche devuelve el error al intentar renombrar un archivo o directorio con una cadena vacía de nombre nuevo.
Vulnerabilidad en kernel de Linux (CVE-2025-37957)
Severidad: ALTA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: SVM: Forzar la salida del modo SMM al interceptar el apagado. Anteriormente, el commit ed129ec9057f ("KVM: x86: forzar la salida del modo anidado al reiniciar la vCPU") solucionó un problema en el que una triple falla en el modo anidado podía provocar escenarios de use-after-free. Sin embargo, esta confirmación no solucionó la situación análoga para el modo de administración del sistema (SMM). Esta omisión provoca la activación de una advertencia cuando KVM fuerza una inicialización de la vCPU tras la interceptación del apagado mientras esta se encuentra en SMM. Esta situación se reprodujo utilizando Syzkaller mediante: 1) la creación de una máquina virtual KVM y vCPU 2) el envío de un ioctl KVM_SMI para ingresar explícitamente a SMM 3) la ejecución de instrucciones no válidas que causan excepciones consecutivas y, finalmente, un fallo triple El problema se manifiesta de la siguiente manera: ADVERTENCIA: CPU: 0 PID: 25506 en arch/x86/kvm/x86.c:12112 kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Módulos vinculados en: CPU: 0 PID: 25506 Comm: syz-executor.0 No contaminado 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 01/04/2014 RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Rastreo de llamadas: shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpu_enter_guest arch/x86/kvm/x86.c:10959 [en línea] vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:870 [en línea] __se_sys_ioctl fs/ioctl.c:856 [en línea] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Arquitectónicamente, INIT se bloquea cuando la CPU está en SMM, de ahí el WARN() de KVM en kvm_vcpu_reset() para protegerse contra errores de KVM, por ejemplo, para detectar una emulación incorrecta de INIT. SHUTDOWN en SVM es un caso extremo extraño en el que KVM necesita hacer _algo_ sensato con el VMCB, ya que técnicamente no está definido, e INIT es la opción menos terrible dada la ABI de KVM. Así que, redobla la apuesta por el uso excesivo de INIT al apagar y fuerza la salida de la vCPU de SMM para evitar cualquier anomalía (y la advertencia). Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con Syzkaller. [sean: revisa el registro de cambios, aclara que esto no es un comportamiento arquitectónico]
Vulnerabilidad en kernel de Linux (CVE-2025-37960)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memblock: aceptar memoria asignada antes de su uso en memblock_double_array(). Al aumentar el tamaño de la matriz en memblock_double_array() y la losa aún no está disponible, se utiliza una llamada a memblock_find_in_range() para reservar/asignar memoria. Sin embargo, es posible que no se haya aceptado el rango devuelto, lo que puede provocar un bloqueo al iniciar un invitado SNP: RIP: 0010:memcpy_orig+0x68/0x130 Código: ... RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000 RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00 RBP: 0000000000002000 R08: 000000000000000 R09: 0000000000002000 R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78 R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00 memblock_double_array+0xff/0x310 memblock_add_range+0x1fb/0x2f0 memblock_reserve+0x4f/0xa0 memblock_alloc_range_nid+0xac/0x130 memblock_alloc_internal+0x53/0xc0 memblock_alloc_try_nid+0x3d/0xa0 swiotlb_init_remap+0x149/0x2f0 mem_init+0xb/0xb0 mm_core_init+0x8f/0x350 start_kernel+0x17e/0x5d0 x86_64_start_reservations+0x14/0x30 x86_64_start_kernel+0x92/0xa0 secondary_startup_64_no_verify+0x194/0x19b Para mitigar este problema, llame a accept_memory() en el rango de memoria devuelto antes de que el slab esté disponible. Antes de la versión 6.12, la interfaz accept_memory() utilizaba los parámetros "start" y "end" en lugar de "start" y "size". Por lo tanto, la llamada a accept_memory() debe ajustarse para especificar "start + size" en lugar de "end" al aplicarlo a kernels anteriores a la versión 6.12.
Vulnerabilidad en kernel de Linux (CVE-2025-37965)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Corrección de error de contexto no válido en el asistente dml [Por qué] Error "BUG: función inactiva llamada desde un contexto no válido". Después: "drm/amd/display: Proteger FPU en dml2_validate()/dml21_validate()". La función populate_dml_plane_cfg_from_plane_state() utiliza el indicador GFP_KERNEL para la asignación de memoria, que no debería usarse en contextos atómicos. Esta asignación solo es necesaria para usar otra función auxiliar, get_scaler_data_for_plane(). [Cómo] Modificar los asistentes para que pasen un puntero a scaler_data dentro del contexto existente, eliminando la necesidad de asignar/desasignar memoria dinámicamente y copiar. (Seleccionado de el commit bd3e84bc98f81b44f2c43936bdadc3241d654259)
Vulnerabilidad en kernel de Linux (CVE-2025-37971)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: bcm2835-camera: Inicializar dev en v4l2_dev. el commit 42a2f6664e18 ("staging: vc04_services: Mover global g_state a vchiq_state") modificó mmal_init para pasar dev->v4l2_dev.dev a vchiq_mmal_init. Sin embargo, no se inicializó dev->v4l2_dev, por lo que se obtuvo una desreferencia de puntero nulo. Se estableció dev->v4l2_dev.dev durante bcm2835_mmal_probe. El puntero del dispositivo se podría pasar a v4l2_device_register para establecerlo; sin embargo, esto también tiene otros efectos que requerirían cambios adicionales.
Vulnerabilidad en kernel de Linux (CVE-2025-37973)
Severidad: ALTA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: corrección de acceso fuera de los límites durante la desfragmentación de elementos multienlace. Actualmente, durante el proceso de desfragmentación de elementos multienlace, la longitud de este elemento se sumaba a la longitud total de los elementos de entrada (IE) al calcular la longitud de los elementos de entrada restantes después del elemento multienlace en cfg80211_defrag_mle(). Esto podría provocar un acceso fuera de los límites si el elemento multienlace o sus elementos de fragmento correspondientes son los últimos elementos en el búfer de los elementos de entrada. Para solucionar este problema, calcule correctamente la longitud de los elementos de entrada restantes restando el desplazamiento final del elemento multienlace del desplazamiento final total de los elementos de entrada.
Vulnerabilidad en kernel de Linux (CVE-2025-37974)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/pci: Se corrige la falta de comprobación para el retorno del error zpci_create_device(). La función zpci_create_device() devuelve un puntero de error que debe comprobarse antes de desreferenciarlo como puntero struct zpci_dev. Se añade la comprobación faltante en __clp_add(), donde se omitió al añadir la lista de escaneo en el commit corregida. Simplemente no añadir el dispositivo a la lista de escaneo provoca el comportamiento anterior.
Vulnerabilidad en kernel de Linux (CVE-2025-37975)
Severidad: ALTA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: módulo: Corrección de acceso de reubicación fuera de los límites. El código actual permite que rel[j] acceda a un elemento después del final de la sección de reubicación. Simplificar a num_relocations, que equivale a la expresión de tamaño existente.
Vulnerabilidad en kernel de Linux (CVE-2025-37977)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: exynos: Deshabilitar iocc si la propiedad dma-coherent no está establecida. Si la propiedad dma-coherent no está establecida, los descriptores no se pueden almacenar en caché y los bits de compartición de iocc deben estar deshabilitados. Sin esto, UFS puede terminar en una configuración incompatible y sufrir problemas de estabilidad aleatorios relacionados con la caché.
Vulnerabilidad en kernel de Linux (CVE-2025-37978)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: integridad: No llamar a set_page_dirty_lock(). Colocar varios búferes de información de protección dentro de la misma página puede provocar errores, ya que set_page_dirty_lock() no se puede llamar desde el contexto de interrupción. Dado que un búfer de información de protección no está respaldado por un archivo, no tiene sentido configurar su página como sucia; no hay nada que sincronizar. Elimine la llamada a set_page_dirty_lock() y elimine el último argumento de bio_integrity_unpin_bvec().
Vulnerabilidad en kernel de Linux (CVE-2025-37980)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corrección de fuga de recursos en la ruta de error blk_register_queue(). Si el registro de una cola falla después de que blk_mq_sysfs_register() se ejecute correctamente, pero la función detecta un error posteriormente, es necesario limpiar los recursos blk_mq_sysfs. Agregue la llamada blk_mq_sysfs_unregister() faltante en la ruta de error para limpiar correctamente estos recursos y evitar una fuga de memoria.
Vulnerabilidad en kernel de Linux (CVE-2025-37981)
Severidad: ALTA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: smartpqi: Usar is_kdump_kernel() para comprobar kdump. El controlador smartpqi comprueba la variable reset_devices para determinar si es necesario realizar ajustes especiales para kdump. Esto provoca que, tras un reinicio normal de kexec, algunos parámetros del controlador, como max_transfer_size, sean mucho más bajos de lo habitual. Es más, las pruebas de reinicio de kexec han revelado corrupción de memoria causada por la escritura del registro del controlador en la memoria del sistema después de un kexec. Para solucionar esto, pruebe is_kdump_kernel() en lugar de reset_devices cuando corresponda.
Vulnerabilidad en kernel de Linux (CVE-2025-37984)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: ecdsa - Protección contra desbordamientos de enteros en DIV_ROUND_UP(). Herbert señala que DIV_ROUND_UP() puede desbordarse innecesariamente si la función de retorno ->key_size() de una implementación de ecdsa devuelve un valor inusualmente grande. En su lugar, Herbert sugiere (para una división entre 8): X / 8 + !!(X y 7). Con base en esta fórmula, introduzca una macro genérica DIV_ROUND_UP_POW2() y úsela en lugar de DIV_ROUND_UP() para los valores de retorno de ->key_size(). Además, utilice la macro en ecc_digits_from_bytes(), cuyo parámetro "nbytes" es un valor de retorno de ->key_size() en algunos casos, o una longitud ASN.1 especificada por el usuario en el caso de ecdsa_get_signature_rs().
Vulnerabilidad en kernel de Linux (CVE-2025-37986)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: class: Invalidación de punteros de dispositivos USB al cancelar el registro del socio. Para evitar el uso de punteros de dispositivos USB no válidos tras la desconexión de un socio de tipo C, este parche borra los punteros al cancelar el registro del socio. Esto garantiza un estado limpio para futuras conexiones.
Vulnerabilidad en kernel de Linux (CVE-2025-37987)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pds_core: Prevenir posible condición de desbordamiento/atascamiento de adminq El adminq de pds_core está protegido por adminq_lock, que impide que se le envíe más de 1 comando a la vez. Esto hace que los controladores del cliente no puedan enviar comandos adminq simultáneamente. Sin embargo, las finalizaciones ocurren en un contexto diferente, lo que significa que se pueden enviar múltiples comandos adminq secuencialmente y todos esperando a ser completados. En el lado del FW, la cola de solicitudes adminq de respaldo solo tiene 16 entradas y falta el mecanismo de reintento o la prevención de desbordamiento/atascamiento. Esto puede provocar que adminq se atasque, por lo que el FW ya no procesa los comandos y ya no envía las finalizaciones. Como solución inicial, evite que haya más de 16 comandos adminq pendientes para que no haya forma de provocar que adminq se atasque. Esto funciona porque la cola de solicitudes adminq de respaldo nunca tendrá más de 16 comandos adminq pendientes, por lo que nunca se desbordará. Esto se hace reduciendo la profundidad de adminq a 16.
Vulnerabilidad en kernel de Linux (CVE-2025-37988)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: corrige un par de ejecucións en el manejo de MNT_TREE_BENEATH por do_move_mount() Normalmente do_lock_mount(path, _) está bloqueando un punto de montaje fijado por *path y en el momento en que la coincidencia de unlock_mount() desbloquea esa ubicación, todavía está fijado por la misma cosa. Desafortunadamente, para el caso 'debajo' ya no es tan simple: el objeto que se bloquea no es el que *path apunta. Es el punto de montaje de path->mnt. El problema es que, sin un bloqueo suficiente, ->mnt_parent puede cambiar debajo de nosotros y ninguno de los bloqueos se mantiene en ese punto. Las reglas son * mount_lock estabiliza m->mnt_parent para cualquier montaje m. * namespace_sem estabiliza m->mnt_parent, siempre que m esté montado. * si se cumple alguna de las anteriores y refcount de m es positivo, se nos garantiza lo mismo para refcount de m->mnt_parent. namespace_sem se anida dentro de inode_lock(), por lo que do_lock_mount() debe tomar inode_lock() antes de obtener namespace_sem. Vuelve a comprobar que path->mnt siga montado en el mismo lugar después de obtener namespace_sem y se encarga de fijar el dentry. Esto es necesario, ya que, de lo contrario, podríamos terminar con una ejecución de mount --move (o umount) mientras obteníamos bloqueos; en ese caso, el dentry dejaría de ser un punto de montaje y podría haber sido expulsado por presión de memoria junto con su inodo, algo que no se desea al obtener el bloqueo de ese inodo. Sin embargo, fijar un dentry no es suficiente; el montaje correspondiente también está fijado solo por el hecho de que path->mnt está montado sobre él y, en ese momento, no tenemos ningún bloqueo. Por lo tanto, el mismo tipo de ejecución podría terminar con todas las referencias a ese montaje eliminadas justo cuando estamos a punto de entrar en inode_lock(). Si esto ocurre, el sistema de archivos se apaga mientras mantenemos una referencia dentry; los resultados no son muy alentadores. Necesitamos obtener dentry y mount simultáneamente; esto hace que inode_lock() sea seguro *y* evita el problema de que el sistema de archivos se apague bajo nuestra supervisión. Después de obtener namespace_sem, verificamos que path->mnt siga montado (lo que estabiliza su ->mnt_parent) y comprobamos que siga montado en el mismo lugar. Desde ese punto hasta la ejecución correspondiente de namespace_unlock(), tenemos la garantía de que el par mount/dentry que obtuvimos también está fijado al ser el punto de montaje de path->mnt, por lo que podemos eliminar discretamente tanto la referencia dentry (como hace el código actual) como la de mnt; esto es correcto en namespace_sem, ya que no eliminamos las referencias finales. Esto resuelve el problema en do_lock_mount(); unlock_mount() también tiene uno, ya que se garantiza que dentry permanecerá fijado solo hasta la ejecución de namespace_unlock(). Esto es fácil de solucionar: solo hay que hacer inode_unlock() antes, mientras todavía está fijado por mp->m_dentry.
Vulnerabilidad en kernel de Linux (CVE-2025-37993)
Severidad: MEDIA
Fecha de publicación: 29/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: m_can: m_can_class_allocate_dev(): inicializar spinlock en la sonda del dispositivo. El spinlock tx_handling_spinlock en la estructura m_can_classdev no se está inicializando. Esto provoca la siguiente queja de spinlock bad magic del kernel, p. ej. al intentar enviar tramas CAN con cansend desde can-utils: | BUG: spinlock bad magic en CPU#0, cansend/95 | lock: 0xff60000002ec1010, .magic: 00000000, .owner: /-1, .owner_cpu: 0 | CPU: 0 UID: 0 PID: 95 Comm: cansend No contaminado 6.15.0-rc3-00032-ga79be02bba5c #5 NONE | Nombre del hardware: MachineWare SIM-V (DT) | Rastreo de llamadas: | [] dump_backtrace+0x1c/0x24 | [] show_stack+0x28/0x34 | [] dump_stack_lvl+0x4a/0x68 | [] dump_stack+0x14/0x1c | [] spin_dump+0x62/0x6e | [] do_raw_spin_lock+0xd0/0x142 | [] _raw_spin_lock_irqsave+0x20/0x2c | [] m_can_start_xmit+0x90/0x34a | [] dev_hard_start_xmit+0xa6/0xee | [] sch_direct_xmit+0x114/0x292 | [] __dev_queue_xmit+0x3b0/0xaa8 | [] can_send+0xc6/0x242 | [] raw_sendmsg+0x1a8/0x36c | [] sock_write_iter+0x9a/0xee | [] vfs_write+0x184/0x3a6 | [] ksys_write+0xa0/0xc0 | [] __riscv_sys_write+0x14/0x1c | [] do_trap_ecall_u+0x168/0x212 | [] handle_exception+0x146/0x152 Inicializar el bloqueo de giro en m_can_class_allocate_dev resuelve ese problema.
Vulnerabilidad en kernel de Linux (CVE-2025-37996)
Severidad: MEDIA
Fecha de publicación: 29/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: arm64: Corrección de un puntero de memcache no inicializado en user_mem_abort(). El commit fce886a60207 ("KVM: arm64: Conectar la MMU pKVM en KVM") hizo que la inicialización de la variable de memcache local en user_mem_abort() fuera condicional, dejando la ruta de código donde se usa sin inicializar mediante kvm_pgtable_stage2_map(). Esto puede fallar en cualquier ruta que requiera una asignación de etapa 2 sin transición debido a un fallo de permiso o un registro incorrecto. Para solucionar esto, asegúrese de que la memcache sea siempre válida.
Vulnerabilidad en kernel de Linux (CVE-2025-37999)
Severidad: MEDIA
Fecha de publicación: 29/05/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/erofs/fileio: llamar a erofs_onlinefolio_split() después de bio_add_folio(). Si bio_add_folio() falla (porque está lleno), erofs_fileio_scan_folio() debe enviar la solicitud de E/S mediante erofs_fileio_rq_submit() y asignar una nueva solicitud de E/S con un `struct bio` vacío. Luego, vuelve a intentar la llamada a bio_add_folio(). Sin embargo, en este punto, ya se ha llamado a erofs_onlinefolio_split(), lo que incrementa `folio->private`; el reintento llamará a erofs_onlinefolio_split() de nuevo, pero nunca habrá una llamada erofs_onlinefolio_end() coincidente. Esto deja el folio bloqueado para siempre y todos los que esperan quedarán atascados en folio_wait_bit_common(). Este error se añadió con el commit ce63cb62d794 ("erofs: compatibilidad con inodos no codificados para fileio"), pero era prácticamente imposible de solucionar porque había espacio para 256 folios en la estructura `struct bio`, hasta el commit 9f74ae8c9ac9 ("erofs: acortar bvecs[] para montajes con respaldo de archivo"), que redujo la capacidad del array a 16 folios. Ahora era fácil activar el error invocando manualmente la lectura anticipada desde el espacio de usuario, por ejemplo: posix_fadvise(fd, 0, st.st_size, POSIX_FADV_WILLNEED); Esto debería solucionarse invocando erofs_onlinefolio_split() solo después de que bio_add_folio() se haya ejecutado correctamente. Esto es seguro: las finalizaciones asincrónicas que invocan erofs_onlinefolio_end() no desbloquearán el folio porque erofs_fileio_scan_folio() todavía contiene una referencia que erofs_onlinefolio_end() liberará al final.
Vulnerabilidad en kernel de Linux (CVE-2025-38002)
Severidad: MEDIA
Fecha de publicación: 06/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/fdinfo: captura ctx->uring_lock en torno a io_uring_show_fdinfo(). No todo requiere bloqueo, razón por la cual existe la variable 'has_lock'. Sin embargo, suficientes requieren bloqueo como para que sea un poco difícil de manejar. Envuelva todo en un trylock `->uring_lock` y simplemente devuelva sin salida si no logramos capturarlo. El trylock() existente ya tendrá una utilidad/salida considerablemente reducida en caso de fallo. Esto soluciona un problema con la lectura de los campos SQE si el anillo se está redimensionando activamente al mismo tiempo.
Vulnerabilidad en codesiddhant Jasmin Ransomware (CVE-2025-6095)
Severidad: MEDIA
Fecha de publicación: 15/06/2025
Fecha de última actualización: 14/11/2025
Se encontró una vulnerabilidad clasificada como crítica en codesiddhant Jasmin Ransomware 1.0.1. La función afectada es desconocida en el archivo /checklogin.php. La manipulación del argumento nombre de usuario/contraseña provoca una inyección SQL. Es posible ejecutar el ataque de forma remota. Se ha hecho público el exploit y puede que sea utilizado. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
Vulnerabilidad en codesiddhant Jasmin Ransomware (CVE-2025-6096)
Severidad: MEDIA
Fecha de publicación: 16/06/2025
Fecha de última actualización: 14/11/2025
Se ha detectado una vulnerabilidad en codesiddhant Jasmin Ransomware hasta la versión 1.0.1, clasificada como crítica. Esta vulnerabilidad afecta a una funcionalidad desconocida del archivo /dashboard.php. La manipulación del argumento "Search" provoca una inyección SQL. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
Vulnerabilidad en kernel de Linux (CVE-2025-38006)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mctp: No acceder a ifa_index si falta. En mctp_dump_addrinfo, ifa_index puede usarse para filtrar interfaces, pero solo cuando se proporciona la estructura ifaddrmsg. De lo contrario, se comparará con memoria no inicializada, lo cual es reproducible en el caso de syzkaller desde dhcpd o "ip addr show" de busybox. La implementación de MCTP del kernel siempre ha filtrado por ifa_index, por lo que los programas de espacio de usuario que esperan volcar direcciones MCTP ya deben estar pasando un valor válido de ifa_index (0 o un índice real). ERROR: KMSAN: valor no inicializado en mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824 netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309
Vulnerabilidad en kernel de Linux (CVE-2025-38014)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: idxd: Refactorizar la llamada de eliminación con el asistente idxd_cleanup(). Este asistente limpia el monitor de rendimiento, las interrupciones, los componentes internos, etc. Refactorizar la llamada de eliminación con el asistente idxd_cleanup() para evitar la duplicación de código. Cabe destacar que esto también corrige la función put_device() que faltaba para los grupos, motores y máquinas virtuales idxd.
Vulnerabilidad en kernel de Linux (CVE-2025-38016)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: bpf: abortar envío si dispositivo destruido La implementación actual de HID bpf asume que no pasará por ella ningún informe/solicitud de salida después de que se haya llamado a hid_bpf_destroy_device(). Esto lleva a un error que al desconectar ciertos tipos de dispositivos HID hace que se acceda a una SRCU limpiada. El error era anteriormente un fallo oculto hasta que un cambio reciente de x86 por CPU [1] hizo que accediera a páginas no presentes. El error se activará si se cumplen las siguientes condiciones: A) un dispositivo bajo el controlador tiene algunos LED encendidos B) hid_ll_driver->request() no está implementado (por ejemplo, logitech-djreceiver) Si se cumple la condición A, hidinput_led_worker() siempre se programa *después* de hid_bpf_destroy_device(). hid_destroy_device ` hid_bpf_destroy_device ` cleanup_srcu_struct(&hdev->bpf.srcu) ` hid_remove_device ` ... ` led_classdev_unregister ` led_trigger_set(led_cdev, NULL) ` led_set_brightness(led_cdev, LED_OFF) ` ... ` input_inject_event ` input_event_dispose ` hidinput_input_event ` schedule_work(&hid->led_work) [hidinput_led_worker] Esto funciona correctamente cuando no se cumple la condición B, en cuyo caso hidinput_led_worker() invoca hid_ll_driver->request(). Este es el caso de la mayoría de los controladores HID, que lo implementan o utilizan el genérico de usbhid. El propio controlador o uno subyacente abortará el procesamiento de la solicitud. De lo contrario, hidinput_led_worker() intenta hid_hw_output_report() y genera el error. hidinput_led_worker ` hid_hw_output_report ` dispatch_hid_bpf_output_report ` srcu_read_lock(&hdev->bpf.srcu) ` srcu_read_unlock(&hdev->bpf.srcu, idx) El error existe desde la introducción [2] de dispatch_hid_bpf_output_report(). Sin embargo, el mismo error también existe en dispatch_hid_bpf_raw_requests(), y he reproducido (sin efecto visible debido a la falta de [1], pero confirmado bpf.destroyed == 1) el error contra el commit (es decir, las correcciones:) que introduce la función. Esto se debe a que hidinput_led_worker() recurre a hid_hw_raw_request() cuando hid_ll_driver->output_report() no está implementado (p. ej., logitech- djreceiver). hidinput_led_worker ` hid_hw_output_report: -ENOSYS ` hid_hw_raw_request ` dispatch_hid_bpf_raw_requests ` srcu_read_lock(&hdev->bpf.srcu) ` srcu_read_unlock(&hdev->bpf.srcu, idx) Corrija el problema retornando antes en las dos funciones mencionadas si hid_bpf se marcó como destruido. Aunque dispatch_hid_bpf_device_event() maneja eventos de entrada y no hay evidencia de que pueda llamarse después de la destrucción, también se le agrega la misma verificación, como red de seguridad, para mantener la consistencia entre todas las funciones de despacho. El impacto del error en otras arquitecturas no está claro. Incluso si se trata de un fallo oculto, sigue siendo peligroso, ya que corrompe la dirección calculada por SRCU. Por lo tanto, se copia la lista estable. [1]: commit 9d7de2aa8b41 ("x86/percpu/64: Usar desplazamientos relativos por CPU") [2]: commit 9286675a2aed ("HID: bpf: añadir enlaces HID-BPF para hid_hw_output_report")
Vulnerabilidad en kernel de Linux (CVE-2025-38017)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/eventpoll: corrige un bucle ocupado sin fin después de que expira el tiempo de espera Después de el commit 0a65bc27bd64 ("eventpoll: establece el tiempo de espera de epoll si es en el futuro"), el siguiente programa ingresaría inmediatamente en un bucle ocupado en el kernel: ``` int main() { int e = epoll_create1(0); struct epoll_event event = {.events = EPOLLIN}; epoll_ctl(e, EPOLL_CTL_ADD, 0, &event); const struct timespec timeout = {.tv_nsec = 1}; epoll_pwait2(e, &event, 1, &timeout, 0); } ``` Esto sucede porque el tiempo de espera dado (distinto de cero) de 1 nanosegundo generalmente expira antes de que se ingrese ep_poll() y luego ep_schedule_timeout() devuelve falso, pero `timed_out` nunca se establece porque se omite la línea de código que lo establece. Esto rápidamente se convierte en un bloqueo suave, RCU se bloquea y se bloquea, lo que inflige graves dolores de cabeza a todo el sistema. Cuando el tiempo de espera ha expirado, no necesitamos programar un hrtimer, pero debemos establecer la variable `timed_out`. Por lo tanto, sugiero mover la comprobación de ep_schedule_timeout() a la expresión `timed_out` en lugar de omitirla. brauner: Tenga en cuenta que hubo una corrección anterior por Joe Damato en respuesta a mi informe de error en [1].
Vulnerabilidad en kernel de Linux (CVE-2025-38019)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: spectrum_router: Se corrige el use-after-free al eliminar dispositivos de red GRE. El controlador solo descarga a los vecinos que se construyen sobre dispositivos de red registrados por él o sus superiores (que son todos Ethernet). El dispositivo admite la encapsulación y desencapsulación GRE del tráfico reenviado, pero el controlador no descargará vecinos ficticios construidos sobre dispositivos de red GRE ya que no son superiores a sus dispositivos de red: # ip link add name gre1 up type gre tos heritage local 192.0.2.1 remote 198.51.100.1 # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 NOARP (Tenga en cuenta que el vecino no está marcado con 'offload') Cuando se vuelve a cargar el controlador y se reproduce la configuración existente, el controlador no realiza la misma comprobación con respecto a los vecinos existentes y descarga el agregado previamente: # devlink dev reload pci/0000:01:00.0 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 offload NOARP Si el vecino se elimina más tarde, el controlador ignorará la notificación (dado que el dispositivo de red GRE no es su superior) y, por lo tanto, seguirá haciendo referencia a la memoria liberada, lo que dará como resultado un use-after-free [1] cuando se elimine el dispositivo de red: # ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1 # ip link del dev gre1 Se soluciona omitiendo la reproducción del vecino si el dispositivo de red para el que se realiza la reproducción no es nuestro superior. [1] ERROR: KASAN: slab-use-after-free en mlxsw_sp_neigh_entry_update+0x1ea/0x200 Lectura de tamaño 8 en la dirección ffff888155b0e420 por la tarea ip/2282 [...] Rastreo de llamadas: dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6f/0x350 print_report+0x108/0x205 kasan_report+0xdf/0x110 mlxsw_sp_neigh_entry_update+0x1ea/0x200 mlxsw_sp_router_rif_gone_sync+0x2a8/0x440 mlxsw_sp_rif_destroy+0x1e9/0x750 mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0 mlxsw_sp_router_netdevice_event+0x3ac/0x15e0 notifier_call_chain+0xca/0x150 call_netdevice_notifiers_info+0x7f/0x100 unregister_netdevice_many_notify+0xc8c/0x1d90 rtnl_dellink+0x34e/0xa50 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x131/0x360 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x121/0x1b0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Vulnerabilidad en kernel de Linux (CVE-2025-38021)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se corrige la comprobación nula de pipe_ctx->plane_state para update_dchubp_dpp. Similar a el commit 6a057072ddd1 ("drm/amd/display: Se corrige la comprobación nula de pipe_ctx->plane_state en dcn20_program_pipe"), que soluciona una desreferencia de puntero nulo en dcn20_update_dchubp_dpp. Esta es la misma función asociada a update_dchubp_dpp en dcn401, con el mismo problema. También se corrige una posible desreferencia de puntero nulo en dcn401_program_pipe. (Seleccionado de el commit d8d47f739752227957d8efc0cb894761bfe1d879)
Vulnerabilidad en kernel de Linux (CVE-2025-38022)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/core: Solución del problema "KASAN: slab-use-after-free Read in ib_register_device" Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 strlen+0x93/0xa0 lib/string.c:420 __fortify_strlen include/linux/fortify-string.h:268 [inline] get_kobj_path_length lib/kobject.c:118 [inline] kobject_get_path+0x3f/0x2a0 lib/kobject.c:158 kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545 ib_register_device drivers/infiniband/core/device.c:1472 [inline] ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393 rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmsg+0x16d/0x220 net/socket.c:2652 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Este problema es Similar al problema corregido en el commit 1d6a9e7449e2 ("RDMA/core: Corrección del problema de use-after-free al cambiar el nombre del dispositivo"). La causa principal es que la función ib_device_rename() cambia el nombre con bloqueo. Sin embargo, en la función kobject_uevent(), se accede a este nombre sin protección de bloqueo. La solución es añadir la protección de bloqueo al acceder a este nombre en la función kobject_uevent().
Vulnerabilidad en kernel de Linux (CVE-2025-38025)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: ad7606: comprobar si el puntero a la función sw_mode_config() es nulo. Compruebe que el puntero a la función sw_mode_config no sea nulo antes de llamarlo. No todos los buses definen esta función, lo que provocaba una desreferencia del puntero nulo.
Vulnerabilidad en kernel de Linux (CVE-2025-38028)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFS/localio: Se corrige una ejecución en nfs_local_open_fh(). Una vez eliminado el bloqueo clp->cl_uuid.lock, otra CPU podría entrar y liberar la estructura nfsd_file recién agregada. Para evitarlo, tome el bloqueo de lectura de la RCU antes de eliminar el bloqueo de giro.
Vulnerabilidad en kernel de Linux (CVE-2025-38029)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kasan: evitar la asignación de páginas inactivas desde un contexto atómico. apply_to_pte_range() entra en el modo MMU perezoso e invoca la devolución de llamada kasan_populate_vmalloc_pte() en cada iteración del recorrido de la tabla de páginas. Sin embargo, la devolución de llamada puede entrar en modo inactivo al intentar asignar una sola página, por ejemplo, si una arquitectura deshabilita la preempción al entrar en el modo MMU perezoso. En s390, si se hace arch_enter_lazy_mmu_mode() -> preempt_enable() y arch_leave_lazy_mmu_mode() -> preempt_disable(), se produce el siguiente fallo: [0.663336] ERROR: función inactiva llamada desde un contexto no válido en ./include/linux/sched/mm.h:321 [0.663348] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd [0.663358] preempt_count: 1, esperado: 0 [0.663366] Profundidad de anidamiento de RCU: 0, esperado: 0 [0.663375] kthreadd/2 no mantiene bloqueos. [ 0.663383] Preempción deshabilitada en: [ 0.663386] [<0002f3284cbb4eda>] apply_to_pte_range+0xfa/0x4a0 [ 0.663405] CPU: 0 UID: 0 PID: 2 Comm: kthreadd No contaminado 6.15.0-rc5-gcc-kasan-00043-gd76bb1ebb558-dirty #162 PREEMPT [ 0.663408] Nombre del hardware: IBM 3931 A01 701 (KVM/Linux) [ 0.663409] Rastreo de llamadas: [ 0.663410] [<0002f3284c385f58>] dump_stack_lvl+0xe8/0x140 [ 0.663413] [<0002f3284c507b9e>] __might_resched+0x66e/0x700 [ 0.663415] [<0002f3284cc4f6c0>] __alloc_frozen_pages_noprof+0x370/0x4b0 [ 0.663419] [<0002f3284ccc73c0>] alloc_pages_mpol+0x1a0/0x4a0 [ 0.663421] [<0002f3284ccc8518>] alloc_frozen_pages_noprof+0x88/0xc0 [ 0.663424] [<0002f3284ccc8572>] alloc_pages_noprof+0x22/0x120 [ 0.663427] [<0002f3284cc341ac>] get_free_pages_noprof+0x2c/0xc0 [ 0.663429] [<0002f3284cceba70>] kasan_populate_vmalloc_pte+0x50/0x120 [ 0.663433] [<0002f3284cbb4ef8>] apply_to_pte_range+0x118/0x4a0 [ 0.663435] [<0002f3284cbc7c14>] apply_to_pmd_range+0x194/0x3e0 [ 0.663437] [<0002f3284cbc99be>] __apply_to_page_range+0x2fe/0x7a0 [ 0.663440] [<0002f3284cbc9e88>] apply_to_page_range+0x28/0x40 [ 0.663442] [<0002f3284ccebf12>] kasan_populate_vmalloc+0x82/0xa0 [ 0.663445] [<0002f3284cc1578c>] alloc_vmap_area+0x34c/0xc10 [ 0.663448] [<0002f3284cc1c2a6>] __get_vm_area_node+0x186/0x2a0 [ 0.663451] [<0002f3284cc1e696>] __vmalloc_node_range_noprof+0x116/0x310 [ 0.663454] [<0002f3284cc1d950>] __vmalloc_node_noprof+0xd0/0x110 [ 0.663457] [<0002f3284c454b88>] alloc_thread_stack_node+0xf8/0x330 [ 0.663460] [<0002f3284c458d56>] dup_task_struct+0x66/0x4d0 [ 0.663463] [<0002f3284c45be90>] copy_process+0x280/0x4b90 [ 0.663465] [<0002f3284c460940>] kernel_clone+0xd0/0x4b0 [ 0.663467] [<0002f3284c46115e>] kernel_thread+0xbe/0xe0 [ 0.663469] [<0002f3284c4e440e>] kthreadd+0x50e/0x7f0 [ 0.663472] [<0002f3284c38c04a>] __ret_from_fork+0x8a/0xf0 [ 0.663475] [<0002f3284ed57ff2>] ret_from_fork+0xa/0x38 En su lugar de asignar páginas individuales por PTE, asigne en masa la memoria de sombra antes de aplicar la devolución de llamada kasan_populate_vmalloc_pte() en un rango de páginas.
Vulnerabilidad en kernel de Linux (CVE-2025-38032)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mr: consolidar las comprobaciones ipmr_can_free_table(). Guoyu Yin informó un splat en la ruta de limpieza de ipmr netns: ADVERTENCIA: CPU: 2 PID: 14564 en net/ipv4/ipmr.c:440 ipmr_free_table net/ipv4/ipmr.c:440 [en línea] ADVERTENCIA: CPU: 2 PID: 14564 en net/ipv4/ipmr.c:440 ipmr_rules_exit+0x135/0x1c0 net/ipv4/ipmr.c:361 Módulos vinculados: CPU: 2 UID: 0 PID: 14564 Comm: syz.4.838 No contaminado 6.14.0 #1 Nombre del hardware: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 RIP: 0010:ipmr_free_table net/ipv4/ipmr.c:440 [en línea] RIP: 0010:ipmr_rules_exit+0x135/0x1c0 net/ipv4/ipmr.c:361 Código: ff df 48 c1 ea 03 80 3c 02 00 75 7d 48 c7 83 60 05 00 00 00 00 00 00 5b 5d 41 5c 41 5d 41 5e e9 71 67 7f 00 e8 4c 2d 8a fd 90 <0f> 0b 90 eb 93 e8 41 2d 8a fd 0f b6 2d 80 54 ea 01 31 ff 89 ee e8 RSP: 0018:ffff888109547c58 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff888108c12dc0 RCX: ffffffff83e09868 RDX: ffff8881022b3300 RSI: ffffffff83e098d4 RDI: 000000000000000005 RBP: ffff888104288000 R08: 0000000000000000 R09: ffffed10211825c9 R10: 0000000000000001 R11: ffff88801816c4a0 R12: 0000000000000001 R13: ffff888108c13320 R14: ffff888108c12dc0 R15: fffffbfff0b74058 FS: 00007f84f39316c0(0000) GS:ffff88811b100000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f84f3930f98 CR3: 0000000113b56000 CR4: 0000000000350ef0 Rastreo de llamadas: ipmr_net_exit_batch+0x50/0x90 net/ipv4/ipmr.c:3160 ops_exit_list+0x10c/0x160 net/core/net_namespace.c:177 setup_net+0x47d/0x8e0 net/core/net_namespace.c:394 copy_net_ns+0x25d/0x410 net/core/net_namespace.c:516 create_new_namespaces+0x3f6/0xaf0 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc3/0x180 kernel/nsproxy.c:228 ksys_unshare+0x78d/0x9a0 kernel/fork.c:3342 __do_sys_unshare kernel/fork.c:3413 [inline] __se_sys_unshare kernel/fork.c:3411 [inline] __x64_sys_unshare+0x31/0x40 kernel/fork.c:3411 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xa6/0x1a0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f84f532cc29 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f84f3931038 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00007f84f5615fa0 RCX: 00007f84f532cc29 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000400 RBP: 00007f84f53fba18 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f84f5615fa0 R15: 00007fff51c5f328 El kernel en ejecución tiene CONFIG_IP_MROUTE_MULTIPLE_TABLES deshabilitado, y la comprobación de integridad para dicha compilación sigue siendo demasiado imprecisa. Solucione el problema consolidando la comprobación de integridad relevante en un único asistente, independientemente de la configuración del kernel. Además, compártala entre el código IPv4 e IPv6.
Vulnerabilidad en kernel de Linux (CVE-2025-38033)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/Kconfig: hacer que CFI_AUTO_DEFAULT dependa de !RUST o Rust >= 1.88 Llamar a core::fmt::write() desde el código rust mientras FineIBT está habilitado da como resultado un pánico del kernel: [ 4614.199779] ¡ERROR del kernel en arch/x86/kernel/cet.c:132! [ 4614.205343] Ups: código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI [ 4614.211781] CPU: 2 UID: 0 PID: 6057 Comm: dmabuf_dump Contaminado: GUO 6.12.17-android16-0-g6ab38c534a43 #1 9da040f27673ec3945e23b998a0f8bd64c846599 [ 4614.227832] Contaminado: [U]=USUARIO, [O]=OOT_MÓDULO [ 4614.241247] RIP: 0010:do_kernel_cp_fault+0xea/0xf0 ... [ 4614.398144] RIP: 0010:_RNvXs5_NtNtNtCs3o2tGsuHyou_4core3fmt3num3impyNtB9_7Display3fmt+0x0/0x20 [ 4614.407792] Código: 48 f7 gl 48 0f 48 f9 48 89 f2 89 c6 5d e9 18 fd ff ff 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 41 81 ea 14 61 af 2c 74 03 0f 0b 90 <66> 0f 1f 00 55 48 89 e5 48 89 f2 48 8b 3f be 01 00 00 00 5d e9 e7 [ 4614.428775] RSP: 0018:ffffb95acfa4ba68 EFLAGS: 00010246 [ 4614.434609] RAX: 000000000000000 RBX: 0000000000000010 RCX: 0000000000000000 [ 4614.442587] RDX: 0000000000000007 RSI: ffffb95acfa4ba70 RDI: ffffb95acfa4bc88 [ 4614.450557] RBP: ffffb95acfa4bae0 R08: ffff0a00ffffff05 R09: 0000000000000070 [ 4614.458527] R10: 0000000000000000 R11: ffffffffab67eaf0 R12: ffffb95acfa4bcc8 [ 4614.466493] R13: ffffffffac5d50f0 R14: 0000000000000000 R15: 0000000000000000 [ 4614.474473] ? __cfi__RNvXs5_NtNtNtCs3o2tGsuHyou_4core3fmt3num3impyNtB9_7Display3fmt+0x10/0x10 [ 4614.484118] ? _RNvNtCs3o2tGsuHyou_4core3fmt5write+0x1d2/0x250 Esto sucede porque core::fmt::write() llama a core::fmt::rt::Argument::fmt(), que actualmente tiene CFI deshabilitado: library/core/src/fmt/rt.rs: 171 // FIXME: Transmutando el formateador en new y ramificando indirectamente a/llamando a 172 // aquí es una violación explícita de CFI. 173 #[allow(inline_no_sanitize)] 174 #[no_sanitize(cfi, kcfi)] 175 #[inline] 176 pub(super) unsafe fn fmt(&self, f: &mut Formatter<'_>) -> Result { Esto causa una excepción de Protección de Control, porque FineIBT ha sellado el endbr64 de la función original. Esto hace que rust actualmente sea incompatible con FineIBT. Agregue una dependencia de Kconfig que evite que FineIBT se active de manera predeterminada si Rust está habilitado. [ Rust 1.88.0 (programado para el 26/06/2025) debería tener esto solucionado [1], y por lo tanto relajamos la condición con Rust >= 1.88. Cuando `objtool` aterrice verificando esto con, por ejemplo, [2], el plan es ejecutarlo idealmente en la CI de Rust ascendente para evitar regresiones tempranas [3], ya que no controlamos el código fuente de `core`. Alice probó el PR de Rust retroportado a un compilador más antiguo. A Peter le gustaría que Rust proporcionara un núcleo estable que se pueda integrar en el kernel: "Depender de tanto código fuera del árbol es 'desafortunado'". - Miguel ] [Menudas palabras. - Miguel ]
Vulnerabilidad en kernel de Linux (CVE-2025-38036)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/vf: Realizar una inicialización temprana de MMIO de GT para leer GMDID. Los VF deben comunicarse con el GuC para obtener el valor GMDID y las funciones GuC existentes utilizadas para eso suponen que el GT ya tiene configurados sus miembros MMIO. Sin embargo, debido a una refactorización reciente, gt->mmio se inicializa más tarde y cualquier intento del VF de usar xe_mmio_read|write() desde las funciones GuC provocará un bloqueo de NPD debido a una dirección de registro MMIO no establecida: [] xe 0000:00:02.1: [drm] Ejecutando en modo SR-IOV VF [] xe 0000:00:02.1: [drm] GT0: enviando H2G MMIO 0x5507 [] ERROR: no se puede manejar el error de página para la dirección: 0000000000190240 Dado que ya estamos ajustando el id y el tipo del GT principal para imitar que es un Media GT antes de inicializar la comunicación GuC, también podemos llamar a xe_gt_mmio_init() para realizar una configuración temprana de gt->mmio que hará que esas funciones GuC funcionen nuevamente.
Vulnerabilidad en kernel de Linux (CVE-2025-38038)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: amd-pstate: Eliminar driver_lock innecesario en set_boost. set_boost es una llamada a función por política, por lo que no es necesario un bloqueo a nivel de controlador. Además, este mutex_acquire puede colisionar con el mutex_acquire de la ruta de cambio de modo en status_store(), lo que puede provocar un interbloqueo. Por lo tanto, elimínelo.
Vulnerabilidad en kernel de Linux (CVE-2025-38039)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Evitar WARN_ON al configurar MQPRIO con la descarga de HTB habilitada. Al intentar habilitar MQPRIO con la descarga de HTB ya configurada, el controlador devuelve `-EINVAL` y activa `WARN_ON`, lo que genera un seguimiento de llamadas innecesario. Actualice el código para gestionar este caso de forma más eficiente devolviendo `-EOPNOTSUPP` en su lugar y proporcionando un mensaje útil al usuario.
Vulnerabilidad en kernel de Linux (CVE-2025-38041)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: sunxi-ng: h616: Reasignación del reloj de la GPU durante cambios de frecuencia. El manual de H616 no indica que el PLL de la GPU admita la configuración dinámica de frecuencia, por lo que debemos tener especial cuidado al cambiarla. Actualmente, cualquier intento de realizar la configuración dinámica de frecuencia (DVFS) del dispositivo en la GPU provoca varios errores de panfrost y bloqueos de la GPU. El manual describe el algoritmo para cambiar la frecuencia del PLL, que ya es compatible con el código del notificador del PLL de la CPU, por lo que lo reutilizamos para reasignar el reloj de la GPU al reloj de la GPU1 durante los cambios de frecuencia.
Vulnerabilidad en kernel de Linux (CVE-2025-38042)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: ti: k3-udma-glue: Eliminar argumento skip_fdq de k3_udma_glue_reset_rx_chn El usuario de k3_udma_glue_reset_rx_chn(), p. ej., ti_am65_cpsw_nuss, puede ejecutarse en múltiples plataformas que tengan diferentes arquitecturas DMA. En algunas plataformas puede haber un FDQ para todos los flujos en el canal RX, mientras que en otras hay un FDQ independiente para cada flujo en el canal RX. Hasta ahora, hemos dependido del argumento skip_fdq de k3_udma_glue_reset_rx_chn(). En lugar de depender de que el usuario proporcione esta información, infiérala en función de la arquitectura DMA durante k3_udma_glue_request_rx_chn() y guárdela en un indicador interno 'single_fdq'. Utilice esa bandera en k3_udma_glue_reset_rx_chn() para decidir si el FDQ necesita ser borrado para cada flujo o sólo para el flujo 0. Corrige el siguiente problema en el controlador ti_am65_cpsw_nuss en AM62-SK. > enlace ip establecer eth1 inactivo > enlace ip establecer eth0 inactivo > ethtool -L eth0 rx 8 > enlace ip establecer eth0 activo > modprobe -r ti_am65_cpsw_nuss [ 103.045726] ------------[ cortar aquí ]------------ [ 103.050505] k3_knav_desc_pool tamaño 512000 != avail 64000 [ 103.050703] ADVERTENCIA: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcas p drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 r fkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool] [ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011 [ 103.119968] Hardware name: Texas Instruments AM625 SK (DT) [ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.154709] sp : ffff8000826ebbc0 [ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000 [ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0 [ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88 [ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000 [ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde [ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000 [ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20 [ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100 [ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000 [ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000 [ 103.229274] Call trace: [ 103.231714] k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P) [ 103.238408] am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss] [ 103.244942] devm_action_release+0x14/0x20 [ 103.249040] release_nodes+0x3c/0x68 [ 103.252610] devres_release_all+0x8c/0xdc [ 103.256614] device_unbind_cleanup+0x18/0x60 [ 103.260876] device_release_driver_internal+0xf8/0x178 [ 103.266004] driver_detach+0x50/0x9c [ 103.269571] bus_remove_driver+0x6c/0xbc [ 103.273485] driver_unregister+0x30/0x60 [ 103.277401] platform_driver_unregister+0x14/0x20 [ 103.282096] am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss] [ 103.288620] __arm64_sys_delete_module+0x17c/0x25c [ 103.293404] invoke_syscall+0x44/0x100 [ 103.297149] el0_svc_common.constprop.0+0xc0/0xe0 [ 103.301845] do_el0_svc+0x1c/0x28 [ 103.305155] el0_svc+0x28/0x98 ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2025-38045)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: corregir el orden de las acciones de depuración. El orden de las acciones de depuración se implementó incorrectamente. Ahora implementamos la división del volcado y el reinicio del firmware se realiza solo en medio del volcado (en lugar de que el firmware se autodestruya en caso de error). Como resultado, algunas acciones al aplicar la configuración ahora bloquearán el dispositivo, por lo que debemos corregir el orden.
Vulnerabilidad en kernel de Linux (CVE-2025-38047)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fred: Se solucionó el bloqueo del sistema durante la reanudación de S4 con FRED habilitado. Al reactivarse desde S4, el kernel de restauración se inicia e inicializa los MSR de FRED según sea necesario. A continuación, carga una imagen de hibernación, incluyendo el kernel de imagen, e intenta cargar las páginas de la imagen directamente en los marcos de página originales utilizados antes de la hibernación, a menos que dichos marcos estén en uso. Una vez que todas las páginas se mueven a sus ubicaciones originales, se accede a una página "trampolín" en el kernel de imagen. En este punto, el kernel de imagen toma el control, pero los MSR de FRED aún contienen valores establecidos por el kernel de restauración, que pueden diferir de los establecidos por el kernel de imagen antes de la hibernación. Por lo tanto, el kernel de imagen debe garantizar que los MSR de FRED tengan los mismos valores que antes de la hibernación. Dado que estos valores dependen únicamente de la ubicación del texto y los datos del kernel, pueden recalcularse desde cero.
Vulnerabilidad en kernel de Linux (CVE-2025-38050)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb: corrección de la desreferencia del puntero NULL del kernel al reemplazar folios hugetlb libres Se observó un fallo del kernel al reemplazar folios hugetlb libres: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000028 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 28 UID: 0 PID: 29639 Comm: test_cma.sh Tainted 6.15.0-rc6-zp #41 PREEMPT(voluntario) RIP: 0010:alloc_and_dissolve_hugetlb_folio+0x1d/0x1f0 RSP: 0018:ffffc9000b30fa90 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000342cca RCX: ffffea0043000000 RDX: ffffc9000b30fb08 RSI: ffffea0043000000 RDI: 0000000000000000 RBP: ffffc9000b30fb20 R08: 0000000000001000 R09: 0000000000000000 R10: ffff88886f92eb00 R11: 000000000000000000 R12: ffffea0043000000 R13: 0000000000000000 R14: 00000000010c0200 R15: 0000000000000004 FS: 00007fcda5f14740(0000) GS:ffff8888ec1d8000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000028 CR3: 0000000391402000 CR4: 0000000000350ef0 Rastreo de llamadas: replace_free_hugepage_folios+0xb6/0x100 alloc_contig_range_noprof+0x18a/0x590 ? srso_return_thunk+0x5/0x5f ? down_read+0x12/0xa0 ? srso_return_thunk+0x5/0x5f cma_range_alloc.constprop.0+0x131/0x290 __cma_alloc+0xcf/0x2c0 cma_alloc_write+0x43/0xb0 simple_attr_write_xsigned.constprop.0.isra.0+0xb2/0x110 debugfs_attr_write+0x46/0x70 full_proxy_write+0x62/0xa0 vfs_write+0xf8/0x420 ? srso_return_thunk+0x5/0x5f ? filp_flush+0x86/0xa0 ? srso_return_thunk+0x5/0x5f ? filp_close+0x1f/0x30 ? srso_return_thunk+0x5/0x5f ? do_dup2+0xaf/0x160 ? srso_return_thunk+0x5/0x5f ksys_write+0x65/0xe0 do_syscall_64+0x64/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e There is a potential race between __update_and_free_hugetlb_folio() and replace_free_hugepage_folios(): CPU1 CPU2 __update_and_free_hugetlb_folio replace_free_hugepage_folios folio_test_hugetlb(folio) -- It's still hugetlb folio. __folio_clear_hugetlb(folio) hugetlb_free_folio(folio) h = folio_hstate(folio) -- Aquí, h es un puntero NULL Cuando ocurre la condición de ejecución anterior, folio_hstate(folio) devuelve NULL y el acceso posterior a este puntero NULL provocará que el sistema se bloquee. Para resolver este problema, ejecute folio_hstate(folio) bajo la protección del bloqueo hugetlb_lock, asegurándose de que folio_hstate(folio) no devuelva NULL.
Vulnerabilidad en kernel de Linux (CVE-2025-38053)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: idpf: corrección de null-ptr-deref en idpf_features_check idpf_features_check se utiliza para validar el paquete TX. La longitud del encabezado skb se compara con el valor admitido por el hardware recibido del plano de control del dispositivo. El valor se almacena en la estructura del adaptador y para acceder a él, se utiliza el puntero vport. Durante el reinicio, se liberan todos los vports y el puntero vport al que apunta la estructura privada netdev es NULL. Para evitar null-ptr-deref, almacene el valor de longitud máxima del encabezado en la estructura privada netdev. Esto también ayuda a almacenar en caché el valor y evitar el acceso al puntero del adaptador en la ruta activa. ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000068 ... RIP: 0010:idpf_features_check+0x6d/0xe0 [idpf] Rastreo de llamadas: ? __die+0x23/0x70 ? page_fault_oops+0x154/0x520 ? exc_page_fault+0x76/0x190 ? asm_exc_page_fault+0x26/0x30 ? idpf_features_check+0x6d/0xe0 [idpf] netif_skb_features+0x88/0x310 validate_xmit_skb+0x2a/0x2b0 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x19d/0x3a0 __dev_queue_xmit+0xb74/0xe70 ...
Vulnerabilidad en kernel de Linux (CVE-2025-38054)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ptp: ocp: Limitar el conteo de señales/frecuencias en las funciones de salida de resumen. La salida de resumen de debugfs podría acceder a elementos no inicializados en las matrices freq_in[] y signal_out[], lo que causa desreferencias de punteros nulos y desencadena un error de kernel (page_fault_oops). Este parche agrega campos u8 (nr_freq_in, nr_signal_out) para rastrear el número de elementos inicializados, con un máximo de 4 por matriz. Las funciones de salida de resumen se actualizan para respetar estos límites, lo que evita el acceso fuera de los límites y garantiza el manejo seguro de la matriz. Amplíe las variables de etiqueta porque el cambio confunde a GCC sobre la longitud máxima de las cadenas.
Vulnerabilidad en kernel de Linux (CVE-2025-38055)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/x86/intel: Corrección de una falla de segmentación con PEBS-via-PT con sample_freq. Actualmente, usar PEBS-via-PT con una frecuencia de muestreo en lugar de un periodo de muestreo provoca una falla de segmentación. Por ejemplo: Error: Desreferencia de puntero nulo del kernel, dirección: 0000000000000195 ? __die_body.cold+0x19/0x27 ? page_fault_oops+0xca/0x290 ? exc_page_fault+0x7e/0x1b0 ? asm_exc_page_fault+0x26/0x30 ? intel_pmu_pebs_event_update_no_drain+0x40/0x60 ? intel_pmu_pebs_event_update_no_drain+0x32/0x60 intel_pmu_drain_pebs_icl+0x333/0x350 handle_pmi_common+0x272/0x3c0 intel_pmu_handle_irq+0x10a/0x2e0 perf_event_nmi_handler+0x2a/0x50 Esto sucede porque intel_pmu_pebs_event_update_no_drain() asume que todos los bits pebs_enabled representan índices de contador, lo que no siempre es el caso. En este caso particular, los bits 60 y 61 se establecen para fines de PEBS a través de PT. El comportamiento de PEBS a través de PT con frecuencia de muestreo es cuestionable porque, aunque se genera un PMI (PEBS_PMI_AFTER_EACH_RECORD), el período no se ajusta de todos modos. Dejando eso de lado, corrija intel_pmu_pebs_event_update_no_drain() pasando la máscara de bits del contador en lugar de 'size'. Tenga en cuenta que, antes de el commit de las correcciones, 'size' estaba limitado al índice máximo del contador, por lo que el problema no se solucionó.
Vulnerabilidad en kernel de Linux (CVE-2025-38056)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: Intel: hda: Se corrige el UAF al recargar el módulo. hda_generic_machine_select() añade -idisp al nombre de archivo tplg asignando una nueva cadena con devm_kasprintf() y luego la almacena directamente en la variable global snd_soc_acpi_intel_hda_machines. Al descargar el módulo, se libera esta memoria, lo que genera una variable global que apunta a la memoria liberada. Recargar el módulo luego activa un use-after-free: ERROR: KFENCE: use-after-free read in string+0x48/0xe0 Use-after-free read at 0x00000000967e0109 (in kfence-#99): string+0x48/0xe0 vsnprintf+0x329/0x6e0 devm_kvasprintf+0x54/0xb0 devm_kasprintf+0x58/0x80 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] sof_probe_work+0x7f/0x600 [snd_sof] process_one_work+0x17b/0x330 worker_thread+0x2ce/0x3f0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 kfence-#99: 0x00000000198a940f-0x00000000ace47d9d, size=64, cache=kmalloc-64 allocated by task 333 on cpu 8 at 17.798069s (130.453553s ago): devm_kmalloc+0x52/0x120 devm_kvasprintf+0x66/0xb0 devm_kasprintf+0x58/0x80 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] sof_probe_work+0x7f/0x600 [snd_sof] process_one_work+0x17b/0x330 worker_thread+0x2ce/0x3f0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 freed by task 1543 on cpu 4 at 141.586686s (6.665010s ago): release_nodes+0x43/0xb0 devres_release_all+0x90/0xf0 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c1/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x42/0xb0 __do_sys_delete_module+0x1d1/0x310 do_syscall_64+0x82/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e Corríjalo copiando la matriz de coincidencia con devm_kmemdup_array() antes de modificarla.
Vulnerabilidad en kernel de Linux (CVE-2025-38057)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: espintcp: corrige fugas de skb. En algunas rutas de error falta un kfree_skb.
Vulnerabilidad en kernel de Linux (CVE-2025-38059)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: evitar la desreferencia de puntero NULL si no hay un árbol csum válido [ERROR] Al intentar una limpieza de solo lectura en un btrfs con la opción de montaje rescue=idatacsums, se bloqueará con el siguiente seguimiento de llamada: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000208 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: GO 6.15.0-rc3-custom+ #236 PREEMPT(full) Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS desconocido 02/02/2022 RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs] Seguimiento de llamadas: scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs] scrub_simple_mirror+0x175/0x290 [btrfs] scrub_stripe+0x5f7/0x6f0 [btrfs] scrub_chunk+0x9a/0x150 [btrfs] scrub_enumerate_chunks+0x333/0x660 [btrfs] btrfs_scrub_dev+0x23e/0x600 [btrfs] btrfs_ioctl+0x1dcf/0x2f80 [btrfs] __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e [CAUSE] La opción de montaje "rescue=idatacsums" omitirá por completo la carga del árbol de sumas de comprobación (CSUM), por lo que los datos leídos no encontrarán ninguna CSU, por lo que se ignorará la verificación de la suma de comprobación de datos. Normalmente, los sitios de llamada que utilizan el árbol de CSU comprueban el bit NO_DATA_CSUMS del indicador de estado del sistema de archivos, pero lamentablemente, scrub no lo comprueba en absoluto. Esto provoca que scrub llame a btrfs_search_slot() en un puntero nulo, lo que provocó el bloqueo mencionado anteriormente. [CORRECCIÓN] Compruebe la extensión y la raíz del árbol de CSU antes de realizar cualquier búsqueda en el árbol.
Vulnerabilidad en kernel de Linux (CVE-2025-38060)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: copy_verifier_state() debería copiar el campo 'loop_entry'. El estado bpf_verifier_state.loop_entry debería ser copiado por copy_verifier_state(). De lo contrario, los valores .loop_entry de estados no relacionados envenenarían env->cur_state. Además, env->stack no debería contener ningún estado con .loop_entry != NULL. Los estados en env->stack aún están por verificar, mientras que .loop_entry está configurado para estados que alcanzaron un estado equivalente. Esto significa que env->cur_state->loop_entry siempre debería ser NULL después de pop_stack(). Vea la autoprueba en la siguiente confirmación para un ejemplo del programa que no es seguro pero es aceptado por el verificador sin esta corrección. Este cambio tiene algún impacto en el rendimiento de la verificación para las autopruebas: Archivo Programa Insns (A) Insns (B) Insns (DIFF) Estados (A) Estados (B) Estados (DIFF) ---------------------------------- ---------------------------- --------- --------- -------------- ---------- ---------- ------------- arena_htab.bpf.o arena_htab_llvm 717 426 -291 (-40.59%) 57 37 -20 (-35.09%) arena_htab_asm.bpf.o arena_htab_asm 597 445 -152 (-25.46%) 47 37 -10 (-21.28%) arena_list.bpf.o arena_list_del 309 279 -30 (-9.71%) 23 14 -9 (-39.13%) iters.bpf.o iter_subprog_check_stacksafe 155 141 -14 (-9.03%) 15 14 -1 (-6.67%) iters.bpf.o iter_subprog_iters 1094 1003 -91 (-8.32%) 88 83 -5 (-5.68%) iters.bpf.o loop_state_deps2 479 725 +246 (+51.36%) 46 63 +17 (+36.96%) kmem_cache_iter.bpf.o open_coded_iter 63 59 -4 (-6.35%) 7 6 -1 (-14.29%) verifier_bits_iter.bpf.o max_words 92 84 -8 (-8.70%) 8 7 -1 (-12.50%) verifier_iterating_callbacks.bpf.o cond_break2 113 107 -6 (-5.31%) 12 12 +0 (+0.00%)Y un impacto negativo significativo para sched_ext: Archivo Programa Insns (A) Insns (B) Insns (DIFF) Estados (A) Estados (B) Estados (DIFF) ----------------- ---------------------- --------- --------- -------------------- ---------- ---------- ------------------ bpf.bpf.o lavd_init 7039 14723 +7684 (+109.16%) 490 1139 +649 (+132.45%) bpf.bpf.o layered_dispatch 11485 10548 -937 (-8.16%) 848 762 -86 (-10.14%) bpf.bpf.o layered_dump 7422 1000001 +992579 (+13373.47%) 681 31178 +30497 (+4478.27%) bpf.bpf.o layered_enqueue 16854 71127 +54273 (+322.02%) 1611 6450 +4839 (+300.37%) bpf.bpf.o p2dq_dispatch 665 791 +126 (+18.95%) 68 78 +10 (+14.71%) bpf.bpf.o p2dq_init 2343 2980 +637 (+27.19%) 201 237 +36 (+17.91%) bpf.bpf.o refresh_layer_cpumasks 16487 674760 +658273 (+3992.68%) 1770 65370 +63600 (+3593.22%) bpf.bpf.o rusty_select_cpu 1937 40872 +38935 (+2010.07%) 177 3210 +3033 (+1713.56%) scx_central.bpf.o central_dispatch 636 2687 +2051 (+322.48%) 63 227 +164 (+260.32%) scx_nest.bpf.o nest_init 636 815 +179 (+28.14%) 60 73 +13 (+21.67%) scx_qmap.bpf.o qmap_dispatch ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2025-38064)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio: interrumpir y reiniciar dispositivos virtio en device_shutdown() Hongyu informó de un bloqueo en kexec en una máquina virtual. QEMU informó de accesos a memoria no válidos durante el bloqueo. Lectura no válida en la dirección 0x102877002, tamaño 2, región '(null)', motivo: rechazada Escritura no válida en la dirección 0x102877A44, tamaño 2, región '(null)', motivo: rechazada ... Se rastreó hasta virtio-console. Kexec funciona bien si virtio-console no está en uso. El problema es que virtio-console continúa escribiendo en el MMIO incluso después de reiniciar el dispositivo virtio-pci subyacente. Además, Eric notó que las IOMMU se reinician antes que los dispositivos; si los dispositivos no se reinician al apagar, continúan presionando la memoria invitada y obtienen errores de la IOMMU. Algunos dispositivos se bloquean entonces. El problema se puede resolver rompiendo todos los dispositivos virtio al apagar el bus virtio y luego reiniciándolos.
Vulnerabilidad en kernel de Linu (CVE-2025-38069)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: endpoint: pci-epf-test: Se corrige la doble liberación que provoca un error en el kernel. Se corrige un error en el kernel detectado al probar el controlador de endpoint stm32_pcie con el manejo de la deaserción PERST#: Durante la inicialización de EP, pci_epf_test_alloc_space() asigna todos los BAR, que se liberan aún más si epc_set_bar() falla (por ejemplo, debido a que no hay una ventana de entrada libre). Sin embargo, cuando pci_epc_set_bar() falla, la ruta de error: pci_epc_set_bar() -> pci_epf_free_space() no borra la asignación previa a epf_test->reg[bar]. Luego, si el host se reinicia, la desasignación PERST# reinicia la secuencia de asignación de BAR con el mismo fallo de asignación (sin ventana de entrada libre), lo que crea una situación de doble liberación, ya que epf_test->reg[bar] se desasignó y sigue siendo distinto de NULL. Por lo tanto, asegúrese de que las invocaciones de pci_epf_alloc_space() y pci_epf_free_space() sean simétricas y, por lo tanto, establezca epf_test->reg[bar] en NULL cuando se libere memoria. [kwilczynski: registro de confirmaciones]
Vulnerabilidad en kernel de Linux (CVE-2025-38070)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: sma1307: Se ha añadido una comprobación de valores nulos en sma1307_setting_loaded(). Todas las variables asignadas por kzalloc y devm_kzalloc podrían ser nulas. Se han añadido varias comprobaciones de punteros y su limpieza. Nuestra herramienta de análisis estático ha detectado este problema.
Vulnerabilidad en kernel de Linux (CVE-2025-38073)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corregir ejecución entre set_blocksize y las rutas de lectura Con el nuevo soporte para tamaños de sector grandes, ahora es posible que set_blocksize cambie i_blksize y el orden de los folios de forma que entre en conflicto con un lector concurrente y provoque un fallo del kernel. Específicamente, supongamos que udev-worker llama a libblkid para detectar las etiquetas en un dispositivo de bloque. La llamada de lectura puede crear un folio de orden 0 para leer los primeros 4096 bytes del disco. Pero entonces udev es interrumpido. A continuación, alguien intenta montar un sistema de archivos de tamaño de sector de 8k desde el mismo dispositivo de bloque. El sistema de archivos llama a set_blksize, que establece i_blksize en 8192 y el orden mínimo de folio en 1. Ahora udev se reanuda, aún manteniendo el folio de orden 0 que asignó. Entonces intenta programar una biografía de lectura y do_mpage_readahead intenta crear bufferheads para el folio. Desafortunadamente, bloques_por_folio == 0 porque el tamaño de página es 4096, pero el tamaño de bloque es 8192, por lo que no se conectan bufferheads y el bh walk nunca establece bdev. Luego, enviamos la biografía con un dispositivo de bloque nulo y se produce un fallo. Por lo tanto, truncamos la caché de páginas después del vaciado, pero antes de actualizar i_blksize. Sin embargo, esto no es suficiente; también necesitamos bloquear la E/S de archivos y los fallos de página durante la actualización. Use tanto i_rwsem como invalidate_lock en modo exclusivo para invalidaciones y en modo compartido para operaciones de lectura/escritura. No sé si esta sea la solución correcta, pero xfs/259 la encontró.
Vulnerabilidad en kernel de Linux (CVE-2025-38076)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: alloc_tag: asignar contadores por CPU para etiquetas de módulo dinámicamente Cuando se descarga un módulo, este verifica si alguna de sus etiquetas aún está en uso y, de ser así, mantenemos activa la memoria que contiene las etiquetas de asignación del módulo hasta que todas las etiquetas estén sin usar. Sin embargo, los contadores por CPU referenciados por las etiquetas son liberados por free_module(). Esto conducirá a UAF si se accede a la memoria asignada por un módulo después de que el módulo se haya descargado. Para corregir esto, asignamos contadores por CPU para etiquetas de asignación de módulo dinámicamente y los mantenemos activos para las etiquetas que aún están en uso después de la descarga del módulo. Esto también elimina el requisito de un PERCPU_MODULE_RESERVE más grande cuando el perfil de asignación de memoria está habilitado porque la memoria por CPU para los contadores ya no necesita reservarse.
Vulnerabilidad en kernel de Linux (CVE-2025-38080)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Aumentar el tamaño de la matriz block_sequence [Por qué] Es posible generar más de 50 pasos en hwss_build_fast_sequence, por ejemplo, con un ASIC de 6 tuberías donde todas las tuberías están en una cadena MPC. Esto desborda el búfer block_sequence y corrompe block_sequence_steps, lo que provoca un fallo. [Cómo] Ampliar block_sequence a 100 elementos. Un límite superior simple para el número posible de pasos para un ASIC de 6 tuberías, ignorando la posibilidad de que los pasos sean mutuamente excluyentes, es 91 con el código actual; por lo tanto, 100 es suficiente.
Vulnerabilidad en kernel de Linux (CVE-2025-38081)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi-rockchip: Se corrige el acceso fuera de los límites al registro. No se debe escribir información de selección de chip nativa para las selecciones de chip GPIO. Las GPIO pueden tener una numeración mucho mayor que la de las CS nativas. Además, no tiene sentido.
Vulnerabilidad en kernel de Linux (CVE-2025-38082)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: virtuser: corrección de una posible escritura fuera de límite. Si el llamador escribió más caracteres, el recuento se trunca al espacio máximo disponible en "simple_write_to_buffer". Compruebe que el tamaño de entrada no supere el tamaño del búfer. Escriba una terminación de cero después.
Vulnerabilidad en kernel de Linux (CVE-2022-49934)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: Se ha corregido el UAF en ieee80211_scan_rx(). ieee80211_scan_rx() intenta acceder a scan_req->flags tras una comprobación nula, pero se observa un UAF al finalizar el escaneo y se ejecuta __ieee80211_scan_completed(), que a su vez llama a cfg80211_scan_done(), lo que libera scan_req. Dado que scan_req está desreferenciado mediante rcu_dereference(), se debe evitar la aceleración en __ieee80211_scan_completed() asegurándose de que, desde el punto de vista de mac80211, ya no se acceda a él desde una sección crítica de lectura de RCU antes de llamar a cfg80211_scan_done().
Vulnerabilidad en kernel de Linux (CVE-2022-49935)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-buf/dma-resv: comprobar si la nueva valla es realmente posterior. Anteriormente, al añadir una valla a un objeto dma_resv, siempre suponíamos que era más reciente que todas las vallas existentes. Gracias al trabajo de Jason para añadir una UAPI a la exportación/importación explícita, esto ya no es necesario. Por lo tanto, sin esta comprobación, permitiríamos que el espacio de usuario forzara al kernel a un error de Use-After-Free. Dado que el cambio es muy pequeño y defensivo, probablemente sea buena idea retroportarlo también a los kernels estables, por si acaso otros utilizan el objeto dma_resv de la misma manera.
Vulnerabilidad en kernel de Linux (CVE-2022-49936)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: núcleo: evitar llamadas de reinicio de dispositivo anidadas. El fuzzing automático del kernel reveló una violación de bloqueo recursivo en usb-storage: ============================================== ADVERTENCIA: posible bloqueo recursivo detectado 5.18.0 #3 No contaminado -------------------------------------------- kworker/1:3/1205 está intentando adquirir el bloqueo: ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, en: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 pero la tarea ya está manteniendo el bloqueo: ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, en: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 ... seguimiento de pila: CPU: 1 PID: 1205 Comm: kworker/1:3 No contaminado 5.18.0 #3 Nombre de hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Cola de trabajo: usb_hub_wq hub_event Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_deadlock_bug kernel/locking/lockdep.c:2988 [inline] check_deadlock kernel/locking/lockdep.c:3031 [inline] validate_chain kernel/locking/lockdep.c:3816 [inline] __lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053 lock_acquire kernel/locking/lockdep.c:5665 [inline] lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630 __mutex_lock_common kernel/locking/mutex.c:603 [inline] __mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747 usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109 r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622 usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458 device_remove drivers/base/dd.c:545 [inline] device_remove+0x11f/0x170 drivers/base/dd.c:537 __device_release_driver drivers/base/dd.c:1222 [inline] device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248 usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627 usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118 usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114 Resultó que esto no era un error en usb-storage sino más bien un intento de reinicio de dispositivo anidado. Es decir, como el controlador rtl8712 se estaba desvinculando de un dispositivo compuesto en preparación para un reinicio USB no relacionado (ese controlador no tiene devoluciones de llamada pre_reset o post_reset), su rutina ->remove llamó a usb_reset_device() - anidando así una llamada de reinicio dentro de otra. Realizar un reinicio como parte del procesamiento de desconexión es una práctica cuestionable en el mejor de los casos. Sin embargo, el informe de errores señala que el núcleo USB no tiene ninguna protección contra reinicios anidados. Agregar un indicador reset_in_progress y probarlo evitará tales errores en el futuro.
Vulnerabilidad en kernel de Linux (CVE-2022-49937)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mceusb: Utilizar nuevas rutinas usb_control_msg_*() El fuzzing automático del kernel provocó una ADVERTENCIA sobre una dirección de tubería no válida en el controlador mceusb: ------------[ cortar aquí ]------------ usb 6-1: directorio de control FALSO, la tubería 80000380 no coincide con bRequestType 40 ADVERTENCIA: CPU: 0 PID: 2465 en drivers/usb/core/urb.c:410 usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410 Módulos vinculados: CPU: 0 PID: 2465 Comm: kworker/0:2 No contaminado 5.19.0-rc4-00208-g69cb6c6556ad #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Cola de trabajo: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410 Código: 7c 24 40 e8 ac 23 91 fd 48 8b 7c 24 40 e8 b2 70 1b ff 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 30 a9 86 e8 48 07 11 02 <0f> 0b e9 1c f0 ff ff e8 7e 23 91 fd 0f b6 1d 63 22 83 05 31 y siguientes 41 RSP: 0018:ffffc900032becf0 EFLAGS: 00010282 RAX: 000000000000000 RBX: ffff8881100f3058 RCX: 0000000000000000 RDX: ffffc90004961000 RSI: ffff888114c6d580 RDI: fffff52000657d90 RBP: ffff888105ad90f0 R08: ffffffff812c3638 R09: 000000000000000 R10: 0000000000000005 R11: ffffed1023504ef1 R12: ffff888105ad9000 R13: 0000000000000040 R14: 0000000080000380 R15: ffff88810ba96500 FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffe810bda58 CR3: 000000010b720000 CR4: 0000000000350ef0 Seguimiento de llamadas: usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153 mceusb_gen1_init drivers/media/rc/mceusb.c:1431 [inline] mceusb_dev_probe+0x258e/0x33f0 drivers/media/rc/mceusb.c:1807 El motivo de la advertencia es bastante claro; el controlador envía una solicitud de lectura inusual en el endpoint 0 pero no establece el bit USB_DIR_IN en el campo bRequestType. Más importante aún, se puede evitar toda la situación y simplificar el controlador al convertirlo a las relativamente nuevas rutinas usb_control_msg_recv() y usb_control_msg_send(). Esto es lo que hace esta corrección.
Vulnerabilidad en kernel de Linux (CVE-2022-49938)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: corrige una pequeña pérdida de mempool en SMB2_negotiate() En algunos casos de falla (desajustes de dialecto) en SMB2_negotiate(), después de enviar la solicitud, las verificaciones devolverían -EIO cuando deberían establecer rc = -EIO y saltar a neg_exit para liberar el búfer de respuesta de mempool.
Vulnerabilidad en kernel de Linux (CVE-2022-49939)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: arreglo UAF de ref->proc causado por condición de ejecución Una transacción de tipo BINDER_TYPE_WEAK_HANDLE puede fallar al incrementar la referencia para un nodo. En este caso, el proc objetivo normalmente libera la referencia fallida al cerrar como se espera. Sin embargo, si el objetivo está muriendo en paralelo la llamada competirá con binder_deferred_release(), por lo que el objetivo podría haber liberado todas sus referencias por ahora dejando la limpieza de la nueva referencia fallida sin manejar. La transacción entonces termina y el proc objetivo se libera haciendo que ref->proc ahora sea un puntero colgante. Más tarde, ref->node se cierra e intentamos tomar spin_lock(&ref->proc->inner_lock), lo que lleva al error de Use-After-Free reportado a continuación. Vamos a arreglar esto limpiando la referencia fallida en el acto en lugar de depender de que el objetivo lo haga. ====================================================================== ERROR: KASAN: Use-After-Free en _raw_spin_lock+0xa8/0x150 Escritura de tamaño 4 en la dirección ffff5ca207094238 por la tarea kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 No contaminado 5.19.0-rc8 #10 Nombre del hardware: linux,dummy-virt (DT) Cola de trabajo: eventos binder_deferred_func Rastreo de llamadas: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20
Vulnerabilidad en kernel de Linux (CVE-2022-49940)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: n_gsm: añadir comprobación de validez para gsm->receive en gsm_receive_buf(). Se puede producir una desreferencia de puntero nulo al intentar acceder a la función "gsm->receive()" en gsmld_receive_buf(). Actualmente, el código asume que gsm->recieve solo se llama después de la activación del MUX. Dado que se puede acceder a la función gsmld_receive_buf() sin necesidad de inicializar el MUX, esta función no se activará y se producirá una desreferencia de puntero nulo. Para solucionar esto, se debe evitar la llamada a "gsm->receive()" si la función no se inicializa mediante una comprobación de validez. Rastreo de llamadas: gsmld_receive_buf+0x1c2/0x2f0 drivers/tty/n_gsm.c:2861 tiocsti drivers/tty/tty_io.c:2293 [en línea] tty_ioctl+0xa75/0x15d0 drivers/tty/tty_io.c:2692 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:870 [en línea] __se_sys_ioctl fs/ioctl.c:856 [en línea] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Vulnerabilidad en kernel de Linux (CVE-2022-49942)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: No finalizar la CSA en modo IBSS si el estado es desconectado. Cuando no estamos conectados a un canal, enviar el anuncio de cambio de canal no tiene sentido. En ese caso, la lista BSS está vacía. Esto provoca que se omita el bucle for en cfg80211_get_bss(), por lo que la función devuelve NULL (consulte la línea 1424 de net/wireless/scan.c), lo que provoca la activación de WARN_ON() en ieee80211_ibss_csa_beacon() (consulte la línea 500 de net/mac80211/ibss.c), lo que se informó en el panel de control de syzkaller. Por lo tanto, se debe comprobar si existe una conexión antes de generar la baliza CSA en ieee80211_ibss_finish_csa().
Vulnerabilidad en kernel de Linux (CVE-2022-49943)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: gadget: Se corrige una oscura violación de lockdep para udc_mutex. Una confirmación reciente que expandió el alcance del mutex udc_lock en el núcleo del gadget logró causar una oscura y ligeramente extraña violación de lockdep. En forma abreviada: ======================================================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 5.19.0-rc7+ #12510 No contaminado ------------------------------------------------------ udevadm/312 está intentando adquirir el bloqueo: ffff80000aae1058 (udc_lock){+.+.}-{3:3}, en: usb_udc_uevent+0x54/0xe0 pero la tarea ya tiene el bloqueo: ffff000002277548 (kn->active#4){++++}-{0:0}, en: kernfs_seq_start+0x34/0xe0 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #3 (kn->active#4){++++}-{0:0}: lock_acquire+0x68/0x84 __kernfs_remove+0x268/0x380 kernfs_remove_by_name_ns+0x58/0xac sysfs_remove_file_ns+0x18/0x24 device_del+0x15c/0x440 -> #2 (device_links_lock){+.+.}-{3:3}: lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 device_link_remove+0x3c/0xa0 _regulator_put.part.0+0x168/0x190 regulator_put+0x3c/0x54 devm_regulator_release+0x14/0x20 -> #1 (mutex_lista_regulador){+.+.}-{3:3}: adquisición_bloqueo+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 regulator_lock_dependent+0x54/0x284 regulator_enable+0x34/0x80 phy_power_on+0x24/0x130 __dwc2_lowlevel_hw_enable+0x100/0x130 dwc2_lowlevel_hw_enable+0x18/0x40 dwc2_hsotg_udc_start+0x6c/0x2f0 gadget_bind_driver+0x124/0x1f4 -> #0 (udc_lock){+.+.}-{3:3}: __lock_acquire+0x1298/0x20cc lock_acquire.part.0+0xe0/0x230 lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 usb_udc_uevent+0x54/0xe0 Evidentemente, esto se debió a que el alcance de udc_mutex era demasiado grande. El mutex solo protege udc->driver, entre otras cosas. Hasta donde sé, no hay razón para que el mutex se mantenga mientras el núcleo del gadget llama a la rutina ->bind o ->unbind de un controlador de gadget, ni mientras se inicia o detiene un UDC. (Esto explica el enlace n.º 1 de la cadena anterior, donde el mutex se mantiene mientras se inicia dwc2_hsotg_udc como parte del sondeo del controlador). Las devoluciones de llamada ->disconnect de los controladores de gadget son problemáticas. Aunque usb_gadget_disconnect() ahora adquirirá el udc_mutex, existe un margen en usb_gadget_bind_driver() entre el momento en que se libera el mutex y se invoca la devolucion de llamada ->bind. Si se produjera una desconexión durante ese margen, podríamos llamar a la rutina ->disconnect del controlador antes que a su rutina ->bind. Para evitarlo, será necesario impedir que un UDC se conecte mientras no tenga un controlador de gadget. Esto ya debería estar hecho, pero no parece estarlo; actualmente, usb_gadget_connect() no lo comprueba. Esta comprobación deberá añadirse más adelante. Se requiere cierto grado de exclusión mutua en soft_connect_store(), que puede desreferenciar udc->driver en cualquier momento, ya que es una devolución de llamada de sysfs. La solución es adquirir el bloqueo del dispositivo del gadget en lugar del udc_mutex. Dado que el núcleo del controlador garantiza que el bloqueo del dispositivo se mantenga siempre durante la vinculación y desvinculación del controlador, esto hará que los accesos en soft_connect_store() sean mutuamente excluyentes con cualquier cambio en udc->driver. Por último, resulta que hay un lugar que debería contener el udc_mutex, pero actualmente no lo hace: la rutina function_show() necesita protección mientras desreferencia udc->driver. Se añaden las llamadas de bloqueo y desbloqueo que faltan.
Vulnerabilidad en kernel de Linux (CVE-2022-49944)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "usb: typec: ucsi: añadir una función común ucsi_unregister_connectors()". La reciente confirmación 87d0e2f41b8c ("usb: typec: ucsi: añadir una función común ucsi_unregister_connectors()") introdujo una regresión que provocaba una desreferencia nula al leer el archivo sysfs de la fuente de alimentación. Se trata de una entrada obsoleta del archivo sysfs que debería haberse eliminado, pero que permanece con operaciones nulas. el commit modificó la gestión de errores para omitir las entradas después de un comando con->wq nulo, lo que deja el dispositivo de alimentación sin liberar. Para solucionar la regresión, se aplica la reversión directa. Se pueden realizar mejoras de código desde cero.
Vulnerabilidad en kernel de Linux (CVE-2022-49945)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (gpio-fan) Corrección de acceso fuera de los límites a una matriz. El controlador no comprueba si el estado de refrigeración transferido a gpio_fan_set_cur_state() supera el estado de refrigeración máximo almacenado en fan_data->num_speeds. Dado que el estado de refrigeración se utiliza posteriormente como índice de matriz en set_fan_speed(), puede producirse un acceso fuera de los límites a una matriz. Esto se puede explotar configurando el estado del dispositivo de refrigeración térmica con valores arbitrarios, lo que provoca, por ejemplo, un error en el kernel al acceder a memoria no disponible de esta forma. Ejemplo de error de kernel: [807.987276] No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffffff80d0588064 [807.987369] Información de aborto de memoria: [807.987398] ESR = 0x96000005 [807.987428] EC = 0x25: DABT (EL actual), IL = 32 bits [807.987477] SET = 0, FnV = 0 [807.987507] EA = 0, S1PTW = 0 [807.987536] FSC = 0x05: error de traducción de nivel 1 [807.987570] Información de aborto de datos: [ 807.987398] ESR = 0x96000005 [ 807.987428] EC = 0x25: DABT (current EL), IL = 32 bits [ 807.987477] SET = 0, FnV = 0 [ 807.987507] EA = 0, S1PTW = 0 [ 807.987536] FSC = 0x05: level 1 translation fault [ 807.987570] Data abort info: [ 807.987763] ISV = 0, ISS = 0x00000005 [ 807.987801] CM = 0, WnR = 0 [ 807.987832] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000001165000 [ 807.987872] [ffffff80d0588064] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 807.987961] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 807.987992] Modules linked in: cmac algif_hash aes_arm64 algif_skcipher af_alg bnep hci_uart btbcm bluetooth ecdh_generic ecc 8021q garp stp llc snd_soc_hdmi_codec brcmfmac vc4 brcmutil cec drm_kms_helper snd_soc_core cfg80211 snd_compress bcm2835_codec(C) snd_pcm_dmaengine syscopyarea bcm2835_isp(C) bcm2835_v4l2(C) sysfillrect v4l2_mem2mem bcm2835_mmal_vchiq(C) raspberrypi_hwmon sysimgblt videobuf2_dma_contig videobuf2_vmalloc fb_sys_fops videobuf2_memops rfkill videobuf2_v4l2 videobuf2_common i2c_bcm2835 snd_bcm2835(C) videodev snd_pcm snd_timer snd mc vc_sm_cma(C) gpio_fan uio_pdrv_genirq uio drm fuse drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [ 807.988508] CPU: 0 PID: 1321 Comm: bash Tainted: G C 5.15.56-v8+ #1575 [ 807.988548] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 807.988574] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 807.988608] pc : set_fan_speed.part.5+0x34/0x80 [gpio_fan] [ 807.988654] lr : gpio_fan_set_cur_state+0x34/0x50 [gpio_fan] [ 807.988691] sp : ffffffc008cf3bd0 [ 807.988710] x29: ffffffc008cf3bd0 x28: ffffff80019edac0 x27: 0000000000000000 [ 807.988762] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800747c920 [ 807.988787] x23: 000000000000000a x22: ffffff800369f000 x21: 000000001999997c [ 807.988854] x20: ffffff800369f2e8 x19: ffffff8002ae8080 x18: 0000000000000000 [ 807.988877] x17: 0000000000000000 x16: 0000000000000000 x15: 000000559e271b70 [ 807.988938] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 807.988960] x11: 0000000000000000 x10: ffffffc008cf3c20 x9 : ffffffcfb60c741c [ 807.989018] x8 : 000000000000000a x7 : 00000000ffffffc9 x6 : 0000000000000009 [ 807.989040] x5 : 000000000000002a x4 : 0000000000000000 x3 : ffffff800369f2e8 [ 807.989062] x2 : 000000000000e780 x1 : 0000000000000001 x0 : ffffff80d0588060 [ 807.989084] Call trace: [ 807.989091] set_fan_speed.part.5+0x34/0x80 [gpio_fan] [ 807.989113] gpio_fan_set_cur_state+0x34/0x50 [gpio_fan] [ 807.989199] cur_state_store+0x84/0xd0 [ 807.989221] dev_attr_store+0x20/0x38 [ 807.989262] sysfs_kf_write+0x4c/0x60 [ 807.989282] kernfs_fop_write_iter+0x130/0x1c0 [ 807.989298] new_sync_write+0x10c/0x190 [ 807.989315] vfs_write+0x254/0x378 [ 807.989362] ksys_write+0x70/0xf8 [ 807.989379] __arm64_sys_write+0x24/0x30 [ 807.989424] invoke_syscall+0x4c/0x110 [ 807.989442] ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2022-49946)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: bcm: rpi: Impedir acceso fuera de los límites. El bucle while en raspberrypi_discover_clocks() asume que el ID del último elemento de reloj es cero. Dado que estos datos provienen del firmware de Videocore y no garantizan dicho comportamiento, esto podría provocar un acceso fuera de los límites. Para solucionarlo, se debe proporcionar un elemento centinela.
Vulnerabilidad en kernel de Linux (CVE-2022-49947)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: corrección de la desreferencia alloc->vma_vm_mm null-ptr. Syzbot informó de un par de problemas introducidos por el commit 44e602b4e52f ("binder_alloc: añadir llamadas mmap_lock faltantes al usar la VMA"), en el que se intenta adquirir mmap_lock cuando alloc->vma_vm_mm aún no se ha inicializado. Esto puede ocurrir si un binder_proc recibe una transacción sin haber llamado previamente a mmap() para configurar el espacio binder_proc->alloc en [1]. Además, se produce un problema similar mediante binder_alloc_print_pages() al intentar volcar el archivo de estadísticas de binder debugfs en [2]. Ejemplo de informe de fallos de syzbot: ======================================================================= KASAN: null-ptr-deref en el rango [0x0000000000000128-0x000000000000012f] CPU: 0 PID: 3755 Comm: syz-executor229 No contaminado 6.0.0-rc1-next-20220819-syzkaller #0 syz-executor229[3755] cmdline: ./syz-executor2294415195 Nombre del hardware: Google Google Compute Engine/Google Compute Motor, BIOS Google 22/07/2022 RIP: 0010:__lock_acquire+0xd83/0x56d0 kernel/locking/lockdep.c:4923 [...] Rastreo de llamadas: lock_acquire kernel/locking/lockdep.c:5666 [inline] lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631 down_read+0x98/0x450 kernel/locking/rwsem.c:1499 mmap_read_lock include/linux/mmap_lock.h:117 [inline] binder_alloc_new_buf_locked drivers/android/binder_alloc.c:405 [inline] binder_alloc_new_buf+0xa5/0x19e0 drivers/android/binder_alloc.c:593 binder_transaction+0x242e/0x9a80 drivers/android/binder.c:3199 binder_thread_write+0x664/0x3220 drivers/android/binder.c:3986 binder_ioctl_write_read drivers/android/binder.c:5036 [inline] binder_ioctl+0x3470/0x6d00 drivers/android/binder.c:5323 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] ================================================================== Solucione estos problemas configurando el puntero alloc->vma_vm_mm durante la operación open() y almacenando en caché directamente desde current->mm. Esto garantiza una referencia válida para tomar mmap_lock en los escenarios descritos anteriormente.. [1] https://syzkaller.appspot.com/bug?extid=f7dc54e5be28950ac459 [2] https://syzkaller.appspot.com/bug?extid=a75ebe0452711c9e56d9
Vulnerabilidad en kernel de Linux (CVE-2022-49948)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vt: Borrar la selección antes de cambiar la fuente. Al cambiar la fuente de la consola con ioctl(KDFONTOP), el nuevo tamaño de fuente puede ser mayor que el anterior. Por lo tanto, una selección anterior podría quedar fuera del nuevo tamaño de pantalla y, por lo tanto, provocar accesos fuera de los límites a la memoria gráfica si se elimina la selección en vc_do_resize(). Para evitar estos accesos fuera de memoria, elimine la selección antes de llamar a los controladores de consola con_font_set().
Vulnerabilidad en kernel de Linux (CVE-2022-49949)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware_loader: Se corrige una fuga de memoria durante la carga de firmware. En la carga de firmware, se asigna una instancia de la estructura fw_upload en firmware_upload_register(). Estos datos deben liberarse en fw_dev_release(). Cree una nueva función fw_upload_free() en sysfs_upload.c para gestionar las liberaciones de memoria específicas de la carga de firmware e incorpore la llamada kfree que falta para la estructura fw_upload.
Vulnerabilidad en kernel de Linux (CVE-2022-49950)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: fastrpc: corrige corrupción de memoria al abrir La comprobación de desbordamiento de duplicación de sesión de la sonda incrementó el recuento de sesiones también cuando no había más sesiones disponibles, de modo que la memoria más allá de la matriz de sesiones asignadas en bloques de tamaño fijo podía corromperse en fastrpc_session_alloc() al abrir().
Vulnerabilidad en kernel de Linux (CVE-2022-49951)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware_loader: Se corrige el error "use-after-free" durante la anulación del registro. En el siguiente código, dentro de firmware_upload_unregister(), la llamada a device_unregister() podría provocar que la función dev_release libere la estructura fw_upload_priv antes de que se desreferenciara para la llamada a module_put(). Este error fue detectado por el robot de pruebas del kernel mediante CONFIG_KASAN al ejecutar las autopruebas del firmware. device_unregister(&fw_sysfs->dev); module_put(fw_upload_priv->module); El problema se corrige copiando fw_upload_priv->module a una variable local para su uso al llamar a device_unregister().
Vulnerabilidad en kernel de Linux (CVE-2022-49952)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: fastrpc: corregir corrupción de memoria en la sonda Agregue la verificación de cordura faltante en el recuento de sesiones sondeadas para evitar corromper la memoria más allá de la matriz de sesiones asignadas por bloques de tamaño fijo cuando hay más de FASTRPC_MAX_SESSIONS sesiones definidas en el árbol de dispositivos.
Vulnerabilidad en kernel de Linux (CVE-2022-49953)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: light: cm3605: Se corrige una ruta de gestión de errores en cm3605_probe(). El commit en Fixes (correcciones) también introdujo una nueva ruta de gestión de errores que debería enlazar con la ruta de gestión de errores existente. De lo contrario, se producirían fugas de recursos.
Vulnerabilidad en kernel de Linux (CVE-2022-49954)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: iforce - reactivar tras borrar el indicador IFORCE_XMIT_RUNNING. syzbot informa que la tarea está bloqueada en __input_unregister_device() [1], ya que iforce_close() espera en wait_event_interruptible() con dev->mutex retenido, lo que bloquea input_disconnect_device() desde __input_unregister_device(). Parece que la causa es simplemente que el commit c2b27ef672992a20 ("Entrada: iforce - esperar a que se complete el comando al cerrar el dispositivo") olvidó llamar a wake_up() después de clear_bit(). Se soluciona este problema mediante un asistente que llame a clear_bit() seguido de wake_up_all().
Vulnerabilidad en kernel de Linux (CVE-2022-49955)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/rtas: Corrección del manejo de MSR[HV] de RTAS para Cell. Los cambios recientes en el manejo de MSR al ingresar RTAS (firmware) provocan bloqueos en las máquinas IBM Cell. Ejemplo de rastreo: el kernel intentó ejecutar la página de usuario (2fff01a8): ¿intento de explotación? (uid: 0) ERROR: No se puede controlar la obtención de instrucciones del núcleo Dirección de instrucción errónea: 0x2fff01a8 Oops: Acceso del núcleo al área defectuosa, firma: 11 [#1] BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=4 Módulos de celda NUMA vinculados: CPU: 0 PID: 0 Comm: swapper/0 Contaminado: GW 6.0.0-rc2-00433-gede0a8d3307a #207 NIP: 000000002fff01a8 LR: 0000000000032608 CTR: 000000000000000 REGS: c0000000015236b0 TRAP: 0400 Contaminado: GW (6.0.0-rc2-00433-gede0a8d3307a) MSR: 0000000008001002 CR: 00000000 XER: 20000000 ... NIP 0x2fff01a8 LR 0x32608 Rastreo de llamadas: 0xc00000000143c5f8 (no confiable) .rtas_call+0x224/0x320 .rtas_get_boot_time+0x70/0x150 .read_persistent_clock64+0x114/0x140 .read_persistent_wall_and_boot_offset+0x24/0x80 .timekeeping_init+0x40/0x29c A diferencia de las plataformas PAPR, donde RTAS solo se usa en huéspedes, en las máquinas IBM Cell, Linux se ejecuta con MSR[HV] activado, pero también usa RTAS, proporcionado por SLOF. Para solucionarlo, copie el bit MSR[HV] del valor MSR que acabamos de leer con mfmsr al valor usado para RTAS. Parece que también podríamos solucionarlo usando un #ifdef CELL para activar MSR[HV], pero esto no funciona, ya que es posible crear una única imagen de kernel que funcione tanto en Cell nativo como en pseries.
Vulnerabilidad en kernel de Linux (CVE-2022-49957)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kcm: corrección del orden y la limpieza de strp_init(). strp_init() se llama solo unas líneas por encima de la comprobación csk->sk_user_data; también inicializa strp->work, etc., por lo que no es necesario llamar a strp_done() para cancelar el trabajo recién inicializado. Si KCM ya utiliza sk_user_data, no se debe modificar psock->strp, en particular el estado strp->work, por lo que es necesario mover strp_init() después de la comprobación csk->sk_user_data. Esto también elimina la advertencia de lockdep reportada por syzbot.
Vulnerabilidad en kernel de Linux (CVE-2022-49958)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: corrige fugas de referencia de netdevice en attached_default_qdiscs() En attached_default_qdiscs(), si un dev tiene varias colas y la cola 0 no puede adjuntar qdisc porque no hay memoria en attached_one_default_qdisc(). Entonces dev->qdisc será noop_qdisc por defecto. Pero las otras colas pueden ser capaces de adjuntar con éxito a la qdisc predeterminada. En este caso, se activará el proceso de retorno a noqueue. Si la qdisc adjunta original no se libera y se adjunta una nueva directamente, esto causará fugas de referencia de netdevice. El siguiente es el registro de errores: veth0: falla de qdisc predeterminada (fq_codel), retorno a noqueue unregister_netdevice: esperando a que veth0 se libere. Recuento de uso = 32 referencias filtradas. qdisc_alloc+0x12e/0x210 qdisc_create_dflt+0x62/0x140 attach_one_default_qdisc.constprop.41+0x44/0x70 dev_activate+0x128/0x290 __dev_open+0x12a/0x190 __dev_change_flags+0x1a2/0x1f0 dev_change_flags+0x23/0x60 do_setlink+0x332/0x1150 __rtnl_newlink+0x52f/0x8e0 rtnl_newlink+0x43/0x70 rtnetlink_rcv_msg+0x140/0x3b0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x1bb/0x290 netlink_sendmsg+0x37c/0x4e0 sock_sendmsg+0x5f/0x70 ____sys_sendmsg+0x208/0x280 Corrija este error borrando cualquier qdisc que no sea noop que pueda haberse asignado antes de intentar volver a conectar.
Vulnerabilidad en kernel de Linux (CVE-2022-49959)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: openvswitch: se corrige una fuga de memoria al crear una ruta de datos fallida. ovs_dp_cmd_new()->ovs_dp_change()->ovs_dp_set_upcall_portids() asigna una matriz mediante kmalloc. Si por alguna razón new_vport() falla durante ovs_dp_cmd_new(), se debe liberar dp->upcall_portids. Se añade la falta de kfree. Ejemplo de Kmemleak: objeto sin referencia 0xffff88800c382500 (tamaño 64): comm "dump_state", pid 323, jiffies 4294955418 (edad 104.347s) volcado hexadecimal (primeros 32 bytes): 5e c2 79 e4 1f 7a 38 c7 09 21 38 0c 80 88 ff ff ^.y..z8..!8..... 03 00 00 00 0a 00 00 00 14 00 00 00 28 00 00 00 ............(... backtrace: [<0000000071bebc9f>] ovs_dp_set_upcall_portids+0x38/0xa0 [<000000000187d8bd>] ovs_dp_change+0x63/0xe0 [<000000002397e446>] ovs_dp_cmd_new+0x1f0/0x380 [<00000000aa06f36e>] genl_family_rcv_msg_doit+0xea/0x150 [<000000008f583bc4>] genl_rcv_msg+0xdc/0x1e0 [<00000000fa10e377>] netlink_rcv_skb+0x50/0x100 [<000000004959cece>] genl_rcv+0x24/0x40 [<000000004699ac7f>] netlink_unicast+0x23e/0x360 [<00000000c153573e>] netlink_sendmsg+0x24e/0x4b0 [<000000006f4aa380>] sock_sendmsg+0x62/0x70 [<00000000d0068654>] ____sys_sendmsg+0x230/0x270 [<0000000012dacf7d>] ___sys_sendmsg+0x88/0xd0 [<0000000011776020>] __sys_sendmsg+0x59/0xa0 [<000000002e8f2dc1>] do_syscall_64+0x3b/0x90 [<000000003243e7cb>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Vulnerabilidad en kernel de Linux (CVE-2022-49960)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915: se corrige la desreferencia de puntero nulo. La Chromebook Asus CX550 se bloquea durante el arranque en el kernel v5.17-rc1. La causa principal es la desreferencia de puntero nulo de bi_next en tgl_get_bw_info() en drivers/gpu/drm/i915/display/intel_bw.c. ERROR: desreferencia de puntero NULL del kernel, dirección: 000000000000002e PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 1 Comm: swapper/0 Contaminado: GU 5.17.0-rc1 Nombre del hardware: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3 14/05/2021 RIP: 0010:tgl_get_bw_info+0x2de/0x510 ... [ 2.554467] Seguimiento de llamadas: [ 2.554467] [ 2.554467] intel_bw_init_hw+0x14a/0x434 [ 2.554467] ? _printk+0x59/0x73 [ 2.554467] ? _dev_err+0x77/0x91 [ 2.554467] i915_driver_hw_probe+0x329/0x33e [ 2.554467] i915_driver_probe+0x4c8/0x638 [ 2.554467] i915_pci_probe+0xf8/0x14e [ 2.554467] ? _raw_spin_unlock_irqrestore+0x12/0x2c [ 2.554467] pci_device_probe+0xaa/0x142 [ 2.554467] really_probe+0x13f/0x2f4 [ 2.554467] __driver_probe_device+0x9e/0xd3 [ 2.554467] driver_probe_device+0x24/0x7c [ 2.554467] __driver_attach+0xba/0xcf [ 2.554467] ? driver_attach+0x1f/0x1f [ 2.554467] bus_for_each_dev+0x8c/0xc0 [ 2.554467] bus_add_driver+0x11b/0x1f7 [ 2.554467] driver_register+0x60/0xea [ 2.554467] ? mipi_dsi_bus_init+0x16/0x16 [ 2.554467] i915_init+0x2c/0xb9 [ 2.554467] ? mipi_dsi_bus_init+0x16/0x16 [ 2.554467] do_one_initcall+0x12e/0x2b3 [ 2.554467] do_initcall_level+0xd6/0xf3 [ 2.554467] do_initcalls+0x4e/0x79 [ 2.554467] kernel_init_freeable+0xed/0x14d [ 2.554467] ? rest_init+0xc1/0xc1 [ 2.554467] kernel_init+0x1a/0x120 [ 2.554467] ret_from_fork+0x1f/0x30 [ 2.554467] ... Pánico del kernel - no sincroniza: Excepción fatal (seleccionada de el commit c247cd03898c4c43c3bce6d4014730403bc13032)
Vulnerabilidad en kernel de Linux (CVE-2022-49961)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Hacer mark_chain_precision para ARG_CONST_ALLOC_SIZE_OR_ZERO Los marcadores de precisión deben propagarse siempre que tengamos un argumento de estilo ARG_CONST_*, ya que el verificador no puede considerar que los escalares imprecisos sean equivalentes para los fines de la comprobación states_equal cuando dichos argumentos refinan el valor de retorno (en este caso, establecer mem_size para PTR_TO_MEM). El mem_size resultante para el R0 se deriva del valor constante, y si el verificador poda incorrectamente los estados considerándolos equivalentes donde existen dichos argumentos (al ver que ambos registros tienen reg->precise como falso en regsafe), podemos terminar con programas no válidos que pasan el verificador que pueden hacer acceso más allá de lo que debería haber sido el mem_size correcto en ese estado explorado. Para mostrar un ejemplo concreto del problema: 0000000000000000 : 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: si r3 > r2 goto +18 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: si w1 == 0 goto +1 10: r2 = -1 0000000000000058 : 11: r1 = 0 ll 13: r3 = 0 14: llamar a bpf_ringbuf_reserve 15: si r0 == 0 goto +7 16: r1 = r0 17: r1 += 16777215 18: w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: llamar a bpf_ringbuf_submit 00000000000000b8 : 23: w0 = 0 24: salir Para el primer caso, la exploración de la ejecución de una sola línea podará la búsqueda en insn 14 para la segunda rama de la rama insn 9, ya que se verificará primero utilizando r2 = -1 (UINT_MAX), mientras que como w1 en insn 9 siempre será 0, por lo que en tiempo de ejecución no obtenemos un error por ser mayor que UINT_MAX/4 de bpf_ringbuf_reserve. El verificador durante regsafe solo ve reg->precise como falso para ambos registros r2 en ambos estados, por lo tanto, los considera iguales para fines de states_equal. Si propagáramos marcadores precisos utilizando el soporte de retroceso, usaríamos el marcado preciso para asegurarnos de que el antiguo r2 (UINT_MAX) estuviera dentro del nuevo r2 (1) y esto nunca sería verdadero, por lo que la verificación fallaría legítimamente. El resultado final es que el acceso fuera de los límites en la instrucción 19 se permitiría sin esta corrección. Tenga en cuenta que reg->precise siempre se establece en verdadero cuando el usuario no tiene CAP_BPF (o cuando el recuento de subprocesos es mayor que 1 (es decir, uso de cualquier función estática o global)), por lo tanto, esto solo es un problema cuando las marcas de precisión deben propagarse explícitamente (es decir, usuarios privilegiados con CAP_BPF). Se ha incluido un caso de prueba simplificado en el próximo parche para evitar futuras regresiones.
Vulnerabilidad en kernel de Linux (CVE-2022-49962)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xhci: Se corrige la desreferencia de puntero nulo al eliminar si xHC solo tiene un concentrador raíz. La ruta de eliminación en el controlador de la plataforma xhci intenta eliminar e instalar los discos duros principal y compartido, incluso si solo existe un disco duro principal (un concentrador raíz). Esto provoca una desreferencia de puntero nulo al reiniciar esos controladores. Compruebe que el disco duro compartido exista antes de intentar eliminarlo.
Vulnerabilidad en kernel de Linux (CVE-2022-49963)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/ttm: corrección del manejo de CCS Crucible + Mesa reciente parece a veces afectar: GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER) Y parece que también podemos activar esto con gem_lmem_swapping, si modificamos la prueba para usar tamaños de objeto ligeramente mayores. Mirando más de cerca, parece que tenemos los siguientes problemas en migration_copy(): - Estamos usando un entero simple en varios lugares, que podemos desbordar fácilmente con un objeto grande. - Pasamos el tamaño completo del objeto (cuando el src es lmem) a emit_pte() y luego intentamos copiarlo, lo cual no funciona, ya que solo tenemos unas pocas ventanas de tamaño fijo en las que mapear las páginas y realizar la copia. Con un objeto > 8M, por lo tanto, no estamos copiando correctamente las páginas. Y luego, con un objeto > 64M, activamos GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER). Por lo tanto, parece que nuestra gestión de copias para cualquier objeto > 8M (que es nuestro CHUNK_SZ) está actualmente inactiva en DG2. Caso de prueba: igt@gem_lmem_swapping (seleccionado de el commit 8676145eb2f53a9940ff70910caf0125bd8a4bc2)
Vulnerabilidad en kernel de Linux (CVE-2022-49964)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: cacheinfo: Se corrige la asignación incorrecta de un valor de error con signo a unsigned fw_level. Aunque acpi_find_last_cache_level() siempre devolvía un valor con signo y el documento indica que devolverá cualquier error causado por la falta de una tabla PPTT, nunca antes devolvía valores negativos. Sin embargo, el commit 0c80f9e165f8 ("ACPI: PPTT: Dejar la tabla asignada para el uso en tiempo de ejecución") la modificó devolviendo -ENOENT si no se encontraba PPTT. El valor devuelto por acpi_find_last_cache_level() se asigna entonces a unsigned fw_level. Esto provocará que el número de hojas de caché se calcule incorrectamente como un valor enorme, lo que provocará la siguiente advertencia de __alloc_pages, ya que el orden sería mayor que MAX_ORDER debido a un valor incorrecto y enorme de hojas de caché. ADVERTENCIA: CPU: 0 PID: 1 en mm/page_alloc.c:5407 __alloc_pages+0x74/0x314 | Módulos vinculados: | CPU: 0 PID: 1 Comm: swapper/0 No contaminado 5.19.0-10393-g7c2a8d3ac4c0 #73 | pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : __alloc_pages+0x74/0x314 | lr : alloc_pages+0xe8/0x318 | Rastreo de llamadas: | __alloc_pages+0x74/0x314 | alloc_pages+0xe8/0x318 | kmalloc_order_trace+0x68/0x1dc | Corrija el mismo problema cambiando fw_level para que sea un entero con signo y devuelva el error de init_cache_level() de manera temprana en caso de error.
Vulnerabilidad en kernel de Linux (CVE-2022-49965)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: agregar interfaces ->fini_xxxx faltantes para algunos ASIC SMU13. Sin estas, se puede inducir una posible pérdida de memoria.
Vulnerabilidad en kernel de Linux (CVE-2022-49966)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: agregar la interfaz ->fini_microcode faltante para Sienna Cichlid para evitar cualquier posible pérdida de memoria.
Vulnerabilidad en kernel de Linux (CVE-2022-49967)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrige una ejecución de datos en torno a bpf_jit_limit. Al leer bpf_jit_limit, se puede modificar simultáneamente mediante sysctl, WRITE_ONCE() en __do_proc_doulongvec_minmax(). El tamaño de bpf_jit_limit es grande, por lo que es necesario añadir un par de READ_ONCE() para evitar la fragmentación de la carga.
Vulnerabilidad en kernel de Linux (CVE-2022-49977)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftrace: Se corrige la desreferencia del puntero NULL en is_ftrace_trampoline cuando ftrace está inactivo ftrace_startup no elimina las operaciones de ftrace_ops_list cuando ftrace_startup_enable falla: register_ftrace_function ftrace_startup __register_ftrace_function ... add_ftrace_ops(&ftrace_ops_list, ops) ... ... ftrace_startup_enable // si ftrace no se modificó, ftrace_disabled se establece en 1 ... return 0 // las operaciones están en ftrace_ops_list. Cuando ftrace_disabled = 1, unregister_ftrace_function simplemente regresa sin hacer nada: unregister_ftrace_function ftrace_shutdown if (unlikely(ftrace_disabled)) return -ENODEV; // regresa aquí, __unregister_ftrace_function no se ejecuta, // como resultado, ops todavía está en ftrace_ops_list __unregister_ftrace_function ... Si ops se asigna dinámicamente, estará libre más tarde, en este caso, is_ftrace_trampoline accede al puntero NULL: is_ftrace_trampoline ftrace_ops_trampoline do_for_each_ftrace_op(op, ftrace_ops_list) // ¡UPS! ¡op puede ser NULL! Syzkaller informa lo siguiente: [ 1203.506103] ERROR: desreferencia de puntero NULL del kernel, dirección: 000000000000010b [ 1203.508039] #PF: acceso de lectura del supervisor en modo kernel [ 1203.508798] #PF: error_code(0x0000) - página no presente [ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0 [ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI [ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Contaminado: GBW 5.10.0 #8 [1203.512324] Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 01/04/2014 [1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0 [1203.514644] Código: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 <48> 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00 [ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246 [ 1203.520092] RAX: 000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866 [ 1203.521469] RDX: 00000000000000000 RSI: 0000000000000008 RDI: 0000000000000010b [ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07 [ 1203.523550] R10: fffffbfff1be3160 R11: 000000000000001 R12: 0000000000478399 [ 1203.524596] R13: 000000000000000 R14: ffff888145088000 R15: 0000000000000008 [ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000 [ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1203.527626] CR2: 00000000000010b CR3: 0000000170e1e001 CR4: 000000000003706e0 [ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Por lo tanto, cuando ftrace_startup_enable falla, debemos revertir el proceso de registro y eliminar las operaciones de ftrace_ops_list.
Vulnerabilidad en kernel de Linux (CVE-2022-49978)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: fb_pm2fb: Evitar posible error de división por cero En `do_fb_ioctl()` de fbmem.c, si cmd es FBIOPUT_VSCREENINFO, var se copiará del usuario, luego pasará por `fb_set_var()` e `info->fbops->fb_check_var()` que podrían ser `pm2fb_check_var()`. A lo largo de la ruta, `var->pixclock` no se modificará. Esta función verifica si el recíproco de `var->pixclock` es demasiado alto. Si `var->pixclock` es cero, habrá un error de división por cero. Por lo tanto, es necesario verificar si el denominador es cero para evitar un bloqueo. Como Syzkaller encontró este error, los registros se enumeran a continuación. Error de división en el seguimiento de llamadas pm2fb_check_var: fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189
Vulnerabilidad en kernel de Linux (CVE-2022-49979)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: corrige error de recuento de referencias en sk_psock_get (2) Syzkaller informa el siguiente error de recuento de referencias: ------------[ cortar aquí ]------------ refcount_t: saturado; pérdida de memoria. ADVERTENCIA: CPU: 1 PID: 3605 en lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19 Módulos vinculados: CPU: 1 PID: 3605 Comm: syz-executor208 No contaminado 5.18.0-syzkaller-03023-g7e062cda7d90 #0 __refcount_add_not_zero include/linux/refcount.h:163 [en línea] __refcount_inc_not_zero include/linux/refcount.h:227 [en línea] refcount_inc_not_zero include/linux/refcount.h:245 [en línea] sk_psock_get+0x3bc/0x410 incluir/linux/skmsg.h:439 tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091 tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983 tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057 tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659 tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682 sk_backlog_rcv incluir/net/sock.h:1061 [en línea] __release_sock+0x134/0x3b0 net/core/sock.c:2849 release_sock+0x54/0x1b0 net/core/sock.c:3404 inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909 __sys_shutdown_sock net/socket.c:2331 [en línea] __sys_shutdown_sock net/socket.c:2325 [en línea] __sys_shutdown+0xf1/0x1b0 net/socket.c:2343 __do_sys_shutdown net/socket.c:2351 [en línea] __se_sys_shutdown net/socket.c:2349 [en línea] Durante el proceso de respaldo de SMC en la llamada al sistema de conexión, el kernel reemplaza TCP con SMC. Para reenviar la cola de espera del socket SMC de activación después del respaldo, el kernel establece clcsk->sk_user_data en el socket SMC de origen en smc_fback_replace_callbacks(). Posteriormente, en la llamada al sistema de apagado, el kernel llamará a sk_psock_get(), que trata clcsk->sk_user_data como de tipo psock, lo que activa la advertencia refcnt. Por lo tanto, la causa principal es que tanto smc como psock utilizan el campo sk_user_data, por lo que es fácil que no coincidan con este campo. Este parche soluciona este problema utilizando otro bit (definido como SK_USER_DATA_PSOCK) en PTRMASK para indicar si sk_user_data apunta a un objeto psock. Este parche depende de una PTRMASK introducida en el commit f1ff5ce2cd5e ("net, sk_msg: Borrar el puntero sk_user_data al clonar si está etiquetado"). Dado que posiblemente haya más indicadores en el campo sk_user_data, este parche también refactoriza el código de indicadores sk_user_data para que sea más genérico y mejore su mantenimiento.
Vulnerabilidad en kernel de Linux (CVE-2022-49980)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: gadget: Corrección de lectura de Use-After-Free en usb_udc_uevent() El analizador de vulnerabilidades syzbot encontró una ejecución entre las devoluciones de llamadas de uevent y la anulación del registro del controlador del gadget que puede causar un error de Use-After-Free: --------------------------------------------------------------- ERROR: KASAN: Use-After-Free en usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732 Lectura de tamaño 8 en la dirección ffff888078ce2050 por la tarea udevd/2968 CPU: 1 PID: 2968 Comm: udevd No contaminado 5.19.0-rc4-next-20220628-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 29/06/2022 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report+0xbe/0x1f0 mm/kasan/report.c:495 usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732 dev_uevent+0x290/0x770 drivers/base/core.c:2424 --------------------------------------------------------------- El error ocurre porque usb_udc_uevent() desreferencia udc->driver pero lo hace sin adquirir el Mutex udc_lock, que protege este campo. Si el controlador del gadget se desvincula del udc simultáneamente con el procesamiento de uevent, se puede acceder a la estructura del controlador después de su desasignación. Para evitar la competencia, nos aseguramos de que la rutina mantenga el mutex en los accesos de competencia.
Vulnerabilidad en kernel de Linux (CVE-2022-49981)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: hidraw: corrige pérdida de memoria en hidraw_release() Libera los informes almacenados en búfer antes de eliminar la entrada de la lista. ERROR: Fuga de memoria, objeto no referenciado 0xffff88810e72f180 (tamaño 32): comm "softirq", pid 0, jiffies 4294945143 (edad 16.080s) volcado hexadecimal (primeros 32 bytes): 64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 00 d..j............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmemdup+0x23/0x50 mm/util.c:128 [] kmemdup include/linux/fortify-string.h:440 [inline] [] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521 [] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992 [] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065 [] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284 [] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670 [] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747 [] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988 [] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474 [] expire_timers kernel/time/timer.c:1519 [inline] [] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790 [] __run_timers kernel/time/timer.c:1768 [inline] [] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803 [] __do_softirq+0xe6/0x2ea kernel/softirq.c:571 [] invoke_softirq kernel/softirq.c:445 [inline] [] __irq_exit_rcu kernel/softirq.c:650 [inline] [] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662 [] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106 [] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649 [] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline] [] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline] [] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline] [] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554
Vulnerabilidad en kernel de Linux (CVE-2022-49982)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: pvrusb2: se corrige una fuga de memoria en pvr_probe. El código de gestión de errores en pvr2_hdw_create olvida anular el registro del dispositivo v4l2. Cuando pvr2_hdw_create regresa a pvr2_context_create, llama a pvr2_context_destroy para destruir el contexto, pero mp->hdw es NULL, lo que provoca que pvr2_hdw_destroy regrese directamente. Para solucionar esto, agregue v4l2_device_unregister para reducir el recuento de referencias de la interfaz USB.
Vulnerabilidad en kernel de Linux (CVE-2022-49983)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udmabuf: Establezca la máscara DMA para el dispositivo udmabuf (v2) Si la máscara DMA no se establece explícitamente, se produce la siguiente advertencia cuando el espacio de usuario intenta acceder a dma-buf a través de la CPU, como lo informa syzbot aquí: ADVERTENCIA: CPU: 1 PID: 3595 en kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Módulos vinculados en: CPU: 0 PID: 3595 Comm: syz-executor249 No contaminado 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Código: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 00000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 000000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 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 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 v2: No olvide cancelar el registro si falla la configuración de la máscara DMA.
Vulnerabilidad en kernel de Linux (CVE-2022-49984)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: Steam: Impedir la desreferencia de puntero nulo en steam_{recv,send}_report. Es posible que un dispositivo malicioso no envíe un Informe de Características. El controlador HID Steam no prevé esto actualmente y desreferencia el puntero 'struct hid_report' obtenido de los dispositivos HID sin verificar primero su validez. Vamos a corregir esto.
Vulnerabilidad en kernel de Linux (CVE-2022-49985)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: No use tnum_range en la comprobación del rango de matriz para los descriptores de poke Hsin-Wei informó un splat de KASAN activado por su fuzzer de tiempo de ejecución BPF que se basa en un syzkaller personalizado: ERROR: KASAN: slab-out-of-bounds en bpf_int_jit_compile+0x1257/0x13f0 Lectura de tamaño 8 en la dirección ffff888004e90b58 por la tarea syz-executor.0/1489 CPU: 1 PID: 1489 Comm: syz-executor.0 No contaminado 5.19.0 #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Rastreo de llamadas: dump_stack_lvl+0x9c/0xc9 print_address_description.constprop.0+0x1f/0x1f0 ? bpf_int_jit_compile+0x1257/0x13f0 kasan_report.cold+0xeb/0x197 ? kvmalloc_node+0x170/0x200 ? bpf_int_jit_compile+0x1257/0x13f0 bpf_int_jit_compile+0x1257/0x13f0 ? arch_prepare_bpf_dispatcher+0xd0/0xd0 ? rcu_read_lock_sched_held+0x43/0x70 bpf_prog_select_runtime+0x3e8/0x640 ? bpf_obj_name_cpy+0x149/0x1b0 bpf_prog_load+0x102f/0x2220 ? __bpf_prog_put.constprop.0+0x220/0x220 ? find_held_lock+0x2c/0x110 ? __might_fault+0xd6/0x180 ? lock_downgrade+0x6e0/0x6e0 ? lock_is_held_type+0xa6/0x120 ? __might_fault+0x147/0x180 __sys_bpf+0x137b/0x6070 ? bpf_perf_link_attach+0x530/0x530 ? new_sync_read+0x600/0x600 ? __fget_files+0x255/0x450 ? lock_downgrade+0x6e0/0x6e0 ? fput+0x30/0x1a0 ? ksys_write+0x1a8/0x260 __x64_sys_bpf+0x7a/0xc0 ? syscall_enter_from_user_mode+0x21/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f917c4e2c2d El problema aquí es que un rango de tnum_range(0, map->max_entries - 1) tiene una capacidad limitada para representar el rango estrecho concreto con el tnum como el conjunto de estados resultantes de value + mask puede resultar en un superconjunto del rango real deseado, y como tal una comprobación tnum_in(range, reg->var_off) puede dar como resultado verdadero cuando no debería, por ejemplo tnum_range(0, 2) daría como resultado 00XX -> v = 0000, m = 0011 de modo que el conjunto deseado de {0, 1, 2} está representado aquí por un superconjunto menos preciso de {0, 1, 2, 3}. Como el registro es un escalar constante, simplemente use el valor concreto reg->var_off.value para la verificación del índice superior.
Vulnerabilidad en kernel de Linux (CVE-2022-49986)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: storvsc: Eliminar WQ_MEM_RECLAIM de storvsc_error_wq. La cola de trabajo storvsc_error_wq no debe marcarse como WQ_MEM_RECLAIM, ya que no necesita avanzar bajo presión de memoria. Marcar esta cola de trabajo como WQ_MEM_RECLAIM puede causar un bloqueo al vaciar una cola de trabajo que no sea WQ_MEM_RECLAIM. En el estado actual, provoca la siguiente advertencia: [ 14.506347] ------------[ cortar aquí ]------------ [ 14.506354] cola de trabajo: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun se está vaciando !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn [ 14.506360] ADVERTENCIA: CPU: 0 PID: 8 en <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130 [ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 No contaminado 5.4.0-1086-azure #91~18.04.1-Ubuntu [ 14.506391] Nombre del hardware: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI versión v4.1 09/05/2022 [ 14.506393] Cola de trabajo: storvsc_error_wq_0 storvsc_remove_lun [ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130 <-snip-> [ 14.506408] Seguimiento de llamadas: [ 14.506412] __flush_work+0xf1/0x1c0 [ 14.506414] __cancel_work_timer+0x12f/0x1b0 [ 14.506417] ? kernfs_put+0xf0/0x190 [ 14.506418] cancel_delayed_work_sync+0x13/0x20 [ 14.506420] disk_block_events+0x78/0x80 [ 14.506421] del_gendisk+0x3d/0x2f0 [ 14.506423] sr_remove+0x28/0x70 [ 14.506427] device_release_driver_internal+0xef/0x1c0 [ 14.506428] device_release_driver+0x12/0x20 [ 14.506429] bus_remove_device+0xe1/0x150 [ 14.506431] device_del+0x167/0x380 [ 14.506432] __scsi_remove_device+0x11d/0x150 [ 14.506433] scsi_remove_device+0x26/0x40 [ 14.506434] storvsc_remove_lun+0x40/0x60 [ 14.506436] process_one_work+0x209/0x400 [ 14.506437] worker_thread+0x34/0x400 [ 14.506439] kthread+0x121/0x140 [ 14.506440] ? process_one_work+0x400/0x400 [ 14.506441] ? kthread_park+0x90/0x90 [ 14.506443] ret_from_fork+0x35/0x40 [ 14.506445] ---[ fin de seguimiento 2d9633159fdc6ee7 ]---
Vulnerabilidad en kernel de Linux (CVE-2022-49987)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: llamada a __md_stop_writes en md_stop. En el enlace [1], podemos ver que raid1d se ejecutaba incluso después de la ruta raid_dtr -> md_stop -> __md_stop. Primero detengamos la escritura en el destructor para alinearla con el comando md-raid normal y solucionar el problema de KASAN. [1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a
Vulnerabilidad en kernel de Linux (CVE-2022-49989)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen/privcmd: corrección del error de salida de privcmd_ioctl_dm_op(). La salida de error de privcmd_ioctl_dm_op() está llamando a unlock_pages() potencialmente con páginas NULL, lo que lleva a una desreferencia NULL. Además, lock_pages() no comprueba si pin_user_pages_fast() ha sido completamente exitoso, lo que resulta en que potencialmente no se bloqueen todas las páginas en la memoria. Esto podría resultar en fallos esporádicos al usar la memoria relacionada en modo de usuario. Corrija todo esto llamando a unlock_pages() siempre con el número real de páginas ancladas, que será cero en caso de que pages sea NULL, y comprobando que el número de páginas ancladas por pin_user_pages_fast() coincida con el número esperado de páginas.
Vulnerabilidad en kernel de Linux (CVE-2022-49990)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390: se corrige la doble liberación de los bloques de control de instrumentación de GS y RI en el fallo de fork() Los punteros para los bloques de control de instrumentación de almacenamiento protegido y tiempo de ejecución se almacenan en el thread_struct de la tarea asociada. Estos punteros se copian inicialmente en fork() mediante arch_dup_task_struct() y luego se borran mediante copy_thread() antes de que fork() regrese. Si fork() falla después del dup de la tarea inicial y antes de copy_thread(), la tarea recién asignada y la memoria thread_struct asociada se liberan mediante free_task() -> arch_release_task_struct(). Esto resulta en una doble liberación de las estructuras de información de almacenamiento protegido y tiempo de ejecución porque los campos en la tarea fallida todavía hacen referencia a la memoria asociada con la tarea de origen. Este problema puede manifestarse como un BUG_ON() en set_freepointer() (con CONFIG_SLAB_FREELIST_HARDENED habilitado) o un error de KASAN (si está habilitado) al ejecutar pruebas de fuzzing de llamadas al sistema de Trinity en s390x. Para evitar este problema, borre los campos de puntero asociados en arch_dup_task_struct() inmediatamente después de copiar la nueva tarea. Tenga en cuenta que el indicador RI permanece borrado en copy_thread() porque reside en la memoria de la pila de subprocesos, donde se copia la información de la pila.
Vulnerabilidad en kernel de Linux (CVE-2022-49991)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb: evitar la corrupción del mapeo de páginas en hugetlb_mcopy_atomic_pte. En el caso de MCOPY_ATOMIC_CONTINUE con un VMA no compartido, las páginas de la caché de páginas se instalan en los ptes. Sin embargo, se llama a hugepage_add_new_anon_rmap por error porque no son vm_shared. Esto corromperá el mapeo de páginas utilizado por el código de la caché de páginas.
Vulnerabilidad en kernel de Linux (CVE-2022-49992)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/mprotect: solo hace referencia a la página pfn de intercambio si coincide el tipo Yu Zhao informó un error después de el commit "mm/swap: Agregar swp_offset_pfn() para obtener PFN de la entrada de intercambio" agregó una verificación en swp_offset_pfn() para el tipo de intercambio [1]: ¡ERROR del kernel en include/linux/swapops.h:117! CPU: 46 PID: 5245 Com: EventManager_De Contaminado: GSOL 6.0.0-dbg-DEV #2 RIP: 0010:pfn_swap_entry_to_page+0x72/0xf0 Código: c6 48 8b 36 48 83 fe ff 74 53 48 01 d1 48 83 c1 08 48 8b 09 f6 c1 01 75 7b 66 90 48 89 c1 48 8b 09 f6 c1 01 74 74 5d c3 eb 9e <0f> 0b 48 ba ff ff ff ff 03 00 00 00 eb ae a9 ff 0f 00 00 75 13 48 RSP: 0018:ffffa59e73fabb80 EFLAGS: 00010282 RAX: 00000000ffffffe8 RBX: 0c00000000000000 RCX: ffffcd5440000000 RDX: 1ffffffffff7a80a RSI: 0000000000000000 RDI: 0c0000000000042b RBP: ffffa59e73fabb80 R08: ffff9965ca6e8bb8 R09: 0000000000000000 R10: ffffffffa5a2f62d R11: 0000030b372e9fff R12: ffff997b79db5738 R13: 000000000000042b R14: 0c0000000000042b R15: 1ffffffffff7a80a FS: 00007f549d1bb700(0000) GS:ffff99d3cf680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000440d035b3180 CR3: 0000002243176004 CR4: 00000000003706e0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: change_pte_range+0x36e/0x880 change_p4d_range+0x2e8/0x670 change_protection_range+0x14e/0x2c0 mprotect_fixup+0x1ee/0x330 do_mprotect_pkey+0x34c/0x440 __x64_sys_mprotect+0x1d/0x30 Se activa porque pfn_swap_entry_to_page() podría invocarse, por ejemplo, en una entrada de intercambio genuina. Para solucionarlo, invoque solo cuando se trate de una entrada de migración de escritura donde se use page*. [1] https://lore.kernel.org/lkml/CAOUHufaVC2Za-p8m0aiHw6YkheDcrO-C3wRGixwDS32VTS+k1w@mail.gmail.com/
Vulnerabilidad en kernel de Linux (CVE-2022-49993)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: loop: Comprobar si hay desbordamiento al configurar loop El espacio de usuario puede configurar un bucle mediante una llamada ioctl, en la que se pasa una configuración de tipo loop_config (consulte el caso de lo_ioctl() en la línea 1550 de drivers/block/loop.c). Esto procede a llamar a loop_configure() que a su vez llama a loop_set_status_from_info() (consulte la línea 1050 de loop.c), pasando &config->info que es de tipo loop_info64*. Esta función luego establece los valores apropiados, como el desplazamiento. loop_device tiene lo_offset de tipo loff_t (consulte la línea 52 de loop.c), que está encadenado por typdef a long long, mientras que loop_info64 tiene lo_offset de tipo __u64 (consulte la línea 56 de include/uapi/linux/loop.h). La función copia directamente el desplazamiento de info al dispositivo como se indica a continuación (véase la línea 980 de loop.c): lo->lo_offset = info->lo_offset; Esto genera un desbordamiento que genera una advertencia en iomap_iter() debido a una llamada a iomap_iter_done() que tiene: WARN_ON_ONCE(iter->iomap.offset > iter->pos); Por lo tanto, se debe verificar si hay un valor negativo durante loop_set_status_from_info(). Informe de error: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e
Vulnerabilidad en kernel de Linux (CVE-2022-49994)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bootmem: eliminar las páginas vmemmap de kmemleak en put_page_bootmem. Las páginas vmemmap están marcadas por kmemleak cuando se asignan desde memblock. Elimínelas de kmemleak al liberar la página. De lo contrario, al reutilizar la página, kmemleak podría informar dicho error y dejar de funcionar. kmemleak: No se puede insertar 0xffff98fb6eab3d40 en el árbol de búsqueda de objetos (se superpone a los existentes) kmemleak: Detector de fugas de memoria del kernel deshabilitado kmemleak: Objeto 0xffff98fb6be00000 (tamaño 335544320): kmemleak: comm "swapper", pid 0, jiffies 4294892296 kmemleak: min_count = 0 kmemleak: count = 0 kmemleak: flags = 0x1 kmemleak: checksum = 0 kmemleak: backtrace:
Vulnerabilidad en kernel de Linux (CVE-2022-49995)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: writeback: evitar el Use-After-Free tras retirar un dispositivo. Al retirar un disco, se llama a bdi_unregister para detener la escritura diferida y esperar a que se complete el trabajo retrasado asociado. Sin embargo, wb_inode_writeback_end() puede programar la estimación de ancho de banda dwork después de que esto se haya completado, lo que puede provocar que el temporizador intente acceder al bdi_writeback recién liberado. Para solucionar esto, verifique si bdi_writeback está activo, de forma similar a cuando se programa la escritura diferida. Dado que esto requiere wb->work_lock y wb_inode_writeback_end() puede ser llamado desde una interrupción, cambie wb->work_lock a un bloqueo irqsafe.
Vulnerabilidad en kernel de Linux (CVE-2022-49996)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige una posible pérdida de memoria en btrfs_get_dev_args_from_path(). En btrfs_get_dev_args_from_path(), btrfs_get_bdev_and_sb() puede fallar si la ruta no es válida. En este caso, btrfs_get_dev_args_from_path() retorna directamente sin liberar los argumentos args->uuid y args->fsid asignados previamente, lo que provoca una pérdida de memoria. Para corregir estas posibles pérdidas, cuando btrfs_get_bdev_and_sb() falla, se llama a btrfs_put_dev_args_from_path() para limpiar la memoria.
Vulnerabilidad en kernel de Linux (CVE-2022-49997)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: lantiq_xrx200: restaurar el búfer si falla la asignación de memoria. En caso de fallo en la asignación de memoria, se almacena una dirección de búfer no válida. Al volver a utilizar este descriptor, el sistema entra en pánico en la función build_skb() al acceder a la memoria.
Vulnerabilidad en kernel de Linux (CVE-2022-49998)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Arreglar el bloqueo en sendmsg de rxrpc Corrige tres errores en la implementación de sendmsg de rxrpc: (1) rxrpc_new_client_call() debería liberar el bloqueo del socket al devolver un error de rxrpc_get_call_slot(). (2) rxrpc_wait_for_tx_window_intr() retornará sin el mutex de llamada retenido en caso de que seamos interrumpidos por una señal mientras esperamos espacio de transmisión en el socket o volvemos a bloquear el mutex de llamada posteriormente. Corrige esto mediante: (a) mover el desbloqueo/bloqueo del mutex de llamada hasta rxrpc_send_data() de modo que el bloqueo no se mantenga alrededor de todo rxrpc_wait_for_tx_window*() y (b) indicar a los llamadores superiores si retornamos con el bloqueo eliminado. Tenga en cuenta que esto significa que recvmsg() no se bloqueará en esta llamada mientras esperamos. (3) Después de eliminar y recuperar el mutex de llamada, rxrpc_send_data() debe volver a verificar el estado del búfer tx_pending y la comprobación de tx_total_len en caso de que hayamos utilizado otro sendmsg() en la misma llamada. Pensándolo bien, podría tener sentido tener bloqueos diferentes para sendmsg() y recvmsg(). Probablemente no sea necesario que recvmsg() espere a sendmsg(). Esto significa que recvmsg() puede devolver MSG_EOR, lo que indica que una llamada está inactiva antes de que un sendmsg() a esa llamada regrese, pero eso puede ocurrir de todos modos. Sin la corrección (2), se puede inducir algo como lo siguiente: ¡ADVERTENCIA: se detectó un saldo de desbloqueo incorrecto! 5.16.0-rc6-syzkaller #0 No contaminado ------------------------------------- syz-executor011/3597 está intentando liberar el bloqueo (&call->user_mutex) en: [] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 ¡pero no hay más bloqueos para liberar! Otra información que podría ayudarnos a depurar esto: syz-executor011/3597 no tiene bloqueos. ... Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_unlock_imbalance_bug include/trace/events/lock.h:58 [en línea] __lock_release kernel/locking/lockdep.c:5306 [en línea] lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657 __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900 rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561 sock_sendmsg_nosec net/socket.c:704 [en línea] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae [Gracias a Hawkins Jiawei y Khalid Masum por sus intentos de solucionar este problema]
Vulnerabilidad en kernel de Linux (CVE-2022-49999)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de corrupción de caché de espacio y posibles asignaciones dobles. Al probar space_cache v2 en un conjunto grande de máquinas, encontramos algunos síntomas: 1. Errores "no se puede agregar espacio libre :-17" (EEXIST). 2. Falta de información de espacio libre, a veces detectados con el error "falta información de espacio libre para X". 3. Espacio contabilizado dos veces: rangos asignados en el árbol de extensiones y marcados como libres en dicho árbol, rangos marcados como asignados dos veces en el árbol de extensiones o rangos marcados como libres dos veces en dicho árbol. Si estos últimos se almacenaban en el disco, el siguiente reinicio generaría el error BUG_ON() en add_new_free_space(). 4. En algunos hosts sin corrupción en disco ni mensajes de error, la caché de espacio en memoria (volcada con drgn) no coincidía con el árbol de espacio libre. Todos estos síntomas tienen la misma causa subyacente: una competencia entre el almacenamiento en caché del espacio libre de un grupo de bloques y su devolución a la caché de espacio en memoria para las extensiones fijadas provoca la duplicación de un rango libre en la caché de espacio. Esta competencia se produce cuando se almacena en caché el espacio libre del árbol de espacio libre (space_cache=v2) o del árbol de extensiones (nospace_cache, o space_cache=v1 si es necesario regenerar la caché). Se supone que struct btrfs_block_group::last_byte_to_unpin y struct btrfs_block_group::progress protegen contra esta competencia, pero el commit d0c2f4fa555e ("btrfs: hacer que las sincronizaciones simultáneas esperen menos al esperar el commit de una transacción") interrumpió esto sutilmente al permitir que varias transacciones desanclaran extensiones simultáneamente. Específicamente, la ejecución es la siguiente: 1. Se elimina una extensión de un grupo de bloques no almacenados en caché en la transacción A. 2. Se llama a btrfs_commit_transaction() para la transacción A. 3. btrfs_run_delayed_refs() -> __btrfs_free_extent() ejecuta la referencia retrasada para la extensión eliminada. 4. __btrfs_free_extent() -> do_free_extent_accounting() -> add_to_free_space_tree() agrega la extensión eliminada nuevamente al árbol de espacio libre. 5. do_free_extent_accounting() -> btrfs_update_block_group() -> btrfs_cache_block_group() pone en cola el grupo de bloques para almacenar en caché. block_group->progress se establece en block_group->start. 6. btrfs_commit_transaction() para la transacción A llama a switch_commit_roots(). Establece block_group->last_byte_to_unpin en block_group->progress, que es block_group->start porque el grupo de bloques aún no se ha almacenado en caché. 7. El hilo de caché accede a nuestro grupo de bloques. Dado que las raíces de las confirmaciones ya se han cambiado, load_free_space_tree() detecta la extensión eliminada como libre y la añade a la caché de espacio. Finaliza el almacenamiento en caché y establece block_group->progress en U64_MAX. 8. btrfs_commit_transaction() avanza la transacción A a TRANS_STATE_SUPER_COMMITTED. 9. fsync llama a btrfs_commit_transaction() para la transacción B. Dado que la transacción A ya está en TRANS_STATE_SUPER_COMMITTED y el commit es para fsync, avanza. 10. btrfs_commit_transaction() para la transacción B llama a switch_commit_roots(). Esta vez, el grupo de bloques ya se ha almacenado en caché, por lo que establece block_group->last_byte_to_unpin en U64_MAX. 11. btrfs_commit_transaction() para la transacción A llama a btrfs_finish_extent_commit(), que llama a unpin_extent_range() para la extensión eliminada. Ve que last_byte_to_unpin está establecido en U64_MAX (¡por la transacción B!), por lo que vuelve a añadir la extensión eliminada a la caché de espacio. Esto explica todos nuestros síntomas anteriores: * Si la secuencia de eventos es exactamente la descrita anteriormente, cuando se vuelve a añadir el espacio libre en el paso 11, fallará con EEXIST. * ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2022-50000)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: flowtable: arreglo de flujos atascados en la limpieza debido a trabajo pendiente Para limpiar la tabla de flujo cuando está libre, normalmente ocurre la siguiente secuencia en orden: 1) Se detiene el trabajo de gc_step para deshabilitar cualquier solicitud de estadísticas/del. 2) Todas las entradas de la tabla de flujo se establecen en estado de desmontaje. 3) Se ejecuta gc_step, que pondrá en cola el trabajo de del de HW para cada entrada de la tabla de flujo. 4) Se espera a que finalice el trabajo del del anterior (vaciado). 5) Se vuelve a ejecutar gc_step, eliminando todas las entradas de la tabla de flujo. 6) Se libera la tabla de flujo. Pero si una entrada de la tabla de flujo ya tiene estadísticas de HW pendientes o trabajo de adición de HW, el paso 3 no pondrá en cola el trabajo de del de HW (se omitirá), el paso 4 esperará a que finalicen las adiciones/estadísticas pendientes y el paso 5 pondrá en cola el trabajo de del de HW que podría ejecutarse después de liberar la tabla de flujo. Para solucionar lo anterior, este parche limpia el trabajo pendiente, luego establece el indicador de desmontaje en todos los flujos en la tabla de flujo y fuerza la ejecución de un recolector de basura para poner en cola el trabajo para eliminar los flujos del hardware, luego limpia este nuevo trabajo pendiente y (finalmente) fuerza la ejecución de otro recolector de basura para eliminar la entrada de la tabla de flujo del software. Rastreo de pila: [47773.882335] ERROR: KASAN: Use-After-Free en down_read+0x99/0x460 [47773.883634] Escritura de tamaño 8 en la dirección ffff888103b45aa8 por la tarea kworker/u20:6/543704 [47773.885634] CPU: 3 PID: 543704 Comm: kworker/u20:6 No contaminado 5.12.0-rc7+ #2 [47773.886745] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009) [47773.888438] Cola de trabajo: nf_ft_offload_del flow_offload_work_handler [nf_flow_table] [47773.889727] Rastreo de llamadas: [47773.890214] dump_stack+0xbb/0x107 [47773.890818] print_address_description.constprop.0+0x18/0x140 [47773.892990] kasan_report.cold+0x7c/0xd8 [47773.894459] kasan_check_range+0x145/0x1a0 [47773.895174] down_read+0x99/0x460 [47773.899706] nf_flow_offload_tuple+0x24f/0x3c0 [nf_flow_table] [47773.907137] flow_offload_work_handler+0x72d/0xbe0 [nf_flow_table] [47773.913372] process_one_work+0x8ac/0x14e0 [47773.921325] [47773.921325] Allocated by task 592159: [47773.922031] kasan_save_stack+0x1b/0x40 [47773.922730] __kasan_kmalloc+0x7a/0x90 [47773.923411] tcf_ct_flow_table_get+0x3cb/0x1230 [act_ct] [47773.924363] tcf_ct_init+0x71c/0x1156 [act_ct] [47773.925207] tcf_action_init_1+0x45b/0x700 [47773.925987] tcf_action_init+0x453/0x6b0 [47773.926692] tcf_exts_validate+0x3d0/0x600 [47773.927419] fl_change+0x757/0x4a51 [cls_flower] [47773.928227] tc_new_tfilter+0x89a/0x2070 [47773.936652] [47773.936652] Freed by task 543704: [47773.937303] kasan_save_stack+0x1b/0x40 [47773.938039] kasan_set_track+0x1c/0x30 [47773.938731] kasan_set_free_info+0x20/0x30 [47773.939467] __kasan_slab_free+0xe7/0x120 [47773.940194] slab_free_freelist_hook+0x86/0x190 [47773.941038] kfree+0xce/0x3a0 [47773.941644] tcf_ct_flow_table_cleanup_work Descripción del parche original y seguimiento de la pila por Paul Blakey.
Vulnerabilidad en kernel de Linux (CVE-2022-50001)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_tproxy: restricción al gancho de preenrutamiento. TPROXY solo se permite desde el preenrutamiento, pero nft_tproxy no lo comprueba. Esto corrige un fallo (desreferencia nula) al usar tproxy desde la salida, por ejemplo.
Vulnerabilidad en kernel de Linux (CVE-2022-50002)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: LAG, corregir la lógica sobre MLX5_LAG_FLAG_NDEVS_READY Solo establezca MLX5_LAG_FLAG_NDEVS_READY si ambos dispositivos de red están registrados. Hacerlo garantiza que tanto ldev->pf[MLX5_LAG_P0].dev como ldev->pf[MLX5_LAG_P1].dev tengan punteros válidos cuando MLX5_LAG_FLAG_NDEVS_READY esté establecido. El problema principal es la asimetría en la configuración de MLX5_LAG_FLAG_NDEVS_READY y su borrado. La configuración se realiza incorrectamente cuando tanto ldev->pf[MLX5_LAG_P0].dev como ldev->pf[MLX5_LAG_P1].dev están establecidos; Se borra correctamente cuando se borra ldev->pf[i].netdev. Considere el siguiente escenario: 1. PF0 carga y asigna un puntero válido a ldev->pf[MLX5_LAG_P0].dev. 2. PF1 carga y asigna punteros válidos a ldev->pf[MLX5_LAG_P1].dev y ldev->pf[MLX5_LAG_P1].netdev. Esto da como resultado que MLX5_LAG_FLAG_NDEVS_READY se configure. 3. PF0 se descarga antes de asignar dev->pf[MLX5_LAG_P0].netdev. MLX5_LAG_FLAG_NDEVS_READY permanece configurado. La ejecución posterior de mlx5_do_bond() dará como resultado una desreferencia de puntero nulo al llamar a mlx5_lag_is_multipath(). Este parche corrige el siguiente seguimiento de llamada encontrado: [ 1293.475195] ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000009a8 [ 1293.478756] #PF: acceso de lectura del supervisor en modo kernel [ 1293.481320] #PF: error_code(0x0000) - página no presente [ 1293.483686] PGD 0 P4D 0 [ 1293.484434] Oops: 0000 [#1] SMP PTI [ 1293.485377] CPU: 1 PID: 23690 Comm: kworker/u16:2 No contaminado 5.18.0-rc5_for_upstream_min_debug_2022_05_05_10_13 #1 [ 1293.488039] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 [ 1293.490836] Cola de trabajo: mlx5_lag mlx5_do_bond_work [mlx5_core] [ 1293.492448] RIP: 0010:mlx5_lag_is_multipath+0x5/0x50 [mlx5_core] [ 1293.494044] Código: e8 70 40 ff e0 48 8b 14 24 48 83 05 5c 1a 1b 00 01 e9 19 ff ff ff 48 83 05 47 1a 1b 00 01 eb d7 0f 1f 44 00 00 0f 1f 44 00 00 <48> 8b 87 a8 09 00 00 48 85 c0 74 26 48 83 05 a7 1b 1b 00 01 41 b8 [ 1293.498673] RSP: 0018:ffff88811b2fbe40 EFLAGS: 00010202 [ 1293.500152] RAX: ffff88818a94e1c0 RBX: ffff888165eca6c0 RCX: 0000000000000000 [ 1293.501841] RDX: 0000000000000001 RSI: ffff88818a94e1c0 RDI: 0000000000000000 [ 1293.503585] RBP: 0000000000000000 R08: ffff888119886740 R09: ffff888165eca73c [ 1293.505286] R10: 0000000000000018 R11: 0000000000000018 R12: ffff88818a94e1c0 [ 1293.506979] R13: ffff888112729800 R14: 0000000000000000 R15: ffff888112729858 [ 1293.508753] FS: 000000000000000(0000) GS:ffff88852cc40000(0000) knlGS:0000000000000000 [ 1293.510782] CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 [ 1293.512265] CR2: 00000000000009a8 CR3: 00000001032d4002 CR4: 0000000000370ea0 [ 1293.514001] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1293.515806] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Vulnerabilidad en kernel de Linux (CVE-2022-50003)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: xsk: prohibir el uso de un id de cola no balanceado Corrija el siguiente escenario: 1. ethtool -L $IFACE rx 8 tx 96 2. xdpsock -q 10 -t -z Lo anterior se refiere a un caso en el que el usuario desea adjuntar un socket XSK en modo txonly a un id de cola que no tiene una cola Rx correspondiente. En este momento, la lógica XSK de ice está estrechamente ligada a actuar en un "par de colas", por ejemplo, las colas Tx y Rx en un id de cola dado están deshabilitadas/habilitadas y a ambas se les asignará un grupo XSK, lo cual no funciona para la configuración de cola presentada. Esto da como resultado el splat incluido en la parte inferior, que es básicamente un acceso OOB a la matriz de anillo Rx. Para solucionar esto, permita el uso de los id solo en el ámbito de las colas "combinadas" reportadas por ethtool. Sin embargo, la lógica debe reescribirse para permitir tales configuraciones más adelante, lo que terminaría como una reescritura completa de la ruta de control, así que sigamos con esta solución temporal. [420160.558008] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000082 [420160.566359] #PF: acceso de lectura del supervisor en modo kernel [420160.572657] #PF: error_code(0x0000) - página no presente [420160.579002] PGD 0 P4D 0 [420160.582756] Oops: 0000 [#1] PREEMPT SMP NOPTI [420160.588396] CPU: 10 PID: 21232 Comm: xdpsock Tainted: G OE 5.19.0-rc7+ #10 [420160.597893] Nombre del hardware: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 19/03/2019 [420160.609894] RIP: 0010:ice_xsk_pool_setup+0x44/0x7d0 [ice] [420160.616968] Código: f3 48 83 ec 40 48 8b 4f 20 48 8b 3f 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 48 8d 04 ed 00 00 00 00 48 01 c1 48 8b 11 <0f> b7 92 82 00 00 00 48 85 d2 0f 84 2d 75 00 00 48 8d 72 ff 48 85 [420160.639421] RSP: 0018:ffffc9002d2afd48 EFLAGS: 00010282 [420160.646650] RAX: 0000000000000050 RBX: ffff88811d8bdd00 RCX: ffff888112c14ff8 [420160.655893] RDX: 000000000000000 RSI: ffff88811d8bdd00 RDI: ffff888109861000 [420160.665166] RBP: 000000000000000a R08: 000000000000000a R09: 0000000000000000 [420160.674493] R10: 000000000000889f R11: 0000000000000000 R12: 000000000000000a [420160.683833] R13: 00000000000000a R14: 0000000000000000 R15: ffff888117611828 [420160.693211] FS: 00007fa869fc1f80(0000) GS:ffff8897e0880000(0000) knlGS:0000000000000000 [420160.703645] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [420160.711783] CR2: 000000000000082 CR3: 00000001d076c001 CR4: 00000000007706e0 [420160.721399] DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [420160.731045] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [420160.740707] PKRU: 55555554 [420160.745960] Rastreo de llamadas: [420160.750962] [420160.755597] ? kmalloc_large_node+0x79/0x90 [420160.762703] ? __kmalloc_node+0x3f5/0x4b0 [420160.769341] xp_assign_dev+0xfd/0x210 [420160.775661] ? shmem_file_read_iter+0x29a/0x420 [420160.782896] xsk_bind+0x152/0x490 [420160.788943] __sys_bind+0xd0/0x100 [420160.795097] ? exit_to_user_mode_prepare+0x20/0x120 [420160.802801] __x64_sys_bind+0x16/0x20 [420160.809298] do_syscall_64+0x38/0x90 [420160.815741] entry_SYSCALL_64_after_hwframe+0x63/0xcd [420160.823731] RIP: 0033:0x7fa86a0dd2fb [420160.830264] Code: c3 66 0f 1f 44 00 00 48 8b 15 69 8b 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bc 0f 1f 44 00 00 f3 0f 1e fa b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 8b 0c 00 f7 d8 64 89 01 48 [420160.855410] RSP: 002b:00007ffc1146f618 EFLAGS: 00000246 ORIG_RAX: 0000000000000031 [420160.866366] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa86a0dd2fb [420160.876957] RDX: 0000000000000010 RSI: 00007ffc1146f680 RDI: 0000000000000003 [420160.887604] RBP: 000055d7113a0520 R08: 00007fa868fb8000 R09: 0000000080000000 [420160.898293] R10: 0000000000008001 R11: 0000000000000246 R12: 000055d7113a04e0 [420160.909038] R13: 000055d7113a0320 R14: 000000000000000a R15: 0000000000000000 [420160.91 ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2022-50004)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: política: corregir la desreferencia de puntero nulo de metadatos dst->dev xmit Cuando intentamos transmitir un skb con metadata_dst adjunto (es decir, dst->dev == NULL) a través de la interfaz xfrm, podemos alcanzar una desreferencia de puntero nulo[1] en xfrmi_xmit2() -> xfrm_lookup_with_ifid() debido a la comprobación de un dispositivo skb de bucle invertido cuando no hay ninguna política que desreferencia dst->dev incondicionalmente. No tener dst->dev puede interpretarse como que no es un dispositivo de bucle invertido, así que simplemente agregue una comprobación para un dst_orig->dev nulo. Con esta corrección, los contadores de errores de Tx de la interfaz xfrm suben como de costumbre. [1] net-next calltrace capturado a través de netconsole: ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000000c0 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 1 PID: 7231 Comm: ping Kdump: cargado No contaminado 5.19.0+ #24 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-1.fc36 04/01/2014 RIP: 0010:xfrm_lookup_with_ifid+0x5eb/0xa60 Código: 8d 74 24 38 e8 26 a4 37 00 48 89 c1 e9 12 fc ff ff 49 63 ed 41 83 fd ser 0f 85 ser 01 00 00 41 ser ff ff ff ff 45 31 ed 48 8b 03 80 c0 00 00 00 08 75 0f 41 80 bc 24 19 0d 00 00 01 0f 84 1e 02 RSP: 0018:ffffb0db82c679f0 EFLAGS: 00010246 RAX: 000000000000000 RBX: ffffd0db7fcad430 RCX: ffffb0db82c67a10 RDX: 00000000000000000 RSI: 0000000000000000 RDI: ffffb0db82c67a80 RBP: ffffb0db82c67a80 R08: ffffb0db82c67a14 R09: 0000000000000000 R10: 0000000000000000 R11: ffff8fa449667dc8 R12: ffffffff966db880 R13: 000000000000000 R14: 00000000ffffffff R15: 000000000000000 FS: 00007ff35c83f000(0000) GS:ffff8fa478480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000c0 CR3: 000000001ebb7000 CR4: 0000000000350ee0 Seguimiento de llamadas: xfrmi_xmit+0xde/0x460 ? tcf_bpf_act+0x13d/0x2a0 dev_hard_start_xmit+0x72/0x1e0 __dev_queue_xmit+0x251/0xd30 ip_finish_output2+0x140/0x550 ip_push_pending_frames+0x56/0x80 raw_sendmsg+0x663/0x10a0 ? try_charge_memcg+0x3fd/0x7a0 ? __mod_memcg_lruvec_state+0x93/0x110 ? sock_sendmsg+0x30/0x40 sock_sendmsg+0x30/0x40 __sys_sendto+0xeb/0x130 ? manejar_mm_fault+0xae/0x280 ? hacer_dirección_usuario_fault+0x1e7/0x680 ? kvm_read_and_reset_apf_flags+0x3b/0x50 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7ff35cac1366 Código: eb 0b 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff ff eb b8 0f 1f 00 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 72 c3 90 55 48 83 ec 30 44 89 4c 24 2c 4c 89 RSP: 002b:00007fff738e4028 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007fff738e57b0 RCX: 00007ff35cac1366 RDX: 0000000000000040 RSI: 0000557164e4b450 RDI: 0000000000000003 RBP: 0000557164e4b450 R08: 00007fff738e7a2c R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040 R13: 00007fff738e5770 R14: 00007fff738e4030 R15: 0000001d00000001 Módulos vinculados en: netconsole veth br_netfilter bridge bonding virtio_net [última descarga: netconsole] CR2: 00000000000000c0
Vulnerabilidad en kernel de Linux (CVE-2022-50005)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: pn533: Se corrigen los errores de Use-After-Free causados por pn532_cmd_timeout. Cuando se desconecta el dispositivo uart pn532, se llama a pn532_uart_remove(). Sin embargo, no hay funciones en pn532_uart_remove() que puedan eliminar el temporizador cmd_timeout, lo que causaría errores de Use-After-Free. El proceso se muestra a continuación: (hilo 1) | (hilo 2) | pn532_uart_send_frame pn532_uart_remove | mod_timer(&pn532->cmd_timeout,...) ... | (esperar un tiempo) kfree(pn532) //FREE | pn532_cmd_timeout | pn532_uart_send_frame | pn532->... //USE Este parche añade del_timer_sync() a pn532_uart_remove() para evitar errores de Use-After-Free. Además, pn53x_unregister_nfc() está bien sincronizado, establece nfc_dev->shutting_down como verdadero y ninguna llamada al sistema podría reiniciar el temporizador cmd_timeout.
Vulnerabilidad en kernel de Linux (CVE-2022-50006)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4.2 corrige problemas con __nfs42_ssc_open. Al realizar una copia, un servidor de destino no debería aceptar el identificador de archivo proporcionado si no es un identificador de archivo normal. Si alloc_file_pseudo() falla, debemos decrementar una referencia en el inodo recién creado; de lo contrario, se produce una fuga.
Vulnerabilidad en kernel de Linux (CVE-2022-50007)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: se corrige una fuga de referencias en __xfrm_policy_check(). El problema ocurre en una ruta de error en __xfrm_policy_check(). Cuando falla la obtención del objeto `pols[1]`, la función simplemente devuelve 0, olvidando decrementar el recuento de referencias de `pols[0]`, que se incrementa previamente mediante xfrm_sk_policy_lookup() o xfrm_policy_lookup(). Esto puede provocar fugas de memoria. Para solucionarlo, reduzca el recuento de referencias de `pols[0]` en esa ruta.
Vulnerabilidad en kernel de Linux (CVE-2022-50008)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kprobes: no llamar a disarm_kprobe() para kprobes deshabilitados. La suposición en __disable_kprobe() es errónea, y podría intentar desarmar un kprobe ya desarmado y ejecutar el comando WARN_ONCE() a continuación. [0] Podemos reproducir fácilmente este problema. 1. Escriba 0 en /sys/kernel/debug/kprobes/enabled. # echo 0 > /sys/kernel/debug/kprobes/enabled 2. Ejecute execsnoop. En este momento, un kprobe está deshabilitado. # /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE] 3. Escriba 1 en /sys/kernel/debug/kprobes/enabled, lo cual cambia kprobes_all_disarmed a falso pero no arma el kprobe deshabilitado. # echo 1 > /sys/kernel/debug/kprobes/enabled # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DESHABILITADO][FTRACE] 4. Matar execsnoop, cuando __disable_kprobe() llama a disarm_kprobe() para el kprobe deshabilitado y llega a WARN_ONCE() en __disarm_kprobe_ftrace(). # fg /usr/share/bcc/tools/execsnoop ^C En realidad, WARN_ONCE() se dispara dos veces, y __unregister_kprobe_top() pierde algunas limpiezas y deja el kprobe agregado en la tabla hash. Luego, __unregister_trace_kprobe() inicializa tk->rp.kp.list y crea un bucle infinito como este: addedd kprobe.list -> kprobe.list -. ^ | '.__.' En esta situación, estos comandos caen en el bucle infinito y provocan una parada o un bloqueo suave de la RCU. cat /sys/kernel/debug/kprobes/list : show_kprobe_addr() entra en el bucle infinito con la RCU. /usr/share/bcc/tools/execsnoop : warn_kprobe_rereg() contiene kprobe_mutex, y __get_valid_kprobe() queda atascado en el bucle. Para evitar este problema, asegúrese de no llamar a disarm_kprobe() para las kprobes deshabilitadas. [0] No se pudo desarmar kprobe-ftrace en __x64_sys_execve+0x0/0x40 (error -2) ADVERTENCIA: CPU: 6 PID: 2460 en kernel/kprobes.c:1130 __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Módulos vinculados: ena CPU: 6 PID: 2460 Comm: execsnoop No contaminado 5.19.0+ #28 Nombre del hardware: Amazon EC2 c5.2xlarge/, BIOS 1.0 16/10/2017 RIP: 0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Código: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94 RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001 RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff RBP: ffff89c504286da8 R08: 000000000000000 R09: c0000000fffeffff R10: 000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40 R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 000000000000000 FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000000400 PKRU: 55555554 Seguimiento de llamadas: __disable_kprobe (kernel/kprobes.c:1716) disable_kprobe (kernel/kprobes.c:2392) __disable_trace_kprobe (kernel/trace/trace_kprobe.c:340) disable_trace_kprobe (kernel/trace/trace_kprobe.c:429) perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168) perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295) _free_event (kernel/events/core.c:4971) perf_event_release_kernel (kernel/events/core.c:5176) perf_release (kernel/events/core.c:5186) __fput (fs/file_table.c:321) task_work_run (./include/linux/---truncado---
Vulnerabilidad en kernel de Linux (CVE-2022-50009)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrige null-ptr-deref en f2fs_get_dnode_of_data Hay un problema como el siguiente cuando se prueba la escritura atómica de f2fs: F2FS-fs (loop0): No se puede encontrar un sistema de archivos F2FS válido en el 2.º superbloque F2FS-fs (loop0): crc_offset no válido: 0 F2FS-fs (loop0): f2fs_check_nid_range: nid fuera de rango = 1, ejecute fsck para corregirlo. F2FS-fs (loop0): f2fs_check_nid_range: nid fuera de rango = 2, ejecute fsck para corregirlo. ======================================================================= ERROR: KASAN: null-ptr-deref en f2fs_get_dnode_of_data+0xac/0x16d0 Lectura de tamaño 8 en la dirección 000000000000028 por la tarea rep/1990 CPU: 4 PID: 1990 Comm: rep No contaminado 5.19.0-rc6-next-20220715 #266 Rastreo de llamadas: dump_stack_lvl+0x6e/0x91 print_report.cold+0x49a/0x6bb kasan_report+0xa8/0x130 f2fs_get_dnode_of_data+0xac/0x16d0 f2fs_do_write_data_page+0x2a5/0x1030 move_data_page+0x3c5/0xdf0 do_garbage_collect+0x2015/0x36c0 f2fs_gc+0x554/0x1d30 f2fs_balance_fs+0x7f5/0xda0 f2fs_write_single_data_page+0xb66/0xdc0 f2fs_write_cache_pages+0x716/0x1420 f2fs_write_data_pages+0x84f/0x9a0 do_writepages+0x130/0x3a0 filemap_fdatawrite_wbc+0x87/0xa0 file_write_and_wait_range+0x157/0x1c0 f2fs_do_sync_file+0x206/0x12d0 f2fs_sync_file+0x99/0xc0 vfs_fsync_range+0x75/0x140 f2fs_file_write_iter+0xd7b/0x1850 vfs_write+0x645/0x780 ksys_write+0xf1/0x1e0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Como el commit 3db1de0e582c cambió la forma de escritura atómica que ahora es un cow_inode para el archivo de escritura atómica, y también marca cow_inode como FI_ATOMIC_FILE. Al escribir en f2fs_do_write_data_page, cow_inode usará el valor nulo de cow_inode. Esto activará null-ptr-deref. Para solucionar el problema, introduzca el indicador FI_COW_FILE para el inodo COW. Fiexes: 3db1de0e582c("f2fs: cambiar la ruta de escritura atómica actual")
Vulnerabilidad en kernel de Linux (CVE-2022-50010)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: i740fb: Comprobación del argumento de i740_calc_vclk(). Dado que el usuario puede controlar los argumentos de ioctl() desde el espacio de usuario, bajo argumentos especiales, esto puede provocar un error de división por cero. Si el usuario proporciona un valor de 'pixclock' incorrecto que hace que el argumento de i740_calc_vclk() sea menor que 'I740_RFREQ_FIX', se producirá un error de división por cero en: drivers/video/fbdev/i740fb.c:353 p_best = min(15, ilog2(I740_MAX_VCO_FREQ / (freq / I740_RFREQ_FIX))); El siguiente registro puede revelarlo: error de división: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:i740_calc_vclk drivers/video/fbdev/i740fb.c:353 [en línea] RIP: 0010:i740fb_decode_var drivers/video/fbdev/i740fb.c:646 [en línea] RIP: 0010:i740fb_set_par+0x163f/0x3b70 drivers/video/fbdev/i740fb.c:742 Seguimiento de llamadas: fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Solucione esto verificando primero el argumento de i740_calc_vclk().
Vulnerabilidad en kernel de Linux (CVE-2022-50011)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: venus: pm_helpers: Se corrige la advertencia en OPP durante el sondeo Se corrige el siguiente WARN activado durante el sondeo del controlador Venus en 5.19.0-rc8-next-20220728: ADVERTENCIA: CPU: 7 PID: 339 en drivers/opp/core.c:2471 dev_pm_opp_set_config+0x49c/0x610 Módulos vinculados en: qcom_spmi_adc5 rtc_pm8xxx qcom_spmi_adc_tm5 leds_qcom_lpg led_class_multicolor qcom_pon qcom_vadc_common venus_core(+) qcom_spmi_temp_alarm v4l2_mem2mem videobuf2_v4l2 msm(+) videobuf2_common crct10dif_ce spi_geni_qcom snd_soc_sm8250 i2c_qcom_geni gpu_sched snd_soc_qcom_common videodev qcom_q6v5_pas soundwire_qcom drm_dp_aux_bus qcom_stats drm_display_helper qcom_pil_info soundwire_bus snd_soc_lpass_va_macro mc qcom_q6v5 phy_qcom_snps_femto_v2 qcom_rng snd_soc_lpass_macro_common snd_soc_lpass_wsa_macro lpass_gfm_sm8250 slimbus qcom_sysmon qcom_common qcom_glink_smem qmi_helpers qcom_wdt mdt_loader socinfo icc_osm_l3 display_connector drm_kms_helper qnoc_sm8250 drm fuse ip_tables x_tables ipv6 CPU: 7 PID: 339 Comm: systemd-udevd No contaminado 5.19.0-rc8-next-20220728 #4 Nombre del hardware: Qualcomm Technologies, Inc. Robotics RB5 (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : dev_pm_opp_set_config+0x49c/0x610 lr : dev_pm_opp_set_config+0x58/0x610 sp : ffff8000093c3710 x29: ffff8000093c3710 x28: ffffbca3959d82b8 x27: ffff8000093c3d00 x26: ffffbca3959d8e08 x25: ffff4396cac98118 x24: ffff4396c0e24810 x23: ffff4396c4272c40 x22: ffff4396c0e24810 x21: ffff8000093c3810 x20: ffff4396cac36800 x19: ffff4396cac96800 x18: 0000000000000000 x17: 0000000000000003 x16: ffffbca3f4edf198 x15: 0000001cba64a858 x14: 0000000000000180 x13: 000000000000017e x12: 0000000000000000 x11: 0000000000000002 x10: 0000000000000a60 x9: ffff8000093c35c0 x8: ffff4396c4273700 x7: ffff43983efca6c0 x6: ffff43983efca640 x5: 00000000410fd0d0 x4: ffff4396c4272c40 x3: ffffbca3f5d1e008 x2: 00000000000000000 x1 : ffff4396c2421600 x0 : ffff4396cac96860 Rastreo de llamadas: dev_pm_opp_set_config+0x49c/0x610 devm_pm_opp_set_config+0x18/0x70 vcodec_domains_get+0xb8/0x1638 [venus_core] core_get_v4+0x1d8/0x218 [venus_core] venus_probe+0xf4/0x468 [venus_core] platform_probe+0x68/0xd8 really_probe+0xbc/0x2a8 __driver_probe_device+0x78/0xe0 driver_probe_device+0x3c/0xf0 __driver_attach+0x70/0x120 bus_for_each_dev+0x70/0xc0 driver_attach+0x24/0x30 bus_add_driver+0x150/0x200 driver_register+0x64/0x120 __platform_driver_register+0x28/0x38 qcom_venus_driver_init+0x24/0x1000 [venus_core] do_one_initcall+0x54/0x1c8 do_init_module+0x44/0x1d0 load_module+0x16c8/0x1aa0 __do_sys_finit_module+0xbc/0x110 __arm64_sys_finit_module+0x20/0x30 invoke_syscall+0x44/0x108 el0_svc_common.constprop.0+0xcc/0xf0 do_el0_svc+0x2c/0xb8 el0_svc+0x2c/0x88 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x18c/0x190 qcom-venus: probe of aa00000.video-codec failed with error -16. La solución consiste en reordenar el código relacionado con el núcleo OPP. El núcleo OPP espera que se proporcionen todas las opciones de configuración antes de agregar la tabla OPP.
Vulnerabilidad en kernel de Linux (CVE-2022-50012)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/64: Inicializar etiquetas de salto antes de parse_early_param() En 64 bits, llamar a jump_label_init() en setup_feature_keys() es demasiado tarde porque las claves estáticas se pueden usar en subrutinas de parse_early_param(), que a su vez es una subrutina de early_init_devtree(). Por ejemplo, al arrancar con "threadirqs": static_key_enable_cpuslocked(): clave estática '0xc000000002953260' usada antes de llamar a jump_label_init() ADVERTENCIA: CPU: 0 PID: 0 en kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120 ... NIP static_key_enable_cpuslocked+0xfc/0x120 LR static_key_enable_cpuslocked+0xf8/0x120 Rastreo de llamadas: static_key_enable_cpuslocked+0xf8/0x120 (no confiable) static_key_enable+0x30/0x50 setup_forced_irqthreads+0x28/0x40 do_early_param+0xa0/0x108 parse_args+0x290/0x4e0 parse_early_options+0x48/0x5c parse_early_param+0x58/0x84 early_init_devtree+0xd4/0x518 early_setup+0xb4/0x214 Por lo tanto, llame a jump_label_init() justo antes de parse_early_param() en early_init_devtree(). [mpe: Agregar seguimiento de llamadas al registro de cambios y ediciones menores de redacción].
Vulnerabilidad en kernel de Linux (CVE-2022-50013)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar el uso de f2fs_bug_on() en f2fs_new_node_page() Como informó Dipanjan Das , syzkaller encontró un error de f2fs como el siguiente: RIP: 0010:f2fs_new_node_page+0x19ac/0x1fc0 fs/f2fs/node.c:1295 Seguimiento de llamadas: write_all_xattrs fs/f2fs/xattr.c:487 [en línea] __f2fs_setxattr+0xe76/0x2e10 fs/f2fs/xattr.c:743 f2fs_setxattr+0x233/0xab0 fs/f2fs/xattr.c:790 f2fs_xattr_generic_set+0x133/0x170 fs/f2fs/xattr.c:86 __vfs_setxattr+0x115/0x180 fs/xattr.c:182 __vfs_setxattr_noperm+0x125/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1cf/0x260 fs/xattr.c:277 vfs_setxattr+0x13f/0x330 fs/xattr.c:303 setxattr+0x146/0x160 fs/xattr.c:611 path_setxattr+0x1a7/0x1d0 fs/xattr.c:630 __do_sys_lsetxattr fs/xattr.c:653 [en línea] __se_sys_lsetxattr fs/xattr.c:649 [en línea] __x64_sys_lsetxattr+0xbd/0x150 fs/xattr.c:649 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 La entrada NAT y el mapa de bits NAT pueden ser inconsistentes, por ejemplo, un nid está libre en el mapa de bits NAT y blkaddr en su entrada NAT no es NULL_ADDR, puede activar BUG_ON() en f2fs_new_node_page(), arréglelo.
Vulnerabilidad en kernel de Linux (CVE-2022-50014)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/gup: corregir el problema de seguridad de FOLL_FORCE COW y eliminar FOLL_COW Desde que ocurrió el problema de seguridad Dirty COW (CVE-2016-5195), sabemos que FOLL_FORCE puede ser posiblemente peligroso, especialmente si hay ejecuciones que pueden ser explotadas por el espacio de usuario. En este momento, sería suficiente tener algún código que establezca un PTE de una página compartida asignada a R/O sucia, para que FOLL_FORCE pueda escribir en ella por error. Las implicaciones de establecer una PTE protegida contra escritura sucia podrían no ser inmediatamente obvias para todos. Y de hecho, desde el commit 9ae0f87d009c ("mm/shmem: establecer un pte sucio incondicionalmente en mfill_atomic_install_pte"), podemos usar UFFDIO_CONTINUE para asignar una página shmem R/O mientras se marca el pte sucio. Esto puede ser usado por usuarios sin privilegios para modificar el contenido de archivos tmpfs/shmem incluso si no tienen permisos de escritura, y para evitar el sellado de escritura de memfd (COW sucio restringido a tmpfs/shmem [CVE-2022-2590]). Para solucionar definitivamente estos problemas de seguridad, la clave es que solo necesitamos esa lógica de reintento sofisticada (FOLL_COW) para las asignaciones de COW que no permiten escritura (!VM_WRITE). En una asignación de COW, solo se interrumpe si se asigna una página anónima exclusiva. Si se asigna otra cosa, o si la página anónima asignada puede ser compartida (!PageAnonExclusive), se debe generar un fallo de escritura para interrumpir COW. Si no se encuentra una página anónima exclusiva al reintentar, se debe activar la interrupción de COW de nuevo porque algo intervino. Dejemos de lado este manejo de reintentos obligatorios y errores de escritura y utilicemos nuestra bandera PageAnonExclusive() para tomar una decisión similar y usar la misma lógica de COW que en otras partes del kernel. Si encontramos una PTE en una asignación de COW que no asigne una página anónima exclusiva, COW no se rompió correctamente y debemos generar un falso fallo de escritura para romperlo. Al igual que en can_change_pte_writable(), añadido mediante el commit 64fe24a3e05e ("mm/mprotect: intentar evitar errores de escritura en páginas anónimas exclusivas al cambiar la protección") y el commit 76aefad628aa ("mm/mprotect: corregir la comprobación de errores de escritura en can_change_pte_writable()"), nos encargamos de los errores de escritura y uffd-wp manualmente. Por ejemplo, una escritura (write()) mediante /proc/self/mem a un rango protegido por uffd-wp debe fallar en lugar de conceder acceso de escritura silenciosamente y omitir el controlador de errores del espacio de usuario. Tenga en cuenta que FOLL_FORCE no solo se usa para el acceso de depuración, sino que también lo activan aplicaciones sin intenciones de depuración, por ejemplo, al anclar páginas mediante RDMA. Esto corrige CVE-2022-2590. Tenga en cuenta que solo x86_64 y aarch64 se ven afectados, ya que solo estos admiten CONFIG_HAVE_ARCH_USERFAULTFD_MINOR. Afortunadamente, FOLL_COW ya no es necesario para gestionar FOLL_FORCE. Así que simplemente lo eliminaremos. Gracias a Nadav Amit por señalar que la comprobación pte_dirty() en el código de FOLL_FORCE es problemática y podría ser explotable. Nota 1: No comprobamos si la PTE está sucia porque ya no es relevante para tomar la decisión de "fue COWed", y quien modifique la página debe configurarla como sucia de todos modos. Nota 2: Los kernels anteriores a la compatibilidad extendida con uffd-wp y a PageAnonExclusive (< 5.19) pueden simplemente revertir el commit problemática y estar seguros con respecto a UFFDIO_CONTINUE. Una adaptación a la versión 5.19 requiere ajustes menores debido a la falta de vma_soft_dirty_enabled().
Vulnerabilidad en kernel de Linux (CVE-2022-50015)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: Intel: hda-ipc: No procesar la respuesta de IPC antes del arranque del firmware. Aún no está claro, pero es posible crear un firmware tan defectuoso que envíe un mensaje de respuesta antes de un mensaje FW_READY (aún no se sabe si FW_READY llegará después). Dado que los datos de respuesta se asignan solo después del mensaje FW_READY, esto provocará una desreferencia de puntero nulo si no se filtra. El problema se reportó con el firmware IPC4, pero la misma condición se presenta para IPC3.
Vulnerabilidad en kernel de Linux (CVE-2022-50016)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 14/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: Intel: cnl: No procesar la respuesta de IPC antes del arranque del firmware. Aún no está claro, pero es posible crear un firmware tan defectuoso que envíe un mensaje de respuesta antes de un mensaje FW_READY (aún no se sabe si FW_READY llegará después). Dado que los datos de respuesta se asignan solo después del mensaje FW_READY, esto provocará una desreferencia de puntero nulo si no se filtra. El problema se reportó con el firmware IPC4, pero la misma condición se presenta para IPC3.
Vulnerabilidad en 70mai M300 (CVE-2025-6526)
Severidad: BAJA
Fecha de publicación: 23/06/2025
Fecha de última actualización: 14/11/2025
Se ha detectado una vulnerabilidad clasificada como problemática en 70mai M300 hasta el 20250611. Este problema afecta a un procesamiento desconocido del componente HTTP Server. La manipulación da lugar a credenciales con protección insuficiente. El ataque solo puede realizarse dentro de la red local. Es un ataque de complejidad bastante alta. Parece difícil de explotar. Se ha hecho público el exploit y puede que sea utilizado. Se contactó al proveedor con antelación sobre esta divulgación, pero no respondió.
Vulnerabilidad en 70mai M300 (CVE-2025-6530)
Severidad: MEDIA
Fecha de publicación: 23/06/2025
Fecha de última actualización: 14/11/2025
Se encontró una vulnerabilidad en 70mai M300 hasta el 20250611. Se ha clasificado como problemática. Afecta a una parte desconocida del archivo demo.sh del componente Telnet Service. La manipulación provoca una denegación de servicio. Se requiere acceso a la red local para este ataque. Es un ataque de complejidad bastante alta. Parece difícil de explotar. Se ha hecho público el exploit y puede que sea utilizado. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.