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 el proceso vertica-udx-zygote en HP Vertica (CVE-2015-6867)
Severidad: Pendiente de análisis
Fecha de publicación: 04/11/2015
Fecha de última actualización: 19/11/2025
El proceso vertica-udx-zygote en HP Vertica 7.1.1 UDx no requiere autenticación, lo que permite a atacantes remotos ejecutar comandos arbitrarios a través de un paquete manipulado, también conocido como ZDI-CAN-2914.
Vulnerabilidad en el manejador validateAdminConfig en el Analytics Management Console en HPE Vertica (CVE-2016-2002)
Severidad: CRÍTICA
Fecha de publicación: 20/04/2016
Fecha de última actualización: 19/11/2025
El manejador validateAdminConfig en el Analytics Management Console en HPE Vertica 7.0.x en versiones anteriores a 7.0.2.12, 7.1.x en versiones anteriores a 7.1.2-12 y 7.2.x en versiones anteriores a 7.2.2-1 permite a atacantes remotos ejecutar comandos arbitrarios a través del parámetro mcPort , también conocido como ZDI-CAN-3417.
Vulnerabilidad en HPE Vertica Analytics Platform (CVE-2017-5802)
Severidad: CRÍTICA
Fecha de publicación: 15/02/2018
Fecha de última actualización: 19/11/2025
Se ha encontrado una vulnerabilidad de obtención de acceso privilegiado remoto en HPE Vertica Analytics Platform en versiones v4.1 y posteriores.
Vulnerabilidad en Kashipara Online Exam System v1.0 (CVE-2024-40479)
Severidad: ALTA
Fecha de publicación: 12/08/2024
Fecha de última actualización: 19/11/2025
Una vulnerabilidad de inyección SQL en "/admin/quizquestion.php" en Kashipara Online Exam System v1.0 permite a atacantes remotos ejecutar comandos SQL de su elección a través del parámetro "eid".
Vulnerabilidad en OpenText™ Vertica (CVE-2024-6360)
Severidad: MEDIA
Fecha de publicación: 02/10/2024
Fecha de última actualización: 19/11/2025
La vulnerabilidad de asignación incorrecta de permisos para recursos críticos en OpenText™ Vertica podría permitir el abuso de privilegios y dar como resultado el acceso no autorizado o los privilegios a la clave API del agente de Vertica. Este problema afecta a Vertica: de la versión 10.0 a la 10.X, de la versión 11.0 a la 11.X, de la versión 12.0 a la 12.X, de la versión 23.0 a la 23.X, de la versión 24.0 a la 24.X.
Vulnerabilidad en Directus (CVE-2024-54128)
Severidad: MEDIA
Fecha de publicación: 05/12/2024
Fecha de última actualización: 19/11/2025
Directus es una API en tiempo real y un panel de control de aplicaciones para administrar el contenido de bases de datos SQL. La función de comentarios implementó un filtro para evitar que los usuarios agreguen caracteres restringidos, como etiquetas HTML. Sin embargo, este filtro opera en el lado del cliente, lo que puede eludirse, lo que hace que la aplicación sea vulnerable a la inyección de HTML. Esta vulnerabilidad se solucionó en 10.13.4 y 11.2.0.
Vulnerabilidad en FortiClientMac y FortiVoiceUCDesktop (CVE-2024-35281)
Severidad: BAJA
Fecha de publicación: 13/05/2025
Fecha de última actualización: 19/11/2025
Una vulnerabilidad de aislamiento o compartimentación inadecuada [CWE-653] en la aplicación de escritorio FortiClientMac versión 7.4.2 y anteriores, versión 7.2.8 y anteriores, 7.0 todas las versiones y FortiVoiceUCDesktop 3.0 todas las versiones puede permitir que un atacante autenticado inyecte código a través de variables de entorno de Electron.
Vulnerabilidad en kernel de Linux (CVE-2025-37897)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: plfxlc: Eliminar aserción errónea en plfxlc_mac_release. plfxlc_mac_release() afirma que mac->lock se mantiene. Esta aserción es incorrecta, ya que, incluso si fuera posible, no sería el comportamiento válido. La función se utiliza cuando falla la sonda o después de desconectar el dispositivo. En ambos casos, mac->lock no se puede mantener, ya que el controlador no está trabajando con el dispositivo en ese momento. Todas las funciones que usan mac->lock lo desbloquean justo después de mantenerlo. Tampoco es necesario mantener mac->lock para plfxlc_mac_release(), ya que los datos de mac no se ven afectados, excepto mac->flags, que se modifica automáticamente. Este error genera la siguiente advertencia: ================================================================== ADVERTENCIA: CPU: 0 PID: 127 en drivers/net/wireless/purelifi/plfxlc/mac.c:106 plfxlc_mac_release+0x7d/0xa0 Módulos vinculados: CPU: 0 PID: 127 Comm: kworker/0:2 No contaminado 6.1.124-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Cola de trabajo: usb_hub_wq hub_event RIP: 0010:plfxlc_mac_release+0x7d/0xa0 controladores/red/inalámbrico/purelifi/plfxlc/mac.c:106 Rastreo de llamadas: probe+0x941/0xbd0 drivers/net/wireless/purelifi/plfxlc/usb.c:694 usb_probe_interface+0x5c0/0xaf0 drivers/usb/core/driver.c:396 really_probe+0x2ab/0xcb0 drivers/base/dd.c:639 __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785 driver_probe_device+0x50/0x420 drivers/base/dd.c:815 __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943 bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429 __device_attach+0x359/0x570 drivers/base/dd.c:1015 bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489 device_add+0xb48/0xfd0 drivers/base/core.c:3696 usb_set_configuration+0x19dd/0x2020 drivers/usb/core/message.c:2165 usb_generic_driver_probe+0x84/0x140 drivers/usb/core/generic.c:238 usb_probe_device+0x130/0x260 drivers/usb/core/driver.c:293 really_probe+0x2ab/0xcb0 drivers/base/dd.c:639 __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785 driver_probe_device+0x50/0x420 drivers/base/dd.c:815 __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943 bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429 __device_attach+0x359/0x570 drivers/base/dd.c:1015 bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489 device_add+0xb48/0xfd0 drivers/base/core.c:3696 usb_new_device+0xbdd/0x18f0 drivers/usb/core/hub.c:2620 hub_port_connect drivers/usb/core/hub.c:5477 [inline] hub_port_connect_change drivers/usb/core/hub.c:5617 [inline] port_event drivers/usb/core/hub.c:5773 [inline] hub_event+0x2efe/0x5730 drivers/usb/core/hub.c:5855 process_one_work+0x8a9/0x11d0 kernel/workqueue.c:2292 worker_thread+0xa47/0x1200 kernel/workqueue.c:2439 kthread+0x28d/0x320 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 ================================================================ Encontrado por el Centro de verificación de Linux (linuxtesting.org) con Syzkaller.
Vulnerabilidad en kernel de Linux (CVE-2025-37898)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc64/ftrace: se corrige la carga de módulos sin entradas de función parcheables. get_stubs_size asume que siempre debe haber al menos una entrada de función parcheable, lo cual no siempre ocurre (módulos que exportan datos, pero no código); de lo contrario, devuelve -ENOEXEC y, por lo tanto, el encabezado de sección sh_size se establece en ese valor. Durante module_memory_alloc(), el tamaño se pasa a execmem_alloc() tras la alineación de página y, por lo tanto, se establece en cero, lo que provocará un error en la asignación (y, por lo tanto, en la carga del módulo), ya que __vmalloc_node_range() busca asignaciones de tamaño cero y devuelve null: [115.466896] module_64: cast_common: no contiene __patchable_function_entries. [ 115.469189] ------------[ cortar aquí ]------------ [ 115.469496] ADVERTENCIA: CPU: 0 PID: 274 en mm/vmalloc.c:3778 __vmalloc_node_range_noprof+0x8b4/0x8f0 ... [ 115.478574] ---[ fin del seguimiento 0000000000000000 ]--- [ 115.479545] execmem: no se puede asignar memoria Solucione esto eliminando la verificación por completo, ya que de todos modos no es útil propagar esto como un error hacia arriba.
Vulnerabilidad en kernel de Linux (CVE-2025-37899)
Severidad: ALTA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: corrección del problema "use-after-free" al cerrar sesión. El objeto sess->user puede estar siendo utilizado por otro hilo, por ejemplo, si otra conexión ha enviado una solicitud de configuración de sesión para enlazarse a la sesión que se está liberando. El controlador de esa conexión podría estar en la función smb2_sess_setup, que utiliza sess->user.
Vulnerabilidad en kernel de Linux (CVE-2025-37900)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu: Se corrigen dos problemas en iommu_copy_struct_from_user() En la revisión del asistente iommu_copy_struct_to_user(), Matt señaló que se debe rechazar un puntero NULL antes de desreferenciarlo: https://lore.kernel.org/all/86881827-8E2D-461C-BDA3-FA8FD14C343C@nvidia.com Y Alok señaló un error tipográfico al mismo tiempo: https://lore.kernel.org/all/480536af-6830-43ce-a327-adbd13dc3f1d@oracle.com Dado que ambos problemas se copiaron de iommu_copy_struct_from_user(), corríjalos primero en el encabezado actual.
Vulnerabilidad en kernel de Linux (CVE-2022-50096)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/kprobes: Actualización del indicador de estado de kcb tras el paso único. Se corrigió que kprobes actualizara el indicador de estado de kcb (bloque de control de kprobes) a KPROBE_HIT_SSDONE incluso si kp->post_handler no está configurado. Este error puede causar un pánico del kernel si otro usuario INT3 se ejecuta justo después de kprobes, ya que kprobe_int3_handler() malinterpreta que INT3 es el INT3 de paso único de kprobe.
Vulnerabilidad en kernel de Linux (CVE-2022-50097)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: s3fb: Verifique el tamaño de la pantalla antes de memset_io() En la función s3fb_set_par(), el valor de 'screen_size' se calcula mediante la entrada del usuario. Si el usuario proporciona un valor incorrecto, el valor de 'screen_size' puede ser mayor que 'info->screen_size', lo que puede causar el siguiente error: [ 54.083733] ERROR: no se puede manejar el error de página para la dirección: ffffc90003000000 [ 54.083742] #PF: acceso de escritura del supervisor en modo kernel [ 54.083744] #PF: error_code(0x0002) - página no presente [ 54.083760] RIP: 0010:memset_orig+0x33/0xb0 [ 54.083782] Rastreo de llamadas: [ 54.083788] s3fb_set_par+0x1ec6/0x4040 [ 54.083806] fb_set_var+0x604/0xeb0 [ 54.083836] do_fb_ioctl+0x234/0x670 Solucione este problema comprobando el valor de 'screen_size' antes de memset_io().
Vulnerabilidad en kernel de Linux (CVE-2022-50098)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: Se corrige un fallo debido a un acceso obsoleto a SRB cerca de los tiempos de espera de E/S. Asegúrese de que SRB se devuelva durante la escalada de errores de tiempo de espera de E/S. Si esto no es posible, reinicie la ruta de escalada. Se observó la siguiente pila de fallos: Error: no se puede gestionar la solicitud de paginación del kernel en 0000002f56aa90f8 IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx] Rastreo de llamadas: ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx] ? qla2x00_start_sp+0x116/0x1170 [qla2xxx] ? dma_pool_alloc+0x1d6/0x210 ? mempool_alloc+0x54/0x130 ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx] ? qla_do_work+0x2d/0x40 [qla2xxx] ? process_one_work+0x14c/0x390
Vulnerabilidad en kernel de Linux (CVE-2022-50099)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: arkfb: Verifique el tamaño de la pantalla antes de memset_io() En la función arkfb_set_par(), el valor de 'screen_size' se calcula mediante la entrada del usuario. Si el usuario proporciona un valor incorrecto, el valor de 'screen_size' puede ser mayor que 'info->screen_size', lo que puede causar el siguiente error: [ 659.399066] ERROR: no se puede manejar el error de página para la dirección: ffffc90003000000 [ 659.399077] #PF: acceso de escritura del supervisor en modo kernel [ 659.399079] #PF: error_code(0x0002) - página no presente [ 659.399094] RIP: 0010:memset_orig+0x33/0xb0 [ 659.399116] Rastreo de llamadas: [ 659.399122] arkfb_set_par+0x143f/0x24c0 [ 659.399130] fb_set_var+0x604/0xeb0 [ 659.399161] do_fb_ioctl+0x234/0x670 [ 659.399189] fb_ioctl+0xdd/0x130 Solucione este problema comprobando el valor de 'screen_size' antes de memset_io().
Vulnerabilidad en kernel de Linux (CVE-2022-50100)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/core: No volver a poner en cola la tarea en la CPU excluida de cpus_mask La siguiente advertencia se activó en una máquina grande al comienzo del arranque en un kernel de distribución, pero el mismo problema también debería afectar a la línea principal. ADVERTENCIA: CPU: 439 PID: 10 en ../kernel/workqueue.c:2231 process_one_work+0x4d/0x440 Rastreo de llamadas: rescuer_thread+0x1f6/0x360 kthread+0x156/0x180 ret_from_fork+0x22/0x30 el commit c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") optimiza ttwu poniendo en cola una tarea que se está desprogramando en la lista de activación, pero no comprueba si la desprogramación de tareas aún puede ejecutarse en esa CPU. En esta advertencia, la tarea problemática es un subproceso de rescate de la cola de trabajo que comprueba si el rescate es para una cola de trabajo por CPU y se ejecuta en la CPU incorrecta. Aunque esto ocurre al principio del arranque y debería ser posible crear trabajadores, el hilo de rescate aún podría usarse si se alcanza el tiempo de espera inicial (MAYDAY_INITIAL_TIMEOUT) o el intervalo (MAYDAY_INTERVAL) y, en una máquina lo suficientemente grande, se usa con frecuencia. El seguimiento confirmó que la tarea debería haberse migrado correctamente utilizando el hilo de parada para gestionar la migración. Sin embargo, una activación paralela de udev, ejecutándose en otra CPU que no comparte caché de CPU, observa p->on_cpu y utiliza task_cpu(p), pone la tarea en cola en la CPU anterior y activa la advertencia. Compruebe que la tarea de activación que se está desprogramando aún pueda ejecutarse en su CPU actual; de no ser así, espere a que se complete la desprogramación y seleccione una CPU permitida.
Vulnerabilidad en kernel de Linux (CVE-2022-50101)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: vt8623fb: Verifique el tamaño de la pantalla antes de memset_io() En la función vt8623fb_set_par(), el valor de 'screen_size' se calcula mediante la entrada del usuario. Si el usuario proporciona un valor incorrecto, el valor de 'screen_size' puede ser mayor que 'info->screen_size', lo que puede causar el siguiente error: [ 583.339036] ERROR: no se puede manejar el error de página para la dirección: ffffc90005000000 [ 583.339049] #PF: acceso de escritura del supervisor en modo kernel [ 583.339052] #PF: error_code(0x0002) - página no presente [ 583.339074] RIP: 0010:memset_orig+0x33/0xb0 [ 583.339110] Rastreo de llamadas: [ 583.339118] vt8623fb_set_par+0x11cd/0x21e0 [ 583.339146] fb_set_var+0x604/0xeb0 [ 583.339181] do_fb_ioctl+0x234/0x670 [ 583.339209] fb_ioctl+0xdd/0x130 Solucione este problema comprobando el valor de 'screen_size' antes de memset_io().
Vulnerabilidad en kernel de Linux (CVE-2022-50102)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: arkfb: Corrige un error de división por cero en ark_set_pixclock() Dado que el usuario puede controlar los argumentos de ioctl() desde el espacio de usuario, bajo argumentos especiales que pueden resultar en un error de división por cero en: drivers/video/fbdev/arkfb.c:784: ark_set_pixclock(info, (hdiv * info->var.pixclock) / hmul); con hdiv=1, pixclock=1 y hmul=2 terminas con (1*1)/2 = (int) 0. y luego en: drivers/video/fbdev/arkfb.c:504: rv = dac_set_freq(par->dac, 0, 1000000000 / pixclock); obtendremos una división por cero. El siguiente registro puede revelarlo: error de división: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:ark_set_pixclock drivers/video/fbdev/arkfb.c:504 [en línea] RIP: 0010:arkfb_set_par+0x10fc/0x24c0 drivers/video/fbdev/arkfb.c:784 Rastreo 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 marcando el argumento de ark_set_pixclock() primero.
Vulnerabilidad en kernel de Linux (CVE-2022-50103)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched, cpuset: Se solucionó el pánico de dl_cpu_busy() debido a un valor de cs->cpus_allowed vacío. Con cgroup v2, la máscara cpus_allowed de cpuset puede estar vacía, lo que indica que solo usará las CPU efectivas de su padre. Por lo tanto, cpuset_can_attach() puede llamar a task_can_attach() con una máscara vacía. Esto puede provocar que cpumask_any_and() devuelva nr_cpu_ids, lo que provoca el bloqueo de la llamada a dl_bw_of() debido al acceso a un valor de CPU fuera de los límites. Por ejemplo: [80468.182258] ERROR: no se puede manejar el error de página para la dirección: ffffffff8b6648b0 : [80468.191019] RIP: 0010:dl_cpu_busy+0x30/0x2b0 : [80468.207946] Rastreo de llamadas: [80468.208947] cpuset_can_attach+0xa0/0x140 [80468.209953] cgroup_migrate_execute+0x8c/0x490 [80468.210931] cgroup_update_dfl_csses+0x254/0x270 [80468.211898] Solucione esto utilizando effective_cpus en su lugar. Para cgroup v1, effective_cpus es igual que cpus_allowed. Para v2, effective_cpus es la máscara de CPU real que usarán las tareas dentro del conjunto de CPU. Actualice también el segundo argumento de task_can_attach() a cs_effective_cpus para reflejar el cambio. Además, se ha añadido una comprobación a task_can_attach() para evitar que cpumask_any_and() devuelva un valor mayor que nr_cpu_ids.
Vulnerabilidad en kernel de Linux (CVE-2022-50104)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/xive: Se corrige la fuga de recuento de referencias en xive_get_max_prio. of_find_node_by_path() devuelve un puntero de nodo con el recuento de referencias incrementado; al finalizar, se debe usar of_node_put(). Se ha añadido la función of_node_put() que falta para evitar la fuga de recuento de referencias.
Vulnerabilidad en kernel de Linux (CVE-2022-50105)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/spufs: Se corrige la fuga de recuento de referencias en spufs_init_isolated_loader. La función `of_find_node_by_path()` devuelve el puntero de nodo del dispositivo remoto con el recuento de referencias incrementado. Al finalizar, se debe usar `of_node_put()`. Se ha añadido la función `of_node_put()` que falta para evitar la fuga de recuento de referencias.
Vulnerabilidad en kernel de Linux (CVE-2022-50106)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/cell/axon_msi: Se corrige la fuga de recuento de referencias en setup_msi_msg_address. of_get_next_parent() devuelve un puntero de nodo con el recuento de referencias incrementado. Debemos usar of_node_put() cuando ya no sea necesario. Agregue la falta de of_node_put() en la ruta de error para evitar la fuga de recuento de referencias.
Vulnerabilidad en kernel de Linux (CVE-2022-50108)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mfd: max77620: Se corrige la fuga de recuento de referencias en max77620_initialise_fps. of_get_child_by_name() devuelve un puntero de nodo con el recuento de referencias incrementado. Debemos usar of_node_put() cuando ya no sea necesario. Se ha añadido la función of_node_put() que falta para evitar la fuga de recuento de referencias.
Vulnerabilidad en kernel de Linux (CVE-2022-50109)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: amba-clcd: Corrección de errores de fuga de recuento de referencias. En clcdfb_of_init_display(), debemos llamar a of_node_put() para las referencias devueltas por of_graph_get_next_endpoint() y of_graph_get_remote_port_parent() que han aumentado el recuento de referencias. Además, debemos llamar a of_node_put() tanto en la ruta de error como cuando las referencias ya no se utilizan.
Vulnerabilidad en kernel de Linux (CVE-2022-50111)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mt6359: Corregir error de pérdida de recuento de referencias En mt6359_parse_dt() y mt6359_accdet_parse_dt(), debemos llamar a of_node_put() para la referencia devuelta por of_get_child_by_name() que ha aumentado el recuento de referencias.
Vulnerabilidad en kernel de Linux (CVE-2022-50142)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: intel_th: msu: Reparar búferes vmalloced Después de el commit f5ff79fddf0e ("dma-mapping: remove CONFIG_DMA_REMAP") existe la posibilidad de que el buffer DMA se asigne a través de vmalloc(), lo que arruina el código mmapping: > RIP: msc_mmap_fault [intel_th_msu] > Rastreo de llamada: > > __do_fault > do_fault ... Solucione esto teniendo en cuenta la posibilidad de vmalloc.
Vulnerabilidad en kernel de Linux (CVE-2022-50182)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: imx-jpeg: Alinear hacia arriba el tamaño del búfer. El hardware puede admitir cualquier tamaño de imagen (ancho x alto), con dimensiones arbitrarias de ancho y alto. Alinear hacia arriba el tamaño del búfer tanto para el codificador como para el decodificador y dejar la resolución de la imagen sin cambios. Para el decodificador, se puede evitar el riesgo de memoria fuera de los límites. Tanto para el codificador como para el decodificador, el controlador eliminará la limitación de la alineación de la resolución. Por ejemplo, el decodificador puede admitir jpeg cuya resolución es de 227x149, el codificador puede admitir nv12 1080P, no lo cambiará a 1920x1072.
Vulnerabilidad en kernel de Linux (CVE-2022-50183)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/meson: encoder_cvbs: Se corrige la fuga de recuento de referencias en meson_encoder_cvbs_init. `of_graph_get_remote_node()` devuelve el puntero de nodo del dispositivo remoto con el recuento de referencias incrementado. Deberíamos usar `of_node_put()` al finalizar. Se ha añadido la función `of_node_put()` que falta para evitar la fuga de recuento de referencias.
Vulnerabilidad en kernel de Linux (CVE-2022-50184)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/meson: encoder_hdmi: Se corrige la fuga de recuento de referencias en meson_encoder_hdmi_init. `of_graph_get_remote_node()` devuelve el puntero de nodo del dispositivo remoto con el recuento de referencias incrementado. Deberíamos usar `of_node_put()` al finalizar. Se ha añadido la función `of_node_put()` que falta para evitar la fuga de recuento de referencias.
Vulnerabilidad en kernel de Linux (CVE-2022-50185)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/radeon: corrige un desbordamiento de búfer potencial en ni_set_mc_special_registers() La última etiqueta de caso puede escribir dos búferes 'mc_reg_address[j]' y 'mc_data[j]' con el desplazamiento 'j' igual a SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE ya que no hay comprobaciones para este valor en ambas etiquetas de caso después del último 'j++'. En lugar de cambiar ">" a ">=" allí, agregue la comprobación de los límites al comienzo del segundo 'caso' (el primero ya lo tiene). Además, elimine las últimas comprobaciones redundantes para el índice 'j' mayor que el tamaño del arreglo. La expresión siempre es falsa. Además, antes o después del parche 'table->last' puede ser igual a SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE y parece que puede ser un valor válido. Detectado usando la herramienta de análisis estático - Svace.
Vulnerabilidad en kernel de Linux (CVE-2022-50186)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath11k: se corrige la falta de eliminación de skb en el error htc_tx_completion. En el error htc_tx_completion, el skb no se elimina. Esto es incorrecto, ya que la lógica de completion_handler espera que el skb se consuma de todas formas, incluso cuando se produce un error. No liberar el skb en caso de error supone una fuga de memoria, ya que no se liberará en ningún otro lugar. Libere correctamente el paquete en eid >= ATH11K_HTC_EP_COUNT antes de regresar. Probado en: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1
Vulnerabilidad en kernel de Linux (CVE-2022-50187)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath11k: corrección de netdev open race. Asegúrese de asignar los recursos necesarios antes de registrar el dispositivo. Esto evita que un open() de ejecución active un BUG_ON() en mod_timer() cuando se llama ath11k_mac_op_start() antes de configurar mon_reap_timer. No observé este problema con next-20220310, pero sí lo encontré en cada sondeo con next-20220511. Quizás se produjo algún cambio de sincronización entre ambos. Aquí está el backtrace: [51.346947] ¡ERROR del kernel en kernel/time/timer.c:990! [ 51.346958] Error interno: Ups - ERROR: 0 [#1] PREEMPT SMP ... [ 51.578225] Rastreo de llamadas: [ 51.583293] __mod_timer+0x298/0x390 [ 51.589518] mod_timer+0x14/0x20 [ 51.595368] ath11k_mac_op_start+0x41c/0x4a0 [ath11k] [ 51.603165] drv_start+0x38/0x60 [mac80211] [ 51.610110] ieee80211_do_open+0x29c/0x7d0 [mac80211] [ 51.617945] ieee80211_open+0x60/0xb0 [mac80211] [ 51.625311] __dev_open+0x100/0x1c0 [ 51.631420] __dev_change_flags+0x194/0x210 [ 51.638214] dev_change_flags+0x24/0x70 [ 51.644646] do_setlink+0x228/0xdb0 [ 51.650723] __rtnl_newlink+0x460/0x830 [ 51.657162] rtnl_newlink+0x4c/0x80 [ 51.663229] rtnetlink_rcv_msg+0x124/0x390 [ 51.669917] netlink_rcv_skb+0x58/0x130 [ 51.676314] rtnetlink_rcv+0x18/0x30 [ 51.682460] netlink_unicast+0x250/0x310 [ 51.688960] netlink_sendmsg+0x19c/0x3e0 [ 51.695458] ____sys_sendmsg+0x220/0x290 [ 51.701938] ___sys_sendmsg+0x7c/0xc0 [ 51.708148] __sys_sendmsg+0x68/0xd0 [ 51.714254] __arm64_sys_sendmsg+0x28/0x40 [ 51.720900] invoke_syscall+0x48/0x120 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
Vulnerabilidad en kernel de Linux (CVE-2022-50188)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/meson: Se corrige la fuga de recuento de referencias en meson_encoder_hdmi_init. La referencia de of_find_device_by_node() se toma; debemos usar put_device() para liberarla cuando ya no sea necesaria. Se añade la falta de put_device() en la ruta de error para evitar la fuga de recuento de referencias.
Vulnerabilidad en kernel de Linux (CVE-2022-50190)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: Corrección de la simplificación de devm_spi_register_controller. Esto revierte el commit 59ebbe40fb51 ("spi: simplificar devm_spi_register_controller"). Si devm_add_action() falla en devm_add_action_or_reset(), se llamará a devm_spi_unregister(), lo que reduce el recuento de referencias de 'ctlr->dev' a 0 y, en consecuencia, causará un error uaf en los controladores que llaman a spi_put_controller() en la ruta de error.
Vulnerabilidad en kernel de Linux (CVE-2022-50191)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regulator: of: Se corrige el error de pérdida de recuento de referencias en of_get_regulation_constraints() Deberíamos llamar a of_node_put() para la referencia devuelta por of_get_child_by_name() que ha aumentado el recuento de referencias.
Vulnerabilidad en kernel de Linux (CVE-2022-50192)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: tegra20-slink: corrección del UAF en tegra_slink_remove(). Tras llamar a spi_unregister_master(), el recuento de referencias del master se reduce a 0 y se libera en spi_controller_release(). Los datos del dispositivo también se liberan, por lo que se generará un UAF al usar 'tspi'. Para solucionar esto, obtenga el master antes de anular el registro y colóquelo al finalizar su uso.
Vulnerabilidad en kernel de Linux (CVE-2022-50193)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: despierta a todos los que esperan después de que z_erofs_lzma_head esté listo Cuando el usuario monta erofs por segunda vez, el hilo de descompresión puede colgarse. El problema ocurre debido a una secuencia de pasos como la siguiente: 1) La tarea A llamó a z_erofs_load_lzma_config que obtiene todos los nodos de z_erofs_lzma_head. 2) En este momento, la tarea B llamó a z_erofs_lzma_decompress y quiso obtener un nodo. Pero z_erofs_lzma_head estaba vacío, la tarea B tuvo que dormir. 3) La tarea A libera nodos y los empuja hacia z_erofs_lzma_head. Pero la tarea B seguía durmiendo. Un ejemplo de informe cuando se produce el bloqueo: tarea:kworker/u3:1 estado:D pila:14384 pid: 86 ppid: 2 indicadores:0x00004000 Cola de trabajo: erofs_unzipd z_erofs_decompressqueue_work Seguimiento de llamadas: __schedule+0x281/0x760 schedule+0x49/0xb0 z_erofs_lzma_decompress+0x4bc/0x580 ? cpu_core_flags+0x10/0x10 z_erofs_decompress_pcluster+0x49b/0xba0 ? __update_load_avg_se+0x2b0/0x330 ? __update_load_avg_se+0x2b0/0x330 ? update_load_avg+0x5f/0x690 ? update_load_avg+0x5f/0x690 ? set_next_entity+0xbd/0x110 ? _raw_spin_unlock+0xd/0x20 z_erofs_decompress_queue.isra.0+0x2e/0x50 z_erofs_decompressqueue_work+0x30/0x60 process_one_work+0x1d3/0x3a0 worker_thread+0x45/0x3a0 ? process_one_work+0x3a0/0x3a0 kthread+0xe2/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
Vulnerabilidad en kernel de Linux (CVE-2022-50194)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: aoss: Se corrige la fuga de recuento de referencias en qmp_cooling_devices_register. Cada iteración de for_each_available_child_of_node() disminuye el recuento de referencias del nodo anterior. Al interrumpir un bucle for_each_available_child_of_node() antes de tiempo, debemos llamar explícitamente a of_node_put() en el nodo secundario. Añada la función of_node_put() que falta para evitar la fuga de recuento de referencias.
Vulnerabilidad en kernel de Linux (CVE-2022-50195)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: dts: qcom: reemplazar gcc PXO con pxo_board reloj fijo. Reemplazar gcc PXO phandle por pxo_board reloj fijo declarado en el dts. El controlador gcc no proporciona PXO_SRC, ya que es un reloj fijo. Esto provoca un pánico del kernel si algún controlador intenta usarlo.
Vulnerabilidad en kernel de Linux (CVE-2022-50196)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: ocmem: Se corrige la fuga de recuento de referencias en of_get_ocmem. of_parse_phandle() devuelve un puntero de nodo con el recuento de referencias incrementado. Debemos usar of_node_put() cuando ya no sea necesario. Se ha añadido la función of_node_put() que falta para evitar la fuga de recuento de referencias. of_node_put() comprobará el puntero NULL.
Vulnerabilidad en kernel de Linux (CVE-2022-50197)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: zynq: Se corrige la fuga de recuento de referencias en zynq_get_revision. of_find_compatible_node() devuelve un puntero de nodo con el recuento de referencias incrementado; al finalizar, se debe usar of_node_put(). Se ha añadido la función of_node_put() que falta para evitar la fuga de recuento de referencias.
Vulnerabilidad en kernel de Linux (CVE-2022-50198)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: OMAP2+: Se corrige la fuga de recuento de referencias en omap3xxx_prm_late_init. of_find_matching_node() devuelve un puntero de nodo con el recuento de referencias incrementado. Debemos usar of_node_put() cuando ya no sea necesario. Se ha añadido la función of_node_put() que falta para evitar la fuga de recuento de referencias.
Vulnerabilidad en kernel de Linux (CVE-2022-50199)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: OMAP2+: Se corrige la fuga de recuento de referencias en omapdss_init_of. Omapdss_find_dss_of_node() llama a of_find_compatible_node() para obtener el nodo del dispositivo. of_find_compatible_node() devuelve un puntero de nodo con el recuento de referencias incrementado; al finalizar, se debe usar of_node_put(). Se añade la falta de of_node_put() en la ruta de error posterior y en la ruta normal.
Vulnerabilidad en kernel de Linux (CVE-2022-50200)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: selinux: Agregar verificación de los límites en put_entry() Al igual que next_entry(), la verificación de los límites es necesaria para evitar el acceso fuera de los límites de la memoria.
Vulnerabilidad en kernel de Linux (CVE-2022-50201)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: selinux: corrige memleak en security_read_state_kernel() En esta función, devuelve directamente el resultado de __security_read_policy sin liberar la memoria asignada en *data, lo que causa un problema de pérdida de memoria, por lo que libera la memoria si __security_read_policy falla. [PM: ajuste de la línea de asunto]
Vulnerabilidad en kernel de Linux (CVE-2022-50202)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM: hibernar: aplazar el sondeo del dispositivo al reanudar desde la hibernación syzbot informa una tarea colgada en misc_open() [1], ya que hay una ventana de ejecución de punto muerto AB-BA que involucra a la variable probe_count. Actualmente, wait_for_device_probe() de snapshot_open() de misc_open() puede dormir para siempre con misc_mtx retenido si probe_count no puede llegar a 0. Cuando un dispositivo es sondeado por la función de trabajo hub_event(), probe_count se incrementa antes de que comience la función de sondeo y probe_count se decrementa después de que la función de sondeo se complete. Hay tres casos que pueden evitar que probe_count caiga a 0. (a) Un dispositivo que se está sondeando dejó de responder (es decir, hardware roto/malicioso). (b) Un proceso que emula un dispositivo USB usando la interfaz /dev/raw-gadget dejó de responder por alguna razón. (c) Siguen llegando nuevas solicitudes de sondeo de dispositivo antes de que se completen las solicitudes de sondeo de dispositivo existentes. El fenómeno que syzbot reporta es (b). Un proceso que contiene system_transition_mutex y misc_mtx espera a que probe_count sea 0 dentro de wait_for_device_probe(), pero la función de sonda, llamada desde la función de trabajo hub_event(), espera a que los procesos bloqueados en mutex_lock(&misc_mtx) respondan mediante la interfaz /dev/raw-gadget. Este parche mitiga (b) al posponer wait_for_device_probe() de snapshot_open() a snapshot_write() y snapshot_ioctl(). Tenga en cuenta que la posibilidad de (b) persiste mientras cualquier hilo que emule un dispositivo USB mediante la interfaz /dev/raw-gadget pueda ser bloqueado por operaciones de bloqueo ininterrumpido (p. ej., mutex_lock()). Tenga en cuenta también que (a) y (c) no se abordan. Respecto a (c), debemos modificar el código para que espere solo a un dispositivo que contenga la imagen para reanudar la hibernación. No sé cómo abordar (a), ya que el uso del tiempo de espera para wait_for_device_probe() podría provocar la pérdida de datos de usuario en la imagen. Quizás deberíamos exigir que el espacio de usuario espere al dispositivo de imagen antes de abrir la interfaz /dev/snapshot.
Vulnerabilidad en kernel de Linux (CVE-2022-50203)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: OMAP2+: display: Se corrige el error de fuga de refcount. En omapdss_init_fbdev(), of_find_node_by_name() devolverá un puntero de nodo con refcount incrementado. Deberíamos usar of_node_put() cuando ya no se use.
Vulnerabilidad en kernel de Linux (CVE-2022-50204)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: OMAP2+: pdata-quirks: Corregir error de pérdida de recuento de referencias En pdata_quirks_init_clocks(), el bucle contiene of_find_node_by_name() pero sin el of_node_put() correspondiente.
Vulnerabilidad en kernel de Linux (CVE-2022-50205)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext2: Se han añadido más comprobaciones de validez para el recuento de inodos. Se han añadido comprobaciones que verifican que el número de inodos almacenados en el superbloque coincida con el calculado a partir del número de inodos por grupo. También se ha verificado que tengamos al menos un bloque de inodos por grupo. Esto evita fallos en sistemas de archivos dañados.
Vulnerabilidad en kernel de Linux (CVE-2022-50206)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: se corrige el error al configurar simultáneamente sysctls emulation_proc_handler() de insn_emulation y cambia table->data para proc_dointvec_minmax, que puede generar el siguiente error si se llama simultáneamente consigo mismo: | No se puede controlar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000010 | Error interno: Oops: 96000006 [#1] SMP | Rastreo de llamadas: | update_insn_emulation_mode+0xc0/0x148 | emulation_proc_handler+0x64/0xb8 | proc_sys_call_handler+0x9c/0xf8 | proc_sys_write+0x18/0x20 | __vfs_write+0x20/0x48 | Para solucionar este problema, mantenga la tabla->data como &insn->current_mode y use container_of() para recuperar el puntero insn. Se usa otro mutex para proteger contra la actualización de current_mode, pero no para recuperar la emulación insn, ya que la tabla->data ya no cambia.
Vulnerabilidad en kernel de Linux (CVE-2022-50207)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: bcm: Se corrige la fuga de recuento de referencias en bcm_kona_smc_init. of_find_matching_node() devuelve un puntero de nodo con el recuento de referencias incrementado. Debemos usar of_node_put() cuando ya no sea necesario. Se ha añadido la función of_node_put() que falta para evitar la fuga de recuento de referencias.
Vulnerabilidad en kernel de Linux (CVE-2022-50209)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: meson-mx-socinfo: Se corrige la fuga de recuento de referencias en meson_mx_socinfo_init. of_find_matching_node() devuelve un puntero de nodo con el recuento de referencias incrementado. Debemos usar of_node_put() cuando ya no sea necesario. Se ha añadido la función of_node_put() que falta para evitar la fuga de recuento de referencias.
Vulnerabilidad en kernel de Linux (CVE-2022-50210)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: MIPS: cpuinfo: Se corrige una advertencia para CONFIG_CPUMASK_OFFSTACK. Al seleccionar CONFIG_CPUMASK_OFFSTACK y CONFIG_DEBUG_PER_CPU_MAPS, cpu_max_bits_warn() genera una advertencia de tiempo de ejecución similar a la que se muestra a continuación mientras se muestra /proc/cpuinfo. Se corrige usando nr_cpu_ids (el límite de tiempo de ejecución) en lugar de NR_CPUS para iterar las CPU. [ 3.052463] ------------[ cortar aquí ]------------ [ 3.059679] ADVERTENCIA: CPU: 3 PID: 1 en include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Módulos vinculados: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd No contaminado 5.19-rc5+ #1052 [ 3.084034] Nombre del hardware: Loongson Loongson-3A4000-7A1000-1w-V0.1-CRB/Loongson-LS3A4000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27 [3.099465] Pila: 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [3.118774] 90000001001578e8 000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 000000000000000 0000000000000000 000000000000000 00000000000000 00000000000aaaaaa [ 3.147711] ffff8000339dc220 000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Rastreo de llamadas: [ 3.203941] [<98000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9800000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<980000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9800000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9800000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<98000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<98000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<98000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<98000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9800000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9800000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ fin de seguimiento 8b484262b4b8c24c ]---
Vulnerabilidad en kernel de Linux (CVE-2022-50211)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md-raid10: corrección de la advertencia de KASAN. Hay una advertencia de KASAN en raid10_remove_disk al ejecutar la prueba lvm lvconvert-raid-reshape.sh. Para corregir esta advertencia, verificamos que el valor "number" sea válido. ERROR: KASAN: slab fuera de los límites en raid10_remove_disk+0x61/0x2a0 [raid10] Lectura de tamaño 8 en la dirección ffff889108f3d300 por la tarea mdX_raid10/124682 CPU: 3 PID: 124682 Comm: mdX_raid10 No contaminado 5.19.0-rc6 #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x34/0x44 print_report.cold+0x45/0x57a ? __lock_text_start+0x18/0x18 ? raid10_remove_disk+0x61/0x2a0 [raid10] kasan_report+0xa8/0xe0 ? raid10_remove_disk+0x61/0x2a0 [raid10] raid10_remove_disk+0x61/0x2a0 [raid10] Buffer I/O error on dev dm-76, logical block 15344, async page read ? __mutex_unlock_slowpath.constprop.0+0x1e0/0x1e0 remove_and_add_spares+0x367/0x8a0 [md_mod] ? super_written+0x1c0/0x1c0 [md_mod] ? mutex_trylock+0xac/0x120 ? _raw_spin_lock+0x72/0xc0 ? _raw_spin_lock_bh+0xc0/0xc0 md_check_recovery+0x848/0x960 [md_mod] raid10d+0xcf/0x3360 [raid10] ? sched_clock_cpu+0x185/0x1a0 ? rb_erase+0x4d4/0x620 ? var_wake_function+0xe0/0xe0 ? psi_group_change+0x411/0x500 ? preempt_count_sub+0xf/0xc0 ? _raw_spin_lock_irqsave+0x78/0xc0 ? __lock_text_start+0x18/0x18 ? raid10_sync_request+0x36c0/0x36c0 [raid10] ? preempt_count_sub+0xf/0xc0 ? _raw_spin_unlock_irqrestore+0x19/0x40 ? del_timer_sync+0xa9/0x100 ? try_to_del_timer_sync+0xc0/0xc0 ? _raw_spin_lock_irqsave+0x78/0xc0 ? __lock_text_start+0x18/0x18 ? _raw_spin_unlock_irq+0x11/0x24 ? __list_del_entry_valid+0x68/0xa0 ? finish_wait+0xa3/0x100 md_thread+0x161/0x260 [md_mod] ? unregister_md_personality+0xa0/0xa0 [md_mod] ? _raw_spin_lock_irqsave+0x78/0xc0 ? prepare_to_wait_event+0x2c0/0x2c0 ? unregister_md_personality+0xa0/0xa0 [md_mod] kthread+0x148/0x180 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 Allocated by task 124495: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x80/0xa0 setup_conf+0x140/0x5c0 [raid10] raid10_run+0x4cd/0x740 [raid10] md_run+0x6f9/0x1300 [md_mod] raid_ctr+0x2531/0x4ac0 [dm_raid] dm_table_add_target+0x2b0/0x620 [dm_mod] table_load+0x1c8/0x400 [dm_mod] ctl_ioctl+0x29e/0x560 [dm_mod] dm_compat_ctl_ioctl+0x7/0x20 [dm_mod] __do_compat_sys_ioctl+0xfa/0x160 do_syscall_64+0x90/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x9e/0xc0 kvfree_call_rcu+0x84/0x480 timerfd_release+0x82/0x140 L __fput+0xfa/0x400 task_work_run+0x80/0xc0 exit_to_user_mode_prepare+0x155/0x160 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x42/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Second to last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x9e/0xc0 kvfree_call_rcu+0x84/0x480 timerfd_release+0x82/0x140 __fput+0xfa/0x400 task_work_run+0x80/0xc0 exit_to_user_mode_prepare+0x155/0x160 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x42/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The buggy address belongs to the object at ffff889108f3d200 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes to the right of 256-byte region [ffff889108f3d200, ffff889108f3d300) The buggy address belongs to the physical page: page:000000007ef2a34c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1108f3c head:000000007ef2a34c order:2 compound_mapcount:0 compound_pincount:0 flags: 0x4000000000010200(slab|head|zone=2) raw: 4000000000010200 0000000000000000 dead000000000001 ffff889100042b40 raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff889108f3d200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff889108f3d280: 00 00 ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2022-50212)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: no permitir que CHAIN_ID haga referencia a otra tabla Al realizar búsquedas de cadenas en el mismo lote usando su ID, se puede usar una cadena de una tabla diferente. Si se agrega una regla a una tabla pero hace referencia a una cadena en una tabla diferente, se vinculará a la cadena en la tabla2, pero tendría expresiones que hacen referencia a objetos en la tabla1. Luego, cuando se elimina la tabla1, la regla no se eliminará ya que está vinculada a una cadena en la tabla2. Cuando se procesan o eliminan expresiones en la regla, eso conducirá a un Use-After-Free. Al buscar cadenas por ID, use la tabla que se usó para la búsqueda por nombre y solo devuelva las cadenas que pertenecen a esa misma tabla.
Vulnerabilidad en kernel de Linux (CVE-2022-50213)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: no permitir que SET_ID haga referencia a otra tabla. Al buscar conjuntos en el mismo lote usando su ID, se puede usar un conjunto de una tabla diferente. Al eliminar la tabla, es posible que se conserve una referencia al conjunto después de liberarlo, lo que puede provocar un error de Use-After-Free. Al buscar conjuntos por ID, se debe usar la tabla utilizada para la búsqueda por nombre y devolver solo los conjuntos que pertenecen a esa misma tabla. Esto corrige CVE-2022-2586, también reportado como ZDI-CAN-17470.
Vulnerabilidad en kernel de Linux (CVE-2022-50214)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: coresight: Borrar el campo de conexión correctamente los dispositivos coresight rastrean sus conexiones (conexiones de salida) y mantienen una referencia al fwnode. Cuando un dispositivo desaparece, recorremos los dispositivos en el bus coresight y nos aseguramos de que se eliminen las referencias. Esto sucede en ambos sentidos: a) Para todas las conexiones de salida desde el dispositivo, eliminamos la referencia al dispositivo de destino mediante coresight_release_platform_data() b) Iteramos sobre todos los dispositivos en el bus coresight y eliminamos la referencia a fwnode si *este* dispositivo es el destino de la conexión de salida, mediante coresight_remove_conns()->coresight_remove_match(). Sin embargo, coresight_remove_match() no borra el campo fwnode, después de eliminar la referencia, esto causa Use-After-Free y disminuciones adicionales de refcount en el fwnode. Por ejemplo, si tenemos dos dispositivos, A y B, conectados, A -> B. Si eliminamos B primero, B eliminaría la referencia en B desde A mediante coresight_remove_match(). Sin embargo, al eliminar A, aún mantiene una conexión con fwnode apuntando a B. Por lo tanto, intenta eliminar la referencia en coresight_release_platform_data(), lo que genera alertas como: [ 91.990153 ------------[ cortar aquí ]------------ [ 91.990163 ] refcount_t: adición en 0; Use-After-Free. [ 91.990212] ADVERTENCIA: CPU: 0 PID: 461 en lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144 [ 91.990260] Módulos vinculados: coresight_funnel coresight_replicator coresight_etm4x(-) crct10dif_ce coresight ip_tables x_tables ipv6 [última descarga: coresight_cpu_debug] [ 91.990398] CPU: 0 PID: 461 Comm: rmmod Contaminado: GWT 5.19.0-rc2+ #53 [ 91.990418] Nombre del hardware: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II 1 de febrero de 2019 [ 91.990434] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 91.990454] pc : refcount_warn_saturate+0xa0/0x144 [ 91.990476] lr : refcount_warn_saturate+0xa0/0x144 [ 91.990496] sp : ffff80000c843640 [ 91.990509] x29: ffff80000c843640 x28: ffff800009957c28 x27: ffff80000c8439a8 [ 91.990560] x26: ffff00097eff1990 x25: ffff8000092b6ad8 x24: ffff00097eff19a8 [91.990610] x23: ffff80000c8439a8 x22: 0000000000000000 x21: ffff80000c8439c2 [91.990659] x20: 0000000000000000 x19: ffff00097eff1a10 x18: ffff80000ab99c40 [91.990708] x17: 000000000000000 x16: 0000000000000000 x15: ffff80000abf6fa0 [ 91.990756] x14: 000000000000001d x13: 0a2e656572662d72 x12: 657466612d657375 [ 91.990805] x11: 203b30206e6f206e x10: 6f69746964646120 x9: ffff8000081aba28 [91.990854] x8: 206e6f206e6f6974 x7: 69646461203a745f x6: 746e756f63666572 [91.990903] x5: ffff00097648ec58 x4: 0000000000000000 x3: 0000000000000027 [91.990952] x2: 0000000000000000 x1: 0000000000000000 x0: ffff00080260ba00 [91.991000] Rastreo de llamadas: [ 91.991012] refcount_warn_saturate+0xa0/0x144 [ 91.991034] kobject_get+0xac/0xb0 [ 91.991055] of_node_get+0x2c/0x40 [ 91.991076] of_fwnode_get+0x40/0x60 [ 91.991094] fwnode_handle_get+0x3c/0x60 [ 91.991116] fwnode_get_nth_parent+0xf4/0x110 [ 91.991137] fwnode_full_name_string+0x48/0xc0 [ 91.991158] device_node_string+0x41c/0x530 [ 91.991178] pointer+0x320/0x3ec [ 91.991198] vsnprintf+0x23c/0x750 [ 91.991217] vprintk_store+0x104/0x4b0 [ 91.991238] vprintk_emit+0x8c/0x360 [ 91.991257] vprintk_default+0x44/0x50 [ 91.991276] vprintk+0xcc/0xf0 [ 91.991295] _printk+0x68/0x90 [ 91.991315] of_node_release+0x13c/0x14c [ 91.991334] kobject_put+0x98/0x114 [ 91.991354] of_node_put+0x24/0x34 [ 91.991372] of_fwnode_put+0x40/0x5c [ 91.991390] fwnode_handle_put+0x38/0x50 [ 91.991411] coresight_release_platform_data+0x74/0xb0 [coresight] [ 91.991472] coresight_unregister+0x64/0xcc [coresight] [ 91.991525] etm4_remove_dev+0x64/0x78 [coresight_etm4x] [ 91.991563] etm4_remove_amba+0x1c/0x2c [coresight_etm4x] [ 91.991598] amba_remove+0x3c/0x19c ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2022-50215)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: sg: Permitir esperar a que se completen los comandos en el dispositivo eliminado Cuando se elimina un dispositivo SCSI mientras está en uso activo, actualmente sg devolverá inmediatamente -ENODEV en cualquier intento de esperar los comandos activos que se enviaron antes de la eliminación. Esto es problemático para los comandos que usan SG_FLAG_DIRECT_IO ya que el búfer de datos puede seguir en uso por el kernel cuando el espacio de usuario lo libera o lo reutiliza después de obtener ENODEV, lo que lleva a la memoria del espacio de usuario dañada (en el caso de comandos de tipo READ) o al envío de datos dañados al dispositivo (en el caso de comandos de tipo WRITE). Esto se ha visto en la práctica al cerrar sesión en una sesión iscsi_tcp, donde el controlador iSCSI puede seguir procesando comandos después de que el dispositivo se haya marcado para su eliminación. Cambie la política para permitir que el espacio de usuario espere comandos sg activos incluso cuando se esté eliminando el dispositivo. Devuelva -ENODEV solo cuando no haya más respuestas para leer.
Vulnerabilidad en kernel de Linux (CVE-2022-50217)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fuse: escritura de inodo en fuse_release(). Una competencia entre write(2) y close(2) permite que las páginas se ensucien después de fuse_flush -> write_inode_now(). Si estas páginas no se vacían desde fuse_release(), es posible que no haya ningún archivo abierto con permisos de escritura posteriormente. Por lo tanto, cualquier página sucia restante debe reescribirse antes de liberar el archivo. Esta es una reversión parcial de el commit responsable.
Vulnerabilidad en kernel de Linux (CVE-2022-50218)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: light: isl29028: Se corrige la advertencia en isl29028_remove(). El controlador utiliza la forma no administrada de la función de registro en isl29028_remove(). Para que el orden de lanzamiento sea similar al de la sonda, el controlador también debe usar la forma no administrada en la sonda. El siguiente registro lo revela: [32.374955] isl29028 0-0010: eliminar [32.376861] fallo de protección general, probablemente para dirección no canónica 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI [ 32.377676] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.379432] RIP: 0010:kernfs_find_and_get_ns+0x28/0xe0 [ 32.385461] Call Trace: [ 32.385807] sysfs_unmerge_group+0x59/0x110 [ 32.386110] dpm_sysfs_remove+0x58/0xc0 [ 32.386391] device_del+0x296/0xe50 [ 32.386959] cdev_device_del+0x1d/0xd0 [ 32.387231] devm_iio_device_unreg+0x27/0xb0 [ 32.387542] devres_release_group+0x319/0x3d0 [ 32.388162] i2c_device_remove+0x93/0x1f0
Vulnerabilidad en kernel de Linux (CVE-2022-50219)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Corrección de la lectura de Use-After-Free de KASAN en compute_effective_progs Syzbot encontró un error de Use-After-Free en compute_effective_progs(). El reproductor crea varios enlaces BPF y provoca que falle una asignación inyectada por error, al llamar a bpf_link_detach en ellos. La separación del enlace activa la liberación del enlace por bpf_link_free(), que llama a __cgroup_bpf_detach() y update_effective_progs(). Si la asignación de memoria en esta función falla, la función restaura el puntero a bpf_cgroup_link en la lista cgroup, pero la memoria se libera justo después de que regrese. Después de esto, cada llamada posterior a update_effective_progs() hace que este puntero ya desasignado se desreferencia en prog_list_length() y activa el error UAF de KASAN. Para solucionar este problema, no conserve el puntero al programa ni al enlace en la lista, sino elimínelo y reemplácelo con un programa ficticio sin reducir la tabla. La llamada posterior a __cgroup_bpf_detach() o __cgroup_bpf_detach() lo corregirá.
Vulnerabilidad en kernel de Linux (CVE-2022-50220)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usbnet: Se corrige el Use-After-Free de linkwatch al desconectar. usbnet usa la función usbnet_deferred_kevent() para ejecutar tareas que podrían estar en estado de suspensión. Al desconectar, la finalización de la tarea se esperaba originalmente en ->ndo_stop(). Sin embargo, en 2003, esto se trasladó a ->disconnect() mediante el commit histórica "[PATCH] USB: usbnet, previene el bloqueo rtnl exótico": https://git.kernel.org/tglx/history/c/0f138bbfd83c. Este cambio se realizó porque, en aquel entonces, la implementación de la cola de trabajo del kernel no permitía esperar una sola tarea. Se debía esperar la finalización de *todas* las tareas llamando a flush_scheduled_work(), lo que podía provocar un bloqueo al esperar usbnet_deferred_kevent() con rtnl_mutex en ->ndo_stop(). El commit resolvió un problema pero creó otro: Provoca un uso después de la liberación en los controladores Ethernet USB aqc111.c, asix_devices.c, ax88179_178a.c, ch9200.c y smsc75xx.c: * Si los controladores reciben una interrupción de cambio de enlace inmediatamente antes de la desconexión, generan EVENT_LINK_RESET en su devolución de llamada ->status() (no inactiva) y programan usbnet_deferred_kevent(). * usbnet_deferred_kevent() invoca la devolución de llamada ->link_reset() del controlador, que llama a netif_carrier_{on,off}(). * Eso a su vez programa el trabajo linkwatch_event(). Dado que usbnet_deferred_kevent() se espera después de unregister_netdev(), netif_carrier_{on,off}() puede operar en un netdev no registrado y linkwatch_event() puede ejecutarse después de free_netdev(), lo que provoca un error de uso después de la liberación. En 2010, se modificó la configuración de usbnet para que solo esperara una instancia de usbnet_deferred_kevent() en lugar de *todo* el trabajo mediante el commit 23f333a2bfaf ("drivers/net: no usar flush_scheduled_work()"). Lamentablemente, el commit no retrasó la espera a ->ndo_stop(). Se corrigió esta omisión de una vez.
Vulnerabilidad en kernel de Linux (CVE-2022-50221)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/fb-helper: Arregla el acceso fuera de los límites Recorta el rango de memoria al tamaño del búfer de pantalla para evitar el acceso fuera de los límites en el manejo de daños de E/S diferidas de fbdev. La E/S diferida de fbdev solo puede rastrear páginas. A partir del rango de páginas, el controlador de daños calcula el rectángulo de recorte para la actualización de la pantalla. Si el búfer de pantalla de fbdev termina cerca del principio de una página, esa página podría contener más líneas de exploración. El controlador de daños rastrearía entonces estas líneas de exploración inexistentes como sucias y provocaría un acceso fuera de los límites durante la actualización de la pantalla. Por lo tanto, recorta el rango máximo de memoria al tamaño del búfer de pantalla. Mientras lo haces, cambia el nombre de las variables min/max a min_off/max_off en drm_fb_helper_deferred_io(). Esto evita confusiones con las macros del mismo nombre.
Vulnerabilidad en kernel de Linux (CVE-2022-50222)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: vt: al inicializar el búfer de pantalla Unicode, syzbot reporta una fuga de información del kernel en vcs_read() [1], ya que el búfer se puede leer inmediatamente después de la operación de cambio de tamaño. Inicialice el búfer con kzalloc(). ---------- #include #include #include #include int main(int argc, char *argv[]) { struct fb_var_screeninfo var = { }; const int fb_fd = open("/dev/fb0", 3); ioctl(fb_fd, FBIOGET_VSCREENINFO, &var); var.yres = 0x21; ioctl(fb_fd, FBIOPUT_VSCREENINFO, &var); return read(open("/dev/vcsu", O_RDONLY), &var, sizeof(var)) == -1; } ----------
Vulnerabilidad en kernel de Linux (CVE-2022-50223)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: cpuinfo: Se corrige una advertencia para CONFIG_CPUMASK_OFFSTACK. Al seleccionar CONFIG_CPUMASK_OFFSTACK y CONFIG_DEBUG_PER_CPU_MAPS, cpu_max_bits_warn() genera una advertencia de tiempo de ejecución similar a la que se muestra a continuación mientras se muestra /proc/cpuinfo. Se corrige usando nr_cpu_ids (el límite de tiempo de ejecución) en lugar de NR_CPUS para iterar las CPU. [ 3.052463] ------------[ cortar aquí ]------------ [ 3.059679] ADVERTENCIA: CPU: 3 PID: 1 en include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Módulos vinculados: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd No contaminado 5.19-rc5+ #1052 [ 3.084034] Nombre del hardware: Loongson Loongson-3A5000-7A1000-1w-V0.1-CRB/Loongson-LS3A5000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27 [3.099465] Pila: 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [3.118774] 90000001001578e8 000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 000000000000000 0000000000000000 000000000000000 00000000000000 00000000000aaaaaa [ 3.147711] ffff8000339dc220 000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Rastreo de llamadas: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ fin de seguimiento 8b484262b4b8c24c ]---
Vulnerabilidad en kernel de Linux (CVE-2022-50224)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86/mmu: Tratar NX como un bit SPTE válido para NPT. Se trata el bit NX como válido al usar NPT, ya que KVM lo activará cuando la mitigación de páginas enormes de NX esté habilitada (¡increíble!) y activará la advertencia que se activa al activarse los bits SPTE reservados. KVM ha requerido compatibilidad con NX para SVM desde el commit b26a71a1a5b9 ("KVM: SVM: Rechazar la carga de kvm_amd si la compatibilidad con NX no está disponible") precisamente por esta razón, pero aparentemente a nadie se le ocurrió probar NPT con la mitigación habilitada. ------------[ cortar aquí ]------------ spte = 0x800000018a600ee7, nivel = 2, bits rsvd = 0x800f0000001fe000 ADVERTENCIA: CPU: 152 PID: 15966 en arch/x86/kvm/mmu/spte.c:215 make_spte+0x327/0x340 [kvm] Nombre del hardware: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 27/01/2022 RIP: 0010:make_spte+0x327/0x340 [kvm] Rastreo de llamadas: tdp_mmu_map_handle_target_level+0xc3/0x230 [kvm] kvm_tdp_mmu_map+0x343/0x3b0 [kvm] direct_page_fault+0x1ae/0x2a0 [kvm] kvm_tdp_page_fault+0x7d/0x90 [kvm] kvm_mmu_page_fault+0xfb/0x2e0 [kvm] npf_interception+0x55/0x90 [kvm_amd] svm_invoke_exit_handler+0x31/0xf0 [kvm_amd] svm_handle_exit+0xf6/0x1d0 [kvm_amd] vcpu_enter_guest+0xb6d/0xee0 [kvm] ? kvm_pmu_trigger_event+0x6d/0x230 [kvm] vcpu_run+0x65/0x2c0 [kvm] kvm_arch_vcpu_ioctl_run+0x355/0x610 [kvm] kvm_vcpu_ioctl+0x551/0x610 [kvm] __se_sys_ioctl+0x77/0xc0 __x64_sys_ioctl+0x1d/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 ---[ fin de seguimiento 0000000000000000 ]---
Vulnerabilidad en kernel de Linux (CVE-2022-50225)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv:uprobe fix SR_SPIE set/clear management. En riscv, el proceso de uprobe borra spie antes de ejecutar la instrucción de origen y la configura después. Sin embargo, al acceder a la página donde se ha colocado la instrucción de origen, puede producirse un fallo de página y la función irq se ha deshabilitado en arch_uprobe_pre_xol. Esto genera una advertencia como la siguiente. No es necesario borrar/configurar spie en arch_uprobe_pre/post/abort_xol. Simplemente podemos eliminarlo. [ 31.684157] ERROR: función de suspensión llamada desde un contexto no válido en kernel/locking/rwsem.c:1488 [ 31.684677] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 76, name: work [ 31.684929] preempt_count: 0, expected: 0 [ 31.685969] CPU: 2 PID: 76 Comm: work Tainted: G [ 31.686542] Nombre del hardware: riscv-virtio,qemu (DT) [ 31.686797] Rastreo de llamadas: [ 31.687053] [] dump_backtrace+0x30/0x38 [ 31.687699] [] show_stack+0x40/0x4c [ 31.688141] [] dump_stack_lvl+0x44/0x5c [ 31.688396] [] dump_stack+0x18/0x20 [ 31.688653] [] __might_resched+0x114/0x122 [ 31.688948] [] __might_sleep+0x50/0x7a [ 31.689435] [] down_read+0x30/0x130 [ 31.689728] [] do_page_fault+0x166/x446 [ 31.689997] [] ret_from_exception+0x0/0xc
Vulnerabilidad en kernel de Linux (CVE-2022-50226)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: ccp - Use kzalloc para interfaces sev ioctl para evitar fugas de memoria en el kernel Para algunas interfaces sev ioctl, se puede pasar una entrada menor o igual a SEV_FW_BLOB_MAX_SIZE, pero mayor que los datos que devuelve el firmware de PSP. En este caso, kmalloc asignará memoria que sea del tamaño de la entrada en lugar del tamaño de los datos. Dado que el firmware de PSP no sobrescribe completamente el búfer, las interfaces sev ioctl con el problema pueden devolver memoria slab sin inicializar. Actualmente, todas las interfaces ioctl en el controlador ccp son seguras, pero para evitar problemas futuros, cambie todas las interfaces ioctl que asignan memoria con kmalloc para usar kzalloc y memset el búfer de datos a cero en sev_ioctl_do_platform_status.
Vulnerabilidad en kernel de Linux (CVE-2022-50227)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86/xen: Inicializar el temporizador Xen solo una vez. Se ha añadido una comprobación de los temporizadores Xen existentes antes de inicializar uno nuevo. Actualmente, se llama a kvm_xen_init_timer() en cada KVM_XEN_VCPU_ATTR_TYPE_TIMER, lo que provoca el siguiente fallo de ODEBUG cuando vcpu->arch.xen.timer ya está configurado. ODEBUG: init activo (estado activo 0) tipo de objeto: hrtimer sugerencia: xen_timer_callbac0 RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:502 Seguimiento de llamadas: __debug_object_init debug_hrtimer_init debug_init hrtimer_init kvm_xen_init_timer kvm_xen_vcpu_set_attr kvm_arch_vcpu_ioctl kvm_vcpu_ioctl vfs_ioctl
Vulnerabilidad en kernel de Linux (CVE-2022-50228)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: SVM: No generar ERRORES si el espacio de usuario inyecta una interrupción con GIF=0 No generar ERRORES/ADVERTENCIAS en la inyección de interrupción debido a que se borra el GIF, ya que es trivial para el espacio de usuario forzar la situación a través de KVM_SET_VCPU_EVENTS (incluso si tener al menos un WARN allí sería correcto para las inyecciones generadas internamente por KVM). ¡ERROR del kernel en arch/x86/kvm/svm/svm.c:3386! Código de operación no válido: 0000 [#1] CPU SMP: 15 PID: 926 Comm: smm_test No contaminado 5.17.0-rc3+ #264 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_inject_irq+0xab/0xb0 [kvm_amd] Código: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53 RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0 RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 000000000000000 R10: 000000000000000 R11: 000000000000000 R12: 000000000000000 R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000 FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0 Rastreo de llamadas: inject_pending_event+0x2f7/0x4c0 [kvm] kvm_arch_vcpu_ioctl_run+0x791/0x17a0 [kvm] kvm_vcpu_ioctl+0x26d/0x650 [kvm] __x64_sys_ioctl+0x82/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae
Vulnerabilidad en kernel de Linux (CVE-2022-50229)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: bcd2000: corrige un error de UAF en la ruta de error del sondeo Cuando el controlador falla en snd_card_register() en el momento del sondeo, liberará 'bcd2k->midi_out_urb' antes de matarlo, lo que puede causar un error de UAF. El siguiente registro puede revelarlo: [ 50.727020] ERROR: KASAN: uso después de la liberación en bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000] [ 50.727623] Lectura de tamaño 8 en la dirección ffff88810fab0e88 por el intercambiador de tareas/4/0 [ 50.729530] Seguimiento de llamadas: [ 50.732899] bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000] Solucione esto agregando usb_kill_urb() antes de usb_free_urb().
Vulnerabilidad en kernel de Linux (CVE-2022-50230)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: establecer UXN en las tablas de páginas del intercambiador [Este problema se corrigió accidentalmente en c3cee924bd85 ("arm64: head: cubrir toda la imagen del kernel en el mapa de ID inicial") como parte de una refactorización a gran escala del flujo de arranque de arm64. Por lo tanto, esta sencilla solución es la preferida para la retroportación de -stable]. En un sistema que implementa FEAT_EPAN, se deniega el acceso de lectura/escritura al mapa de ID porque UXN no está establecido en las PTE del intercambiador. Como resultado, idmap_kpti_install_ng_mappings genera un pánico en el kernel al acceder a __idmap_kpti_flag. Se soluciona estableciendo UXN en estas PTE.
Vulnerabilidad en kernel de Linux (CVE-2022-50231)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: arm64/poly1305 - corrige una lectura fuera de los límites Se informó un error de kasan durante el fuzzing: BUG: KASAN: slab-out-of-bounds en neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] Lectura de tamaño 4 en la dirección ffff0010e293f010 por la tarea syz-executor.5/1646715 CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: cargado No contaminado 5.10.0.aarch64 #1 Nombre del hardware: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 31/01/2019 Rastreo de llamadas: dump_backtrace+0x0/0x394 show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [en línea] dump_stack+0x158/0x1e4 lib/dump_stack.c:118 print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387 __kasan_report+0xe0/0x140 mm/kasan/report.c:547 kasan_report+0x44/0xe0 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [en línea] __asan_load4+0x94/0xd0 mm/kasan/generic.c:252 neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] neon_poly1305_do_update+0x6c/0x15c [poly1305_neon] neon_poly1305_update+0x9c/0x1c4 [poly1305_neon] crypto_shash_update crypto/shash.c:131 [en línea] shash_finup_unaligned+0x84/0x15c crypto/shash.c:179 crypto_shash_finup+0x8c/0x140 crypto/shash.c:193 shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201 crypto_shash_digest+0xa4/0xfc crypto/shash.c:217 crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229 essiv_skcipher_setkey+0x164/0x200 [essiv] crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612 skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305 alg_setkey+0x114/0x2a0 crypto/af_alg.c:220 alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253 __sys_setsockopt+0x190/0x2e0 net/socket.c:2123 __do_sys_setsockopt net/socket.c:2134 [en línea] __se_sys_setsockopt net/socket.c:2131 [en línea] __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131 __invoke_syscall arch/arm64/kernel/syscall.c:36 [en línea] invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48 el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155 do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217 el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353 el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369 el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683 Este error se puede reproducir con el siguiente código compilado como ko en un sistema con kasan habilitado: #include #include #include #include char test_data[] = "\x00\x01\x02\x03\x04\x05\x06\x07" "\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f" "\x10\x11\x12\x13\x14\x15\x16\x17" "\x18\x19\x1a\x1b\x1c\x1d\x1e"; int init(void) { struct crypto_shash *tfm = NULL; char *data = NULL, *out = NULL; tfm = crypto_alloc_shash("poly1305", 0, 0); datos = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL); salida = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL); memcpy(datos, datos_de_prueba, POLY1305_KEY_SIZE - 1); crypto_shash_tfm_digest(tfm, datos, POLY1305_KEY_SIZE - 1, salida); kfree(data); kfree(out); return 0; } void deinit(void) { } module_init(init) module_exit(deinit) MODULE_LICENSE("GPL"); La causa raíz del error reside en neon_poly1305_blocks. La lógica de neon_poly1305_blocks() es que, si se invocó con s[] y r[] sin inicializar, primero intentará inicializarlos con los datos del primer "bloque", que se cree que tiene una longitud de 32 bytes. Los primeros 16 bytes se utilizan como clave y los siguientes para s[]. Esto provocaría la lectura fuera de los límites mencionada anteriormente. Sin embargo, tras invocar poly1305_init_arch(), solo se restaron 16 bytes de la entrada y s[] se inicializa de nuevo con los siguientes 16 bytes. La segunda inicialización de s[] es ciertamente redundante, lo que indica que la primera inicialización debería ser solo para r[]. Este parche corrige el problema llamando a poly1305_init_arm64() en lugar de truncated.
Vulnerabilidad en kernel de Linux (CVE-2022-50232)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: establecer UXN en las tablas de páginas del intercambiador [Este problema se corrigió accidentalmente en c3cee924bd85 ("arm64: head: cubrir toda la imagen del kernel en el mapa de ID inicial") como parte de una refactorización a gran escala del flujo de arranque de arm64. Por lo tanto, esta sencilla solución es la preferida para la retroportación de -stable]. En un sistema que implementa FEAT_EPAN, se deniega el acceso de lectura/escritura al mapa de ID porque UXN no está establecido en las PTE del intercambiador. Como resultado, idmap_kpti_install_ng_mappings genera un pánico en el kernel al acceder a __idmap_kpti_flag. Se soluciona estableciendo UXN en estas PTE.
Vulnerabilidad en kernel de Linux (CVE-2025-38087)
Severidad: ALTA
Fecha de publicación: 30/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: corrección del use-after-free en taprio_dev_notifier. Dado que taprio_dev_notifier() de taprio no está protegido por una sección crítica de lectura de RCU, una ejecución con advance_sched() puede provocar un use-after-free. Añadir rcu_read_lock() dentro de taprio_dev_notifier() evita esto.
Vulnerabilidad en kernel de Linux (CVE-2025-38089)
Severidad: MEDIA
Fecha de publicación: 30/06/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sunrpc: manejo de SVC_GARBAGE durante el procesamiento de autenticación de servicio como error de autenticación. Tianshuo Han informó de un fallo que se puede activar de forma remota si el cliente envía a un servidor RPC del kernel un paquete especialmente manipulado. Si la decodificación de la respuesta RPC falla de tal manera que se devuelve SVC_GARBAGE sin establecer el puntero rq_accept_statp, se puede desreferenciar ese puntero y almacenar un valor allí. Si es la primera vez que el hilo procesa una RPC, ese puntero se establecerá en NULL y el kernel se bloqueará. En otros casos, podría crear un garabato de memoria. El código del servidor sunrpc trata una devolución de SVC_GARBAGE de svc_authenticate o pg_authenticate como si debiera enviar una respuesta GARBAGE_ARGS. El RFC 5531 indica que si la autenticación falla, la RPC debe rechazarse con un estado de AUTH_ERR. Tratar una devolución de SVC_GARBAGE como AUTH_ERROR, con el motivo AUTH_BADCRED, en lugar de devolver GARBAGE_ARGS en ese caso. Esto evita el problema de tocar el puntero rpc_accept_statp en esta situación y evita el bloqueo.
Vulnerabilidad en kernel de Linux (CVE-2025-38238)
Severidad: MEDIA
Fecha de publicación: 09/07/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: fnic: Se corrige el fallo en fnic_wq_cmpl_handler cuando se agota el tiempo de espera de FDMI. Cuando se agota el tiempo de espera de las solicitudes FDMI de RHBA y RPA, fnic reutiliza una trama para enviar ABTS para cada una de ellas. Al completarse el envío, esto provoca un intento de liberar la misma trama dos veces, lo que provoca un fallo. Se corrige el fallo asignando tramas separadas para RHBA y RPA y modificando la lógica de ABTS según corresponda. Se probó verificando MDS para obtener información de FDMI. Se probó utilizando un controlador instrumentado para: - Descartar la respuesta PLOGI - Descartar la respuesta RHBA - Descartar la respuesta RPA - Descartar la respuesta RHBA y RPA - Descartar la respuesta PLOGI + respuesta ABTS - Descartar la respuesta RHBA + respuesta ABTS - Descartar la respuesta RPA + respuesta ABTS - Descartar la respuesta RHBA y RPA + respuesta ABTS para ambas.
Vulnerabilidad en kernel de Linux (CVE-2025-38241)
Severidad: MEDIA
Fecha de publicación: 09/07/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/shmem, swap: corregir bloqueo suave con swapin mTHP El siguiente bloqueo suave se puede reproducir fácilmente en mi máquina de prueba con: echo always > /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled swapon /dev/zram0 # zram0 es un dispositivo de intercambio de 48G mkdir -p /sys/fs/cgroup/memory/test echo 1G > /sys/fs/cgroup/test/memory.max echo $BASHPID > /sys/fs/cgroup/test/cgroup.procs while true; hacer dd if=/dev/zero of=/tmp/test.img bs=1M count=5120 cat /tmp/test.img > /dev/null rm /tmp/test.img done Luego de un rato: watchdog: BUG: bloqueo suave - ¡CPU#0 bloqueada durante 763 s! [cat:5787] Módulos vinculados: zram virtiofs CPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: cargado Contaminado: GL 6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntario)· Contaminado: [L]=SOFTLOCKUP Nombre del hardware: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015 RIP: 0010:mpol_shared_policy_lookup+0xd/0x70 Code: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 <48> 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8 RSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202 RAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001 RDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518 RBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001 R13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000 FS: 00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: shmem_alloc_folio+0x31/0xc0 shmem_swapin_folio+0x309/0xcf0 ? filemap_get_entry+0x117/0x1e0 ? xas_load+0xd/0xb0 ? filemap_get_entry+0x101/0x1e0 shmem_get_folio_gfp+0x2ed/0x5b0 shmem_file_read_iter+0x7f/0x2e0 vfs_read+0x252/0x330 ksys_read+0x68/0xf0 do_syscall_64+0x4c/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f03f9a46991 Code: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec RSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991 RDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003 RBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380 R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000 R13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000 La razón es simple, la lectura anticipada trajo algún folio de orden 0 en la caché de intercambio y El folio mTHP de intercambio que se está asignando entra en conflicto con él, por lo que swapcache_prepare falla y provoca que shmem_swap_alloc_folio devuelva -EEXIST, y shmem simplemente reintenta una y otra vez, causando este bucle. Se puede solucionar aplicando una solución similar para el intercambio mTHP anónimo. El cambio de rendimiento es muy leve; tiempo de intercambio 10g cero folios con shmem (prueba realizada 12 veces): Antes: 2.47 s Después: 2.48 s [kasong@tencent.com: añadir comentario]
Vulnerabilidad en kernel de Linux (CVE-2025-38242)
Severidad: MEDIA
Fecha de publicación: 09/07/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: userfaultfd: corrige la ejecución de userfaultfd_move y la caché de intercambio. Esta confirmación corrige dos tipos de ejecuciones, pueden tener resultados diferentes: Barry informó un BUG_ON en el commit c50f8e6053b0, podemos ver el mismo BUG_ON si la búsqueda del mapa de archivos devolvió NULL y folio se agrega a la caché de intercambio después de eso. Si se activa otro tipo de ejecución (folio modificado tras la búsqueda), es posible que el contador RSS esté dañado: [406.893936] ERROR: Estado incorrecto del contador RSS mm:ffff0000c5a9ddc0 tipo:MM_ANONPAGES val:-1 [406.894071] ERROR: Estado incorrecto del contador RSS mm:ffff0000c5a9ddc0 tipo:MM_SHMEMPAGES val:1 Porque el folio se está contabilizando en la VMA incorrecta. No estoy seguro de si habrá alguna corrupción de datos, aunque parece que no. Los problemas anteriores ya son críticos. Al ver un PTE de entrada de intercambio, userfaultfd_move realiza una búsqueda de caché de intercambio sin bloqueo e intenta mover el folio encontrado a la VMA que falla. Actualmente, se basa en la comprobación del valor de PTE para garantizar que el folio movido siga perteneciendo a la entrada de intercambio src y que no se haya añadido ningún folio nuevo a la caché de intercambio, lo cual resulta poco fiable. Al trabajar y revisar la serie de tablas de intercambio con Barry, se observan y reproducen las siguientes ejecuciones existentes [1]: En el siguiente ejemplo, move_pages_pte mueve src_pte a dst_pte, donde src_pte es una PTE de entrada de intercambio que contiene la entrada de intercambio S1, y S1 no está en la caché de intercambio: CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // Aquí tiene entrada = S1 ... ... // folio A es un nuevo folio asignado // y se instala en src_pte // src_pte ahora apunta al folio A, S1 // tiene conteo de intercambio == 0, puede liberarse // mediante folio_swap_swap o la recuperación del asignador de intercambio. // folio B es un folio en otro VMA. // S1 se libera, el folio B puede usarlo // para intercambiar sin problemas. ... folio = filemap_get_folio(S1) // ¡¡¡Tengo el folio B aquí!!! ... ... // Ahora S1 está libre para volver a usarse. // Ahora src_pte es una entrada de intercambio PTE // que mantiene S1 de nuevo. folio_trylock(folio) move_swap_pte double_pt_lock is_pte_pages_stable // Comprobación aprobada porque src_pte == S1 folio_move_anon_rmap(...) // ¡¡¡Se movió el folio B inválido aquí!!! La ventana de ejecución es muy corta y requiere múltiples colisiones de múltiples eventos raros, por lo que es muy improbable que suceda, pero con un reproductor construido deliberadamente y una ventana de tiempo mayor, se puede reproducir fácilmente. Esto se puede arreglar comprobando si el folio devuelto por filemap es el folio de caché de intercambio válido después de adquirir el bloqueo de folio. Otra ejecución similar es posible: filemap_get_folio puede devolver NULL, pero el folio (A) podría intercambiarse dentro y fuera de nuevo usando la misma entrada de intercambio después de la búsqueda. En tal caso, el folio (A) puede permanecer en el caché de intercambio, por lo que también debe moverse: CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // Aquí obtuvo entry = S1, y S1 no está en el caché de intercambio folio = filemap_get ---truncated---
Vulnerabilidad en kernel de Linux (CVE-2025-38243)
Severidad: MEDIA
Fecha de publicación: 09/07/2025
Fecha de última actualización: 19/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de desreferencias de punteros inodos no válidos durante la reproducción de registros. En algunos casos, al ejecutar read_one_inode(), si se obtiene un puntero nulo, se accede a una ruta de error o a una ruta de paso en el caso de __add_inode_ref(). En este caso, se realiza algo como: iput(&inode->vfs_inode);, lo que genera un puntero inodo no válido que desencadena un acceso no válido a memoria y provoca un fallo. Para solucionar esto, es necesario asegurarse de no realizar dichas desreferencias.