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 pages.php en el complemento Custom Pages para MyBulletinBoard (CVE-2008-6198)
Severidad: Pendiente de análisis
Fecha de publicación: 20/02/2009
Fecha de última actualización: 26/09/2025
Vulnerabilidad de inyección SQL en pages.php en el complemento Custom Pages v1.0 para MyBulletinBoard (MyBB), permite a atacantes remotos ejecutar comandos SQL de su elección a través del parámetro "page".
Vulnerabilidad en MyBB (CVE-2008-7082)
Severidad: Pendiente de análisis
Fecha de publicación: 25/08/2009
Fecha de última actualización: 26/09/2025
MyBB (también conocido como MyBulletinBoard) v1.4.3 incluye el parámetro "my_post_key" en URLs en moderation.php con las acciones (1) "mergeposts", (2) "split", y (3) "deleteposts", lo que permitiría a atacantes remotos robar la credencial de autenticación y evitar la protección de falsificación de petición en sitios cruzados (CSRF) y secuestrar la autenticación de los moderadores mediante la lectura de la credencial de autenticación de la cabecera HTTP.
Vulnerabilidad en myps.php en MyBB (CVE-2009-4813)
Severidad: Pendiente de análisis
Fecha de publicación: 27/04/2010
Fecha de última actualización: 26/09/2025
Vulnerabilidad de secuencias de comandos en sitios cruzados (XSS) en myps.php en MyBB (también conocido como MyBulletinBoard) 1.4.10 permite a atacantes remotos inyectar secuencias de comandos web o HTML de su elección a través del parámetro "username" en una acción "donate".
Vulnerabilidad en incfunctions_time.php en MyBB (CVE-2009-4448)
Severidad: Pendiente de análisis
Fecha de publicación: 29/12/2009
Fecha de última actualización: 26/09/2025
inc/functions_time.php en MyBB (alias MyBulletinBoard) v1.4.10, y posiblemente versiones anteriores, permite a atacantes remotos provocar una denegación de servicio (consumo de CPU) mediante una solicitud elaborada con un gran valor para el año, lo que dispara un bucle largo, como puede conseguirse a través de member.php y posiblemente otros vectores.
Vulnerabilidad en MyBB (MyBulletinBoard) (CVE-2009-4449)
Severidad: MEDIA
Fecha de publicación: 29/12/2009
Fecha de última actualización: 26/09/2025
Vulnerabilidad de salto de directorio en MyBB (MyBulletinBoard) v1.4.10, y posiblemente versiones anteriores. Cuando se cambia el avatar de usuario desde la galería, permite a usuarios remotos autenticados determinar la existencia de ficheros a través de secuencias de salto de directorio en el avatar y posiblemente los parámetros de la galería. Relacionado con (1) admin/modules/user/users.php y (2) usercp.php.
Vulnerabilidad en MyBB (CVE-2010-5096)
Severidad: Pendiente de análisis
Fecha de publicación: 13/08/2012
Fecha de última actualización: 26/09/2025
** EN DISPUTA ** Múltiples vulnerabilidades de inyección SQL en MyBB (también conocido como MyBulletinBoard) antes de v1.6.1 permite a atacantes remotos ejecutar comandos SQL a través del parámetro 'keywords' de una acción (1) do_search a search.php o (2) una acción do_stuff a private.php. NOTA: El vendedor rechaza este problema diciendo que "...aunque esto no conduce a una inyección de SQL, sí que provoca un error de genérico de MyBB de SQL Server".
Vulnerabilidad en gpac (CVE-2023-46426)
Severidad: ALTA
Fecha de publicación: 09/03/2024
Fecha de última actualización: 26/09/2025
Vulnerabilidad de desbordamiento de búfer de almacenamiento dinámico en gpac versión 2.3-DEV-rev588-g7edc40fee-master, permite a atacantes remotos ejecutar código arbitrario y provocar una denegación de servicio (DoS) a través del componente gf_fwrite en utils/os_file.c.
Vulnerabilidad en gpac (CVE-2023-46427)
Severidad: CRÍTICA
Fecha de publicación: 09/03/2024
Fecha de última actualización: 26/09/2025
Se descubrió un problema en gpac versión 2.3-DEV-rev588-g7edc40fee-master, que permite a atacantes remotos ejecutar código arbitrario, provocar una denegación de servicio (DoS) y obtener información confidencial a través de la deferencia de puntero nulo en el componente gf_dash_setup_period en media_tools/dash_client. C.
Vulnerabilidad en Palo Alto Networks GlobalProtect (CVE-2024-2431)
Severidad: MEDIA
Fecha de publicación: 13/03/2024
Fecha de última actualización: 26/09/2025
Un problema en la aplicación Palo Alto Networks GlobalProtect permite a un usuario sin privilegios deshabilitar la aplicación GlobalProtect en configuraciones que permiten a un usuario deshabilitar GlobalProtect con un código de acceso.
Vulnerabilidad en Palo Alto Networks GlobalProtect (CVE-2024-2432)
Severidad: MEDIA
Fecha de publicación: 13/03/2024
Fecha de última actualización: 26/09/2025
Una vulnerabilidad de escalada de privilegios (PE) en la aplicación Palo Alto Networks GlobalProtect en dispositivos Windows permite a un usuario local ejecutar programas con privilegios elevados. Sin embargo, la ejecución requiere que el usuario local pueda aprovechar con éxito una condición de ejecución.
Vulnerabilidad en gpac 2.3-DEV-rev921-g422b78ecf-master (CVE-2024-28318)
Severidad: ALTA
Fecha de publicación: 15/03/2024
Fecha de última actualización: 26/09/2025
Se descubrió que gpac 2.3-DEV-rev921-g422b78ecf-master contiene una vulnerabilidad de escritura fuera de los límites a través de swf_get_string en scene_manager/swf_parse.c:325
Vulnerabilidad en gpac 2.3-DEV-rev921-g422b78ecf-master (CVE-2024-28319)
Severidad: MEDIA
Fecha de publicación: 15/03/2024
Fecha de última actualización: 26/09/2025
Se descubrió que gpac 2.3-DEV-rev921-g422b78ecf-master contiene una vulnerabilidad de lectura fuera de los límites a través de gf_dash_setup_period media_tools/dash_client.c:6374
Vulnerabilidad en kernel de Linux (CVE-2022-48664)
Severidad: MEDIA
Fecha de publicación: 28/04/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige el bloqueo durante el desmontaje al detener un trabajador de recuperación de espacio. A menudo, cuando ejecutamos generic/562 desde fstests, podemos bloquearnos durante el desmontaje, lo que resulta en un rastro como este: 07 de septiembre 11:52 :00 debian9 desconocido: ejecute fstests generic/562 el 07/09/2022 11:52:00 07 de septiembre 11:55:32 kernel debian9: INFORMACIÓN: tarea umount:49438 bloqueada durante más de 120 segundos. 07 de septiembre 11:55:32 kernel debian9: no contaminado 6.0.0-rc2-btrfs-next-122 #1 07 de septiembre 11:55:32 kernel debian9: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva esto mensaje. 07 de septiembre 11:55:32 kernel debian9: tarea: estado de montaje: D pila: 0 pid:49438 ppid: 25683 banderas:0x00004000 07 de septiembre 11:55:32 kernel de debian9: Seguimiento de llamadas: 07 de septiembre 11:55:32 kernel de debian9 : 07 de septiembre 11:55:32 kernel debian9: __schedule+0x3c8/0xec0 07 de septiembre 11:55:32 kernel debian9: ? rcu_read_lock_sched_held+0x12/0x70 07 de septiembre 11:55:32 kernel debian9: horario+0x5d/0xf0 07 de septiembre 11:55:32 kernel debian9: Schedule_timeout+0xf1/0x130 07 de septiembre 11:55:32 kernel debian9:? lock_release+0x224/0x4a0 7 de septiembre 11:55:32 kernel debian9:? lock_acquired+0x1a0/0x420 7 de septiembre 11:55:32 kernel debian9:? trace_hardirqs_on+0x2c/0xd0 07 de septiembre 11:55:32 kernel debian9: __wait_for_common+0xac/0x200 07 de septiembre 11:55:32 kernel debian9:? usleep_range_state+0xb0/0xb0 07 de septiembre 11:55:32 kernel debian9: __flush_work+0x26d/0x530 07 de septiembre 11:55:32 kernel debian9:? Flush_workqueue_prep_pwqs+0x140/0x140 7 de septiembre 11:55:32 kernel debian9:? trace_clock_local+0xc/0x30 7 de septiembre 11:55:32 kernel debian9: __cancel_work_timer+0x11f/0x1b0 7 de septiembre 11:55:32 kernel debian9:? close_ctree+0x12b/0x5b3 [btrfs] 07 de septiembre 11:55:32 kernel debian9:? __trace_bputs+0x10b/0x170 07 de septiembre 11:55:32 kernel debian9: close_ctree+0x152/0x5b3 [btrfs] 07 de septiembre 11:55:32 kernel debian9:? evict_inodes+0x166/0x1c0 07 de septiembre 11:55:32 kernel debian9: generic_shutdown_super+0x71/0x120 07 de septiembre 11:55:32 kernel debian9: kill_anon_super+0x14/0x30 07 de septiembre 11:55:32 kernel debian9: 0 [btrfs] 07 de septiembre 11:55:32 kernel debian9: desactivar_locked_super+0x2e/0xa0 07 de septiembre 11:55:32 kernel debian9: cleanup_mnt+0x100/0x160 07 de septiembre 11:55:32 kernel de debian9: task_work_run+0x59/0xa0 07 de septiembre 11:55:32 kernel debian9: exit_to_user_mode_prepare+0x1a6/0x1b0 07 de septiembre 11:55:32 kernel debian9: syscall_exit_to_user_mode+0x16/0x40 07 de septiembre 11:55:32 kernel de debian9: do_syscall_64+0x48/0x90 07 de septiembre: 55:32 kernel debian9: Entry_SYSCALL_64_after_hwframe+0x63/0xcd 07 de septiembre 11:55:32 kernel debian9: RIP: 0033:0x7fcde59a57a7 07 de septiembre 11:55:32 kernel debian9: RSP: 002b:00007ffe914217c8 EFLAGS: ORIG_RAX: 00000000000000a6 07 de septiembre 11:55: 32 kernel debian9: RAX: 0000000000000000 RBX: 00007fcde5ae8264 RCX: 00007fcde59a57a7 07 de septiembre 11:55:32 kernel debian9: RDX: 0000000000000000 RSI: 00 RDI: 000055b57556cdd0 07 de septiembre 11:55:32 kernel debian9: RBP: 000055b57556cba0 R08: 0000000000000000 R09: 00007ffe91420570 07 de septiembre 11:55:32 kernel debian9: R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000000000 07 de septiembre 11:55:32 kernel debian9: R13: 55b57556cdd0 R14: 000055b57556ccb8 R15: 0000000000000000 7 de septiembre 11:55:32 kernel debian9: < /TASK> Lo que sucede es lo siguiente: 1) El kthread limpiador intenta iniciar una transacción para eliminar un grupo de bloques no utilizado, pero la reserva de metadatos no se puede satisfacer de inmediato, por lo que se crea un ticket de reserva e inicia la recuperación asíncrona de metadatos---truncadas---
Vulnerabilidad en Ecommerce-CodeIgniter-Bootstrap (CVE-2024-31823)
Severidad: ALTA
Fecha de publicación: 29/04/2024
Fecha de última actualización: 26/09/2025
Un problema en el commit Ecommerce-CodeIgniter-Bootstrap v. d22b54e8915f167a135046ceb857caaf8479c4da permite a un atacante remoto ejecutar código arbitrario a través del método removeSecondaryImage del componente Publish.php.
Vulnerabilidad en iPerf3 (CVE-2024-26306)
Severidad: MEDIA
Fecha de publicación: 14/05/2024
Fecha de última actualización: 26/09/2025
iPerf3 anterior a 3.17, cuando se usa con OpenSSL anterior a 3.2.0 como servidor con autenticación RSA, permite un canal lateral de temporización en las operaciones de descifrado RSA. Este canal lateral podría ser suficiente para que un atacante recupere el texto sin formato de las credenciales. Requiere que el atacante envíe una gran cantidad de mensajes para descifrarlos, como se describe en "Everlasting ROBOT: the Marvin Attack" de Hubert Kario.
Vulnerabilidad en kernel de Linux (CVE-2024-43867)
Severidad: MEDIA
Fecha de publicación: 21/08/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau: prime: corrige el desbordamiento insuficiente de refcount Llamar a nouveau_bo_ref() en un nouveau_bo sin inicializarlo (y por lo tanto el ttm_bo de respaldo) conduce a un desbordamiento insuficiente de refcount. En lugar de llamar a nouveau_bo_ref() en la ruta de desenredado de drm_gem_object_init(), limpie las cosas manualmente. (cereza escogida del commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)
Vulnerabilidad en kernel de Linux (CVE-2024-43869)
Severidad: MEDIA
Fecha de publicación: 21/08/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf: corrige la fuga de eventos al liberar el archivo y el ejecutable. El trabajo de la tarea pendiente de rendimiento nunca se espera hasta que se libere el evento correspondiente. En el caso de un evento secundario, publicado directamente a través de free_event(), esto puede potencialmente resultar en un evento filtrado, como en el siguiente escenario que ni siquiera requiere una implementación de trabajo IRQ débil para activarse: Schedule() prepare_task_switch() =======> perf_event_overflow() evento->pending_sigtrap = ... irq_work_queue(&event->pending_irq) <======= perf_event_task_sched_out() event_sched_out() evento-> pendiente_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) task_work_add(&event->pending_task) Finish_lock_switch() =======> perf_pending_irq() //no hacer nada, confiar en el trabajo de la tarea pendiente <======= < /IRQ> comenzar_new_exec() perf_event_exit_task() perf_event_exit_event() // Si es un evento secundario free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) // el evento se filtró También pueden ocurrir escenarios similares con perf_event_remove_on_exec () o simplemente contra perf_event_release() concurrente. Solucione este problema sincronizando con el trabajo de tarea pendiente posiblemente restante mientras se libera el evento, tal como se hace con el trabajo de IRQ pendiente restante. Esto significa que la devolución de llamada de la tarea pendiente no necesita ni debe contener una referencia al evento, lo que impide que se libere.
Vulnerabilidad en kernel de Linux (CVE-2024-43870)
Severidad: MEDIA
Fecha de publicación: 21/08/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf: corrige la fuga de eventos al salir Cuando se programa una tarea, las entregas de sigtrap pendientes se difieren a la tarea de destino al reanudarse en el espacio de usuario a través de task_work. Sin embargo, se ignoran los fallos al agregar la devolución de llamada de un evento al motor task_work. Y dado que la última llamada para la salida de eventos ocurre después de que finalmente se cierra el trabajo de la tarea, hay una pequeña ventana durante la cual el sigtrap pendiente se puede poner en cola aunque se ignore, lo que filtra la adición del recuento de eventos, como en el siguiente escenario: TAREA A ----- do_exit() salida_task_work(tsk); perf_event_overflow() evento->pending_sigtrap = pendiente_id; irq_work_queue(&event->pending_irq); =========> PREEMPCIÓN: TAREA A -> TAREA B event_sched_out() evento->pending_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) // FALLA: el trabajo de la tarea ha salido task_work_add(&event->pending_task) [...] perf_pending_irq() // retorno temprano: evento->oncpu = -1 [...] =========> TAREA B -> TAREA A perf_event_exit_task(tsk) perf_event_exit_event() free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) / /evento de fuga debido a un recuento inesperado == 2 Como resultado, el evento nunca se libera mientras la tarea finaliza. Solucione este problema con el manejo de errores apropiado de task_work_add().
Vulnerabilidad en kernel de Linux (CVE-2024-43875)
Severidad: MEDIA
Fecha de publicación: 21/08/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: endpoint: limpieza del manejo de errores en vpci_scan_bus() Smatch se queja de una verificación NULL inconsistente en vpci_scan_bus(): drivers/pci/endpoint/functions/pci-epf-vntb.c :1024 Error de vpci_scan_bus(): anteriormente asumimos que 'vpci_bus' podría ser nulo (consulte la línea 1021). En lugar de imprimir un mensaje de error y luego fallar, deberíamos devolver un código de error y limpiar. Además, la verificación NULL se invierte, por lo que imprime un error de éxito en lugar de fracaso.
Vulnerabilidad en kernel de Linux (CVE-2024-43877)
Severidad: ALTA
Fecha de publicación: 21/08/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: pci: ivtv: Agregar verificación para el resultado del mapa DMA En caso de que DMA falle, 'dma->SG_length' es 0. Este valor se usa luego para acceder a 'dma->SGarray [dma->SG_length - 1]', lo que provocará un acceso fuera de los límites. Agregue un cheque para devolver anticipadamente un valor no válido. Ajuste las advertencias en consecuencia. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.
Vulnerabilidad en kernel de Linux (CVE-2024-43878)
Severidad: ALTA
Fecha de publicación: 21/08/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: corrige el error de acceso a la memoria de la ruta de entrada Cuando hay una mala configuración del estado de entrada, la ruta lenta KASAN informa el error. Corrija este error. inicio de sesión oeste: [52.987278] eth1: renombrado de veth11 [53.078814] eth1: renombrado de veth21 [53.181355] eth1: renombrado de veth31 [54.921702] ===================== =============================================== [ 54.922602] ERROR : KASAN: acceso a memoria salvaje en xfrmi_rcv_cb+0x2d/0x295 [ 54.923393] Lectura de tamaño 8 en la dirección 6b6b6b6b00000000 mediante tarea ping/512 [ 54.924169] [ 54.924386] CPU: 0 PID: 512 Comm: ping No contaminado 6. 9.0- 08574-gcd29a4313a1b #25 [ 54.925290] Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 [ 54.926401] Seguimiento de llamadas: [ 54.926731] [54.927009] dump_stack_lvl+0x2a/0x3b [54.927478] kasan_report+0x84/0xa6 [54.927930]? xfrmi_rcv_cb+0x2d/0x295 [ 54.928410] xfrmi_rcv_cb+0x2d/0x295 [ 54.928872] ? xfrm4_rcv_cb+0x3d/0x5e [ 54.929354] xfrm4_rcv_cb+0x46/0x5e [ 54.929804] xfrm_rcv_cb+0x7e/0xa1 [ 54.930240] xfrm_input+0x1b3a/0x1b96 [ 54.930715] ? xfrm_offload+0x41/0x41 [54.931182]? raw_rcv+0x292/0x292 [54.931617]? nf_conntrack_confirm+0xa2/0xa2 [54.932158]? skb_sec_path+0xd/0x3f [54.932610]? xfrmi_input+0x90/0xce [ 54.933066] xfrm4_esp_rcv+0x33/0x54 [ 54.933521] ip_protocol_deliver_rcu+0xd7/0x1b2 [ 54.934089] ip_local_deliver_finish+0x110/0x120 [ 54.93 4659] ? ip_protocol_deliver_rcu+0x1b2/0x1b2 [ 54.935248] NF_HOOK.constprop.0+0xf8/0x138 [ 54.935767] ? ip_sublist_rcv_finish+0x68/0x68 [54.936317]? ¿secure_tcpv6_ts_off+0x23/0x168 [54.936859]? ip_protocol_deliver_rcu+0x1b2/0x1b2 [54.937454]? __xfrm_policy_check2.constprop.0+0x18d/0x18d [ 54.938135] NF_HOOK.constprop.0+0xf8/0x138 [ 54.938663] ? ip_sublist_rcv_finish+0x68/0x68 [54.939220]? __xfrm_policy_check2.constprop.0+0x18d/0x18d [54.939904]? ip_local_deliver_finish+0x120/0x120 [ 54.940497] __netif_receive_skb_one_core+0xc9/0x107 [ 54.941121] ? __netif_receive_skb_list_core+0x1c2/0x1c2 [54.941771]? blk_mq_start_stopped_hw_queues+0xc7/0xf9 [54.942413]? blk_mq_start_stopped_hw_queue+0x38/0x38 [54.943044]? virtqueue_get_buf_ctx+0x295/0x46b [ 54.943618] Process_backlog+0xb3/0x187 [ 54.944102] __napi_poll.constprop.0+0x57/0x1a7 [ 54.944669] net_rx_action+0x1cb/0x380 [ 54.94 5150] ? __napi_poll.constprop.0+0x1a7/0x1a7 [54.945744]? vring_new_virtqueue+0x17a/0x17a [54.946300]? note_interrupt+0x2cd/0x367 [ 54.946805] handle_softirqs+0x13c/0x2c9 [ 54.947300] do_softirq+0x5f/0x7d [ 54.947727] [ 54.948014] [ 54.948300] _enable_ip+0x48/0x62 [ 54.948832] __neigh_event_send+0x3fd/0x4ca [ 54.949361] neigh_resolve_output+0x1e/0x210 [ 54.949896] ip_finish_output2+0x4bf/0x4f0 [ 54.950410] ? __ip_finish_output+0x171/0x1b8 [ 54.950956] ip_send_skb+0x25/0x57 [ 54.951390] raw_sendmsg+0xf95/0x10c0 [ 54.951850] ? check_new_pages+0x45/0x71 [ 54.952343] ? raw_hash_sk+0x21b/0x21b [54.952815]? kernel_init_pages+0x42/0x51 [54.953337]? prep_new_page+0x44/0x51 [54.953811]? get_page_from_freelist+0x72b/0x915 [54.954390]? signal_pending_state+0x77/0x77 [54.954936]? preempt_count_sub+0x14/0xb3 [54.955450]? __might_resched+0x8a/0x240 [ 54.955951] ? __might_sleep+0x25/0xa0 [ 54.956424] ? first_zones_zonelist+0x2c/0x43 [ 54.956977] ? __rcu_read_lock+0x2d/0x3a [ 54.957476] ? __pte_offset_map+0x32/0xa4 [54.957980]? __might_resched+0x8a/0x240 [ 54.958483] ? __might_sleep+0x25/0xa0 [ 54.958963] ? inet_send_prepare+0x54/0x54 [54.959478]? sock_sendmsg_nosec+0x42/0x6c [ 54.960000] sock_sendmsg_nosec+0x42/0x6c [ 54.960502] __sys_sendto+0x15d/0x1cc [ 54.960966] ? __x64_sys_getpeername+0x44/0x44 [ 54.961522] ? __handle_mm_fault+0x679/0xae4 [ 54.962068] ? find_vma+0x6b/0x ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2024-43880)
Severidad: MEDIA
Fecha de publicación: 21/08/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: espectro_acl_erp: corrige la advertencia de anidamiento de objetos. Las ACL en Spectrum-2 y los ASIC más nuevos pueden residir en el TCAM algorítmico (A-TCAM) o en el TCAM de circuito ordinario (C-TCAM). El primero puede contener más ACL (es decir, filtros tc), pero el número de máscaras en cada región (es decir, cadena tc) es limitado. Para mitigar los efectos de la limitación anterior, el dispositivo permite que los filtros compartan una única máscara si sus máscaras solo difieren en hasta 8 bits consecutivos. Por ejemplo, dst_ip/25 se puede representar usando dst_ip/24 con un delta de 1 bit. C-TCAM no tiene un límite en la cantidad de máscaras que se utilizan (y por lo tanto no admite la agregación de máscaras), pero puede contener una cantidad limitada de filtros. El controlador utiliza la librería "objagg" para realizar la agregación de máscaras pasándole objetos que constan de la máscara del filtro y si el filtro se insertará en la A-TCAM o en la C-TCAM, ya que los filtros en diferentes TCAM no pueden compartir una máscara. El conjunto de objetos creados depende del orden de inserción de los filtros y no es necesariamente óptimo. Por lo tanto, el controlador solicitará periódicamente a la librería que calcule un conjunto más óptimo ("sugerencias") observando todos los objetos existentes. Cuando la librería pregunta al controlador si se pueden agregar dos objetos, el controlador solo compara las máscaras proporcionadas e ignora la indicación A-TCAM/C-TCAM. Esto es lo correcto ya que el objetivo es mover tantos filtros como sea posible a la A-TCAM. El driver también prohíbe agregar dos máscaras idénticas, ya que esto solo puede suceder si una se colocó intencionalmente en la C-TCAM para evitar un conflicto en la A-TCAM. Lo anterior puede dar como resultado el siguiente conjunto de sugerencias: H1: {máscara X, A-TCAM} -> H2: {máscara Y, A-TCAM} // X es Y + delta H3: {máscara Y, C-TCAM} -> H4: {máscara Z, A-TCAM} // Y es Z + delta Después de obtener las sugerencias de la librería, el controlador comenzará a migrar filtros de una región a otra mientras consulta las sugerencias calculadas e indica al dispositivo que realice una búsqueda. en ambas regiones durante la transición. Suponiendo que se está migrando un filtro con máscara X a la A-TCAM en la nueva región, la búsqueda de sugerencias devolverá H1. Dado que H2 es el padre de H1, la librería intentará encontrar el objeto asociado con él y crearlo si es necesario, en cuyo caso se realizará otra búsqueda de sugerencias (recursiva). Esta búsqueda de sugerencias para {máscara Y, A-TCAM} devolverá H2 o H3 ya que el controlador pasa a la librería una función de comparación de objetos que ignora la indicación A-TCAM/C-TCAM. En última instancia, esto puede conducir a objetos anidados que no son compatibles con la librería [1]. Para solucionarlo, elimine la función de comparación de objetos tanto del controlador como de la librería, ya que el controlador era el único usuario. De esa forma, la búsqueda solo arrojará coincidencias exactas. No tengo un reproductor confiable que pueda reproducir el problema de manera oportuna, pero antes de solucionarlo, el problema se reproducía en varios minutos y con la solución no se reproduce en más de una hora. Tenga en cuenta que la utilidad actual de las sugerencias es limitada porque incluyen la indicación C-TCAM y representan una agregación que en realidad no puede ocurrir. Esto se abordará en net-next. [1] ADVERTENCIA: CPU: 0 PID: 153 en lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0 Módulos vinculados en: CPU: 0 PID: 153 Comm: kworker/0:18 No contaminado 6.9.0-rc6-custom -g70fbc2c1c38b #42 Nombre del hardware: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018 Cola de trabajo: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:objagg_obj_parent_assign+0xb5/0xd0 [...] Seguimiento de llamadas: < TAREA> ---truncado----
Vulnerabilidad en kernel de Linux (CVE-2024-43881)
Severidad: ALTA
Fecha de publicación: 21/08/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: ath12k: cambia la dirección de DMA al mapear paquetes reinyectados. Para paquetes fragmentados, ath12k vuelve a ensamblar cada fragmento como un paquete normal y luego lo reinyecta en el anillo HW. En este caso, la dirección DMA debe ser DMA_TO_DEVICE, no DMA_FROM_DEVICE. De lo contrario, se puede reinyectar una carga útil no válida en el HW y posteriormente entregarla al host. Dado que se puede asignar memoria arbitraria al búfer skb, falta conocimiento sobre los datos contenidos en el búfer reinyectado. En consecuencia, existe el riesgo de que se filtre información privada. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1
Vulnerabilidad en kernel de Linux (CVE-2022-48883)
Severidad: ALTA
Fecha de publicación: 21/08/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: IPoIB, bloquea interfaces PKEY con menos colas de recepción que las principales. Un usuario puede configurar un número arbitrario de colas de recepción al crear una interfaz a través de netlink. Esto no funciona para interfaces PKEY secundarias porque la interfaz secundaria utiliza los canales de recepción principales. Aunque el niño comparte los canales de recepción de los padres, la cantidad de colas de recepción es importante para la matriz channel_stats: el índice del canal de recepción de los padres se usa para acceder a los channel_stats del niño. Por lo tanto, la matriz debe ser al menos tan grande como el tamaño de la cola de recepción principal para que el recuento funcione correctamente y evitar accesos fuera de los límites. Este parche comprueba el escenario mencionado y devuelve un error al intentar crear la interfaz. El error se propaga al usuario.
Vulnerabilidad en kernel de Linux (CVE-2023-52916)
Severidad: ALTA
Fecha de publicación: 06/09/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: aspeed: corrige la sobrescritura de memoria si el tiempo es 1600x900 Al capturar 1600x900, el sistema podría bloquearse cuando el uso de la memoria del sistema es ajustado. La forma de reproducir este problema: 1. Use 1600x900 para mostrar en el host 2. Monte ISO a través de 'Medios virtuales' en la web de OpenBMC 3. Ejecute el script como se muestra a continuación en el host para hacer sha continuamente #!/bin/bash while [ [1] ]; do find /media -type f -printf '"%h/%f"\n' | xargs sha256sum done 4. Abra KVM en la web de OpenBMC El tamaño del bloque de macro capturado es 8x8. Por lo tanto, debemos asegurarnos de que la altura de src-buf esté alineada con 8 para solucionar este problema.
Vulnerabilidad en kernel de Linux (CVE-2024-46713)
Severidad: ALTA
Fecha de publicación: 13/09/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/aux: Se corrige la serialización del búfer AUX. Ole informó que event->mmap_mutex es estrictamente insuficiente para serializar el búfer AUX, agregue un mutex por RB para serializarlo por completo. Tenga en cuenta que en el comentario de orden de bloqueo, el orden perf_event::mmap_mutex ya estaba mal, es decir, su anidación bajo mmap_lock no es nueva con este parche.
Vulnerabilidad en kernel de Linux (CVE-2024-46729)
Severidad: ALTA
Fecha de publicación: 18/09/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se corrige el cálculo incorrecto del tamaño del bucle [POR QUÉ] fe_clk_en tiene un tamaño de 5, pero sizeof(fe_clk_en) tiene un tamaño de byte de 20, que es mayor que el tamaño de la matriz. [CÓMO] Se divide el tamaño de byte 20 por el tamaño de su elemento. Esto corrige 2 problemas de OVERRUN informados por Coverity.
Vulnerabilidad en kernel de Linux (CVE-2024-46733)
Severidad: MEDIA
Fecha de publicación: 18/09/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: reparar fugas de reserva de qgroup en cow_file_range En la ruta de escritura en búfer, la página sucia posee la reserva de qgroup hasta que crea una ordered_extent. Por lo tanto, cualquier error que ocurra antes de que se cree la ordered_extent debe liberar esa reserva, o de lo contrario se pierde el espacio. El fstest generic/475 ejercita varias rutas de error de E/S y puede desencadenar errores en cow_file_range donde no logramos asignar la extensión ordenada. Tenga en cuenta que debido a que *sí* borramos delalloc, es probable que eliminemos el inodo de la lista de delalloc, por lo que los inodos/páginas no tienen una llamada de invalidación/lavado en ellos en la ruta de aborto de confirmación. Esto genera fallas en la etapa de desmontaje de la prueba que se ven así: BTRFS: error (dispositivo dm-8 estado EA) en cleanup_transaction:2018: errno=-5 falla de E/S BTRFS: error (dispositivo dm-8 estado EA) en btrfs_replace_file_extents:2416: errno=-5 falla de E/S Advertencia de BTRFS (dispositivo dm-8 estado EA): qgroup 0/5 tiene espacio sin liberar, tipo 0 rsv 28672 ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 3 PID: 22588 en fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs] Módulos vinculados en: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq CPU: 3 PID: 22588 Comm: umount Kdump: cargado Tainted: GW 6.10.0-rc7-gab56fde445b8 #21 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 01/04/2014 RIP: 0010:close_ctree+0x222/0x4d0 [btrfs] RSP: 0018:ffffb4465283be00 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8 RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000 R10: 000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c R13: 000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0 Seguimiento de llamadas: ? close_ctree+0x222/0x4d0 [btrfs] ? __warn.cold+0x8e/0xea ? close_ctree+0x222/0x4d0 [btrfs] ? reportar_error+0xff/0x140 ? manejar_error+0x3b/0x70 ? exc_op_inválida+0x17/0x70 ? asm_exc_op_inválida+0x1a/0x20 ? cerrar_ctree+0x222/0x4d0 [btrfs] apagado_genérico_super+0x70/0x160 matar_anónimo_super+0x11/0x40 btrfs_kill_super+0x11/0x20 [btrfs] desactivar_bloqueado_super+0x2e/0xa0 limpieza_mnt+0xb5/0x150 ejecución_trabajo_tarea+0x57/0x80 salida_llamada_al_sistema_modo_usuario_+0x121/0x130 hacer_llamada_al_sistema_64+0xab/0x1a0 entrada_SYSCALL_64_después_de_hwframe+0x77/0x7f RIP: 0033:0x7f916847a887 ---[ fin de seguimiento 0000000000000000 ]--- Error BTRFS (estado del dispositivo dm-8 EA): se filtró el espacio reservado del qgroup Los casos 2 y 3 en la ruta out_reserve pertenecen a este tipo de fuga y deben liberar los datos reservados del qgroup. Debido a que ya es una ruta de error, opté por no manejar los posibles errores en btrfs_free_qgroup_data.
Vulnerabilidad en kernel de Linux (CVE-2024-46736)
Severidad: ALTA
Fecha de publicación: 18/09/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: se corrige la doble colocación de @cfile en smb2_rename_path() Si se llama a smb2_set_path_attr() con un @cfile válido y se devuelve -EINVAL, debemos llamar a cifs_get_writable_path() nuevamente ya que la referencia de @cfile ya fue descartada por la llamada anterior a smb2_compound_op().
Vulnerabilidad en kernel de Linux (CVE-2024-46745)
Severidad: MEDIA
Fecha de publicación: 18/09/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: uinput - rechazar solicitudes con un número irrazonable de ranuras Al ejercitar la interfaz uinput, syzkaller puede intentar configurar el dispositivo con un número realmente grande de ranuras, lo que provoca un error de asignación de memoria en input_mt_init_slots(). Si bien este error de asignación se maneja correctamente y la solicitud se rechaza, da como resultado informes de syzkaller. Además, dicha solicitud puede poner una carga indebida en el sistema que intentará liberar una gran cantidad de memoria para una solicitud falsa. Arréglelo limitando el número permitido de ranuras a 100. Esto se puede ampliar fácilmente si vemos dispositivos que pueden rastrear más de 100 contactos.
Vulnerabilidad en kernel de Linux (CVE-2024-46752)
Severidad: MEDIA
Fecha de publicación: 18/09/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: reemplazar BUG_ON() con manejo de errores en update_ref_for_cow() En lugar de un BUG_ON(), simplemente devuelva un error, registre un mensaje de error y cancele la transacción en caso de que encontremos un búfer de extensión que pertenezca al árbol de reubicación que no tenga el indicador backref completo establecido. Esto es inesperado y nunca debería suceder (salvo por errores o una posible mala memoria).
Vulnerabilidad en kernel de Linux (CVE-2024-46753)
Severidad: MEDIA
Fecha de publicación: 18/09/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: manejo correcto de errores de btrfs_dec_ref() En walk_up_proc() ejecutamos BUG_ON(ret) desde btrfs_dec_ref(). Esto es incorrecto, aquí tenemos un manejo correcto de errores, devolvemos el error.
Vulnerabilidad en kernel de Linux (CVE-2024-46764)
Severidad: ALTA
Fecha de publicación: 18/09/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: añadir comprobación de nombre no válido en btf_name_valid_section() Si la longitud de la cadena de nombre es 1 y el valor de name[0] es un byte NULL, se produce una vulnerabilidad OOB en btf_name_valid_section() y el valor de retorno es verdadero, por lo que el nombre no válido pasa la comprobación. Para resolver esto, debe comprobar si la primera posición es un byte NULL y si el primer carácter es imprimible.
Vulnerabilidad en kernel de Linux (CVE-2024-46767)
Severidad: MEDIA
Fecha de publicación: 18/09/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: Se corrige la falta de of_node_put() para LED. La llamada de of_get_child_by_name() hará que se incremente el recuento de referencias para los LED. Si tiene éxito, debería llamar a of_node_put() para disminuirlo y solucionarlo.
Vulnerabilidad en kernel de Linux (CVE-2024-50212)
Severidad: MEDIA
Fecha de publicación: 09/11/2024
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: lib: alloc_tag_module_unload debe esperar llamadas kfree_rcu pendientes Ben Greear informa del siguiente splat: ------------[ cortar aquí ]------------ net/netfilter/nf_nat_core.c:1114 módulo nf_nat func:nf_nat_register_fn tiene 256 asignados en la descarga del módulo ADVERTENCIA: CPU: 1 PID: 10421 en lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Módulos vinculados en: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Nombre del hardware: Cadena predeterminada Cadena predeterminada/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 La salida del módulo nf_nat llama a kfree_rcu en esas direcciones, pero es probable que la operación de liberación aún esté pendiente en el momento en que alloc_tag verifique si hay fugas. Espere a que se completen las operaciones kfree_rcu pendientes antes de que la verificación resuelva esta advertencia. Reproductor: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # enumerará 4 asignaciones rmmod nft_chain_nat rmmod nf_nat # emitirá una ADVERTENCIA. [akpm@linux-foundation.org: agregar comentario]
Vulnerabilidad en kernel de Linux (CVE-2024-57883)
Severidad: MEDIA
Fecha de publicación: 15/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: hugetlb: recuento compartido de la tabla de páginas PMD independiente El recuento de referencias de folio puede aumentar inesperadamente a través de try_get_folio() por un llamador como split_huge_pages. En huge_pmd_unshare(), usamos el recuento de referencias para verificar si una tabla de páginas pmd está compartida. La comprobación es incorrecta si el llamador anterior aumenta el refcount, y esto puede provocar una fuga de la tabla de páginas: ERROR: Estado de página incorrecto en proceso sh pfn:109324 página: refcount:0 mapcount:0 mapping:0000000000000000 índice:0x66 pfn:0x109324 indicadores: 0x17ffff800000000(nodo=0|zona=2|lastcpupid=0xfffff) tipo_página: f2(tabla) sin procesar: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 sin procesar: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000 página volcada porque: mapcount distinto de cero ... CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: cargado Contaminado: GB 6.13.0-rc2master+ #7 Contaminado: [B]=BAD_PAGE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 dump_stack+0x18/0x28 bad_page+0x8c/0x130 free_page_is_bad_report+0xa4/0xb0 free_unref_page+0x3cc/0x620 __folio_put+0xf4/0x158 split_huge_pages_all+0x1e0/0x3e8 split_huge_pages_write+0x25c/0x2d8 full_proxy_write+0x64/0xd8 vfs_write+0xcc/0x280 ksys_write+0x70/0x110 __arm64_sys_write+0x24/0x38 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x34/0x128 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x190/0x198 El problema puede ser provocado por damon, offline_page, page_idle, etc., que aumentarán el recuento de referencias de la tabla de páginas. 1. La tabla de páginas en sí se descartará después de informar el "recuento de mapas distinto de cero". 2. La página HugeTLB mapeada por la tabla de páginas no se libera ya que tratamos la tabla de páginas como compartida y una tabla de páginas compartida no se desasignará. Arréglelo introduciendo un recuento de páginas compartidas de tabla de páginas PMD independiente. Como se describe en el comentario, pt_index/pt_mm/pt_frag_refcount se utilizan para s390 gmap, x86 pgds y powerpc, pt_share_count se utiliza para x86/arm64/riscv pmds, por lo que podemos reutilizar el campo como pt_share_count.
Vulnerabilidad en kernel de Linux (CVE-2024-57884)
Severidad: MEDIA
Fecha de publicación: 15/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: vmscan: tiene en cuenta las páginas libres para evitar un bucle infinito en throttle_direct_reclaim() La tarea a veces continúa en bucle en throttle_direct_reclaim() porque allow_direct_reclaim(pgdat) sigue devolviendo falso. #0 [ffff80002cb6f8d0] __switch_to en ffff8000080095ac #1 [ffff80002cb6f900] __schedule en ffff800008abbd1c #2 [ffff80002cb6f990] schedule en ffff800008abc50c #3 [ffff80002cb6f9b0] throttle_direct_reclaim en ffff800008273550 #4 [ffff80002cb6fa20] try_to_free_pages en ffff800008277b68 #5 [ffff80002cb6fae0] __alloc_pages_nodemask en ffff8000082c4660 #6 [ffff80002cb6fc50] alloc_pages_vma en ffff8000082e4a98 #7 [ffff80002cb6fca0] do_anonymous_page en ffff80000829f5a8 #8 [ffff80002cb6fce0] __handle_mm_fault en ffff8000082a5974 #9 [ffff80002cb6fd90] handle_mm_fault en ffff8000082a5bd4 En este punto, el pgdat contiene las siguientes dos zonas: NODO: 4 ZONA: 0 DIRECCIÓN: ffff00817fffe540 NOMBRE: "DMA32" TAMAÑO: 20480 MÍN./BAJO/ALTO: 11/28/45 ESTADÍSTICA DE VM: NR_PÁGINAS_LIBRES: 359 NR_ZONA_INACTIVA_ANON: 18813 NR_ZONA_ACTIVA_ANON: 0 NR_ZONA_ARCHIVO_INACTIVO: 50 NR_ZONA_ARCHIVO_ACTIVO: 0 NR_ZONA_UNEVICTABLE: 0 NR_ZONA_ESCRITURA_PENDIENTE: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_PÁGINAS_CMA_LIBRES: 0 NODO: 4 ZONA: 1 DIRECCIÓN: ffff00817fffec00 NOMBRE: "Normal" TAMAÑO: 8454144 PRESENTE: 98304 MÍN./BAJO/ALTO: 68/166/264 ESTADÍSTICO_VM: NR_PÁGINAS_LIBRES: 146 NR_ZONE_INACTIVE_ANON: 94668 NR_ZONE_ACTIVE_ANON: 3 NR_ZONE_INACTIVE_FILE: 735 NR_ZONE_ACTIVE_FILE: 78 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0 En allow_direct_reclaim(), mientras se procesa ZONE_DMA32, la suma de páginas inactivas/activas respaldadas por archivos calculada en zone_reclaimable_pages() en función del resultado de zone_page_state_snapshot() es cero. Además, dado que este sistema carece de intercambio, se omite el cálculo de páginas anónimas inactivas/activas. crash> p nr_swap_pages nr_swap_pages = $1937 = { counter = 0 } Como resultado, ZONE_DMA32 se considera irrecuperable y se omite, pasando al procesamiento de la siguiente zona, ZONE_NORMAL, a pesar de que ZONE_DMA32 tiene páginas libres que exceden significativamente la marca de agua alta. El problema es que pgdat->kswapd_failures no se ha incrementado. crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures $1935 = 0x0 Esto se debe a que el nodo se considera equilibrado. La lógica de equilibrio de nodos en balance_pgdat() evalúa todas las zonas colectivamente. Si una o más zonas (por ejemplo, ZONE_DMA32) tienen suficientes páginas libres para cumplir con sus marcas de agua, todo el nodo se considera equilibrado. Esto hace que balance_pgdat() salga antes de incrementar kswapd_failures, ya que considera que el estado general de la memoria es aceptable, aunque algunas zonas (como ZONE_NORMAL) permanezcan bajo una presión significativa. El parche garantiza que zone_reclaimable_pages() incluya páginas libres (NR_FREE_PAGES) en su cálculo cuando no haya otras páginas recuperables disponibles (por ejemplo, páginas anónimas o respaldadas por archivos). Este cambio evita que zonas como ZONE_DMA32, que tienen suficientes páginas libres, se consideren por error no recuperables. Al hacerlo, el parche garantiza un equilibrio adecuado de los nodos, evita enmascarar la presión en otras zonas como ZONE_NORMAL y evita bucles infinitos en throttle_direct_reclaim() causados por allow_direct_reclaim(pgdat) que devuelve falso repetidamente. El núcleo se cuelga debido a una tarea atascada en throttle_direct_reclaim(), causada por un nodo que se considera incorrectamente equilibrado a pesar de la presión en ciertas zonas, como ZONE_NORMAL. Este problema surge de zone_reclaimable_pages ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2024-57885)
Severidad: MEDIA
Fecha de publicación: 15/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/kmemleak: se corrige la función inactiva llamada desde un contexto no válido en el mensaje de impresión Se soluciona un error en el kernel que activa una advertencia de "función inactiva llamada desde un contexto no válido" cuando se imprime /sys/kernel/debug/kmemleak en condiciones específicas: - CONFIG_PREEMPT_RT=y - Establezca SELinux como el LSM para el sistema - Establezca kptr_restrict en 1 - el búfer de kmemleak contiene al menos un elemento ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 136, name: cat preempt_count: 1, expected: 0 Profundidad de anidación de RCU: 2, expected: 2 6 bloqueos mantenidos por cat/136: #0: ffff32e64bcbf950 (&p->bloqueo){+.+.}-{3:3}, en: seq_read_iter+0xb8/0xe30 #1: ffffafe6aaa9dea0 (scan_mutex){+.+.}-{3:3}, en: kmemleak_seq_start+0x34/0x128 #3: ffff32e6546b1cd0 (&object->bloqueo){....}-{2:2}, en: kmemleak_seq_show+0x3c/0x1e0 #4: ffffafe6aa8d8560 (rcu_lectura_bloqueo){....}-{1:2}, en: has_ns_capability_noaudit+0x8/0x1b0 #5: ffffafe6aabbc0f8 (notif_bloqueo){+.+.}-{2:2}, en: avc_compute_av+0xc4/0x3d0 marca de evento de irq: 136660 hardirqs habilitados por última vez en (136659): [] _raw_spin_unlock_irqrestore+0xa8/0xd8 hardirqs deshabilitados por última vez en (136660): [] _raw_spin_lock_irqsave+0x8c/0xb0 softirqs habilitados por última vez en (0): [] copy_process+0x11d8/0x3df8 softirqs deshabilitados por última vez en (0): [<0000000000000000>] 0x0 Preempción deshabilitada en: [] kmemleak_seq_show+0x3c/0x1e0 CPU: 1 UID: 0 PID: 136 Comm: cat Contaminado: GE 6.11.0-rt7+ #34 Contaminado: [E]=UNSIGNED_MODULE Nombre del hardware: linux,dummy-virt (DT) Rastreo de llamadas: dump_backtrace+0xa0/0x128 show_stack+0x1c/0x30 dump_stack_lvl+0xe8/0x198 dump_stack+0x18/0x20 rt_spin_lock+0x8c/0x1a8 avc_perm_nonode+0xa0/0x150 cred_has_capability.isra.0+0x118/0x218 selinux_capable+0x50/0x80 security_capable+0x7c/0xd0 has_ns_capability_noaudit+0x94/0x1b0 has_capability_noaudit+0x20/0x30 puntero_restringido+0x21c/0x4b0 puntero+0x298/0x760 vsnprintf+0x330/0xf70 seq_printf+0x178/0x218 impresión_sin_referencia+0x1a4/0x2d0 kmemleak_seq_show+0xd0/0x1e0 seq_read_iter+0x354/0xe30 seq_read+0x250/0x378 lectura_proxy_completa+0xd8/0x148 vfs_read+0x190/0x918 ksys_read+0xf0/0x1e0 __arm64_sys_read+0x70/0xa8 %pS y %pK, en la misma línea de seguimiento inverso, son redundantes, y %pS puede anular el servicio %pK en ciertos contextos. %pS solo ya proporciona la información necesaria, y si no puede resolver el símbolo, vuelve a imprimir la dirección sin formato anulando la intención original detrás de %pK. Además, %pK requiere una verificación de privilegios CAP_SYSLOG aplicada a través del LSM, que puede activar una advertencia de "función inactiva llamada desde un contexto no válido" en kernels RT_PREEMPT cuando la verificación ocurre en un contexto atómico. Este problema también puede afectar a otros LSM. Este cambio evita la verificación de privilegios innecesaria y resuelve la advertencia de función inactiva sin ninguna pérdida de información.
Vulnerabilidad en kernel de Linux (CVE-2024-57886)
Severidad: MEDIA
Fecha de publicación: 15/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/damon/core: corrige nuevas fugas de objetos damon_target en damon_commit_targets() Serie de parches "mm/damon/core: corrige fugas de memoria y entradas ignoradas de damon_commit_ctx()". Debido a dos errores en damon_commit_targets() y damon_commit_schemes(), que se llaman desde damon_commit_ctx(), algunas entradas de usuario pueden ignorarse y algunos objetos de memoria pueden filtrarse. Arréglelos. Tenga en cuenta que solo los usuarios de la interfaz sysfs de DAMON se ven afectados. Otros módulos de usuario de la API del núcleo de DAMON que se centran más en usos de producción simples y dedicados, incluidos DAMON_RECLAIM y DAMON_LRU_SORT, no utilizan la función con errores de la misma manera, por lo que no se ven afectados. Este parche (de 2): Cuando se agregan nuevos objetivos DAMON a través de damon_commit_targets(), los objetivos recién creados no se desasignan cuando falla la actualización de los datos internos (damon_commit_target()). Peor aún, incluso si la configuración se realiza correctamente, el nuevo objetivo no está vinculado al contexto. Por lo tanto, los nuevos objetivos siempre se filtran independientemente de la falla de configuración de los datos internos. Corrija las filtraciones.
Vulnerabilidad en kernel de Linux (CVE-2024-57889)
Severidad: MEDIA
Fecha de publicación: 15/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: mcp23s08: Se corrige la suspensión en un contexto atómico debido al bloqueo de regmap Si un dispositivo usa el expansor de E/S MCP23xxx para recibir IRQ, puede ocurrir el siguiente error: ERROR: función de suspensión llamada desde un contexto no válido en kernel/locking/mutex.c:283 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ... preempt_count: 1, expected: 0 ... Seguimiento de llamadas: ... __might_resched+0x104/0x10e __might_sleep+0x3e/0x62 mutex_lock+0x20/0x4c regmap_lock_mutex+0x10/0x18 regmap_update_bits_base+0x2c/0x66 Observamos el problema mientras experimentábamos con un controlador de pantalla táctil que usaba el expansor de E/S MCP23017 (I2C). El mapa de reglas en el controlador pinctrl-mcp23s08 usa un mutex para protección contra accesos concurrentes, que es el valor predeterminado para los mapas de reglas sin .fast_io, .disable_locking, etc. mcp23s08_irq_set_type() llama a regmap_update_bits_base(), y este último bloquea el mutex. Sin embargo, __setup_irq() bloquea el spinlock desc->lock antes de llamar a estas funciones. Como resultado, el sistema intenta bloquear el mutex que contiene el spinlock. Parece que los bloqueos internos del mapa de reglas no son necesarios en este controlador en absoluto. mcp->lock parece proteger el mapa de reglas de accesos concurrentes, excepto, probablemente, en mcp_pinconf_get/set. mcp23s08_irq_set_type() y mcp23s08_irq_mask/unmask() se llaman bajo chip_bus_lock(), que llama a mcp23s08_irq_bus_lock(). Este último toma mcp->lock y habilita el almacenamiento en caché del mapa de reglas, de modo que los accesos I2C potencialmente lentos se posponen hasta chip_bus_unlock(). Los accesos al mapa de reglas desde mcp23s08_probe_one() no necesitan bloqueo adicional. En todos los lugares restantes donde se accede al mapa de reglas, excepto mcp_pinconf_get/set(), el controlador ya toma mcp->lock. Este parche agrega bloqueo en mcp_pinconf_get/set() y deshabilita el bloqueo interno en la configuración de regmap. Entre otras cosas, corrige el problema de suspensión en el contexto atómico descrito anteriormente.
Vulnerabilidad en kernel de Linux (CVE-2024-57893)
Severidad: MEDIA
Fecha de publicación: 15/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: seq: oss: Se corrigen las ejecuciones al procesar mensajes SysEx El secuenciador OSS gestiona los mensajes SysEx divididos en paquetes de 6 bytes y la capa OSS del secuenciador ALSA intenta combinarlos. Almacena los datos en el búfer interno y este acceso es acelerado a partir de ahora, lo que puede llevar al acceso fuera de los límites. Como solución temporal, introduzca un mutex para serializar el proceso de los paquetes de mensajes SysEx.
Vulnerabilidad en kernel de Linux (CVE-2024-57903)
Severidad: MEDIA
Fecha de publicación: 15/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: restringir SO_REUSEPORT a sockets inet Después de la confirmación culpada, los sockets criptográficos podrían destruirse accidentalmente desde la devolución de llamada de RCU, como lo detectó zyzbot [1]. Intentar adquirir un mutex en la devolución de llamada de RCU no está permitido. Restringir la opción de socket SO_REUSEPORT a los sockets inet. La v1 de este parche admitía sockets TCP, UDP y SCTP, pero la prueba fcnal-test.sh necesitaba compatibilidad con RAW e ICMP. [1] ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/mutex.c:562 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1 preempt_count: 100, expected: 0 Profundidad de anidación de RCU: 0, expected: 0 1 bloqueo retenido por ksoftirqd/1/24: #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, en: rcu_lock_acquire include/linux/rcupdate.h:337 [en línea] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, en: rcu_do_batch kernel/rcu/tree.c:2561 [en línea] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, en: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823 Preempción deshabilitada en: [] softirq_handle_begin kernel/softirq.c:402 [en línea] [] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537 CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 No contaminado 6.13.0-rc3-syzkaller-00174-ga024e377efed #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Llamada Rastro: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 __might_resched+0x5d4/0x780 kernel/sched/core.c:8758 __mutex_lock_common kernel/locking/mutex.c:562 [en línea] __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735 crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179 aead_release+0x3d/0x50 crypto/algif_aead.c:489 alg_do_release crypto/af_alg.c:118 [en línea] alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502 __sk_destruct+0x58/0x5f0 net/core/sock.c:2260 rcu_do_batch kernel/rcu/tree.c:2567 [en línea] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 run_ksoftirqd+0xca/0x130 kernel/softirq.c:950 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Vulnerabilidad en kernel de Linux (CVE-2025-21647)
Severidad: ALTA
Fecha de publicación: 19/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched: sch_cake: agregar comprobaciones de los límites a los recuentos de equidad de flujo masivo del host Aunque arreglamos un error lógico en el commit citada a continuación, syzbot aún logró activar un desbordamiento de los contadores de flujo masivo por host, lo que provocó un acceso a la memoria fuera de los límites. Para evitar que dichos errores lógicos provoquen accesos a la memoria fuera de los límites, esta confirmación elimina todos los accesos a los contadores de flujo masivo por host a una serie de ayudantes que realizan la comprobación de los límites antes de cualquier incremento o decremento. Esto también tiene el beneficio de mejorar la legibilidad al mover las comprobaciones condicionales para el modo de flujo a estos ayudantes, en lugar de tenerlas distribuidas por todo el código (que era la causa del error lógico original). Como parte de este cambio, el cálculo cuántico de flujo se consolida en una función auxiliar, lo que significa que el tramado aplicado al escalamiento de carga ost ahora se aplica tanto en la rotación DRR como cuando se inicia por primera vez el cuántico de un flujo disperso. El único efecto visible para el usuario es que el tamaño máximo de paquete que se puede enviar mientras un flujo permanece disperso variará ahora en +/- un byte en algunos casos. Esto no debería suponer una diferencia notable en la práctica y, por lo tanto, no vale la pena complicar el código para conservar el comportamiento anterior.
Vulnerabilidad en kernel de Linux (CVE-2025-21654)
Severidad: MEDIA
Fecha de publicación: 19/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ovl: soporte para codificar fid desde un inodo sin alias Dmitry Safonov informó que una aserción WARN_ON() puede ser activada por el espacio de usuario al llamar a inotify_show_fdinfo() para un inodo vigilado por overlayfs, cuyos alias dentry se descartaron con drop_caches. La aserción WARN_ON() en inotify_show_fdinfo() se eliminó, porque es posible que la codificación del identificador de archivo falle por otra razón, pero el impacto de no codificar un identificador de archivo overlayfs va más allá de esta aserción. Como se muestra en el caso de prueba LTP mencionado en el enlace a continuación, no codificar un identificador de archivo overlayfs desde un inodo sin alias también conduce a no informar un fid con eventos fanotify FAN_DELETE_SELF. Como Dmitry señala en su análisis del problema, ovl_encode_fh() falla si no puede encontrar un alias para el inodo, pero este error se puede solucionar. ovl_encode_fh() rara vez usa el alias y en el caso de identificadores de archivos no decodificables, como suele ser el caso con la información de fid de fanotify, ovl_encode_fh() nunca necesita usar el alias para codificar un identificador de archivo. Aplaza la búsqueda de un alias hasta que realmente sea necesario para que ovl_encode_fh() no falle en el caso común de eventos de fanotify FAN_DELETE_SELF.
Vulnerabilidad en kernel de Linux (CVE-2024-57921)
Severidad: MEDIA
Fecha de publicación: 19/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: Agregar un bloqueo al acceder a la función de recorte del compañero Al ejecutar videos de YouTube y juegos de Steam simultáneamente, el evaluador encontró un problema de condición de ejecución/bloqueo del sistema con la configuración de múltiples pantallas. Agregar un bloqueo a la función de recorte del asignador de compañeros sería la solución. [ 7197.250436] error de protección general, probablemente para la dirección no canónica 0xdead000000000108 [ 7197.250447] RIP: 0010:__alloc_range+0x8b/0x340 [amddrm_buddy] [ 7197.250470] Seguimiento de llamadas: [ 7197.250472] [ 7197.250475] ? asm_exc_general_protection+0x27/0x30 [7197.250498] ? __alloc_range+0x8b/0x340 [amddrm_buddy] [7197.250501] ? __alloc_range+0x109/0x340 [amddrm_buddy] [ 7197.250506] amddrm_buddy_block_trim+0x1b5/0x260 [amddrm_buddy] [ 7197.250511] amdgpu_vram_mgr_new+0x4f5/0x590 [amdgpu] [ 7197.250682] amdttm_resource_alloc+0x46/0xb0 [amdttm] [ 7197.250689] ttm_bo_alloc_resource+0xe4/0x370 [amdttm] [ 7197.250696] amdttm_bo_validate+0x9d/0x180 [amdttm] [ [7197.250701] amdgpu_bo_pin+0x15a/0x2f0 [amdgpu] [ 7197.250831] amdgpu_dm_plane_helper_prepare_fb+0xb2/0x360 [amdgpu] [ 7197.251025] ? drm_atomic_helper_prepare_planes.part.0+0x2f/0x1e0 [ 7197.251035] drm_atomic_helper_prepare_planes+0x5d/0x70 [ 7197.251037] drm_atomic_helper_commit+0x84/0x160 [ 7197.251040] drm_atomic_nonblocking_commit+0x59/0x70 [ 7197.251043] drm_mode_atomic_ioctl+0x720/0x850 [ 7197.251047] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [ 7197.251049] drm_ioctl_kernel+0xb9/0x120 [ 7197.251053] ? srso_alias_return_thunk+0x5/0xfbef5 [ 7197.251056] drm_ioctl+0x2d4/0x550 [ 7197.251058] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [ 7197.251063] amdgpu_drm_ioctl+0x4e/0x90 [ amdgpu] [ 7197.251186] __x64_sys_ioctl+0xa0/0xf0 [ 7197.251190] x64_sys_call+0x143b/0x25c0 [ 7197.251193] do_syscall_64+0x7f/0x180 [ 7197.251197] ? srso_alias_return_thunk+0x5/0xfbef5 [ 7197.251199] ? amdgpu_display_user_framebuffer_create+0x215/0x320 [amdgpu] [ 7197.251329] ? drm_internal_framebuffer_create+0xb7/0x1a0 [ 7197.251332] ? srso_alias_return_thunk+0x5/0xfbef5 (seleccionado de el commit 3318ba94e56b9183d0304577c74b33b6b01ce516)
Vulnerabilidad en kernel de Linux (CVE-2024-57923)
Severidad: MEDIA
Fecha de publicación: 19/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zlib: arregla los bytes avail_in para la ruta de compresión de hardware zlib s390 Dado que la longitud de los datos de entrada que se pasan a zlib_compress_folios() puede ser arbitraria, configurar siempre strm.avail_in como un múltiplo de PAGE_SIZE puede provocar que los bytes de lectura superen el rango de entrada. Actualmente, esto activa una afirmación en btrfs_compress_folios() en el kernel de depuración (ver a continuación). Arregla el cálculo de strm.avail_in para la ruta de aceleración de hardware S390. La afirmación falló: *total_in <= orig_len, en fs/btrfs/compression.c:1041 ------------[ corte aquí ]------------ ¡ERROR del kernel en fs/btrfs/compression.c:1041! Evento de monitor: 0040 ilc:2 [#1] PREEMPT SMP CPU: 16 UID: 0 PID: 325 Comm: kworker/u273:3 No contaminado 6.13.0-20241204.rc1.git6.fae3b21430ca.300.fc41.s390x+debug #1 Nombre de hardware: IBM 3931 A01 703 (z/VM 7.4.0) Cola de trabajo: btrfs-delalloc btrfs_work_helper Krnl PSW: 0704d00180000000 0000021761df6538 (btrfs_compress_folios+0x198/0x1a0) R:0 T:1 IO:1 EX:1 Clave:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 0000000080000000 0000000000000001 0000000000000047 0000000000000000 000000000000006 ffffff01757bb000 000001976232fcc0 000000000000130c 000001976232fcd0 000001976232fcc8 00000118ff4a0e30 0000000000000001 00000111821ab400 0000011100000000 0000021761df6534 000001976232fb58 Código Krnl: 0000021761df6528: c020006f5ef4 larl %r2,0000021762be2310 0000021761df652e: c0e5ffbd09d5 brasl %r14,00000217615978d8 #0000021761df6534: af000000 mc 0,0 >0000021761df6538: 0707 bcr 0,%r7 0000021761df653a: 0707 bcr 0,%r7 0000021761df653c: 0707 bcr 0,%r7 0000021761df653e: 0707 bcr 0,%r7 0000021761df6540: c004004bb7ec brcl 0,000002176276d518 Seguimiento de llamadas: [<0000021761df6538>] btrfs_compress_folios+0x198/0x1a0 ([<0000021761df6534>] btrfs_compress_folios+0x194/0x1a0) [<0000021761d97788>] rango_archivo_comprimir+0x3b8/0x6d0 [<0000021761dcee7c>] ayuda_trabajo_btrfs+0x10c/0x160 [<0000021761645760>] trabajo_proceso_uno+0x2b0/0x5d0 [<000002176164637e>] subproceso_trabajador+0x20e/0x3e0 [<000002176165221a>] subproceso_k+0x15a/0x170 [<00000217615b859c>] __ret_de_bifurcación+0x3c/0x60 [<00000217626e72d2>] ret_de_bifurcación+0xa/0x38 INFORMACIÓN: bloqueo_dep es Desactivado. Dirección del último evento de ruptura: [<0000021761597924>] _printk+0x4c/0x58 Pánico del kernel: no se sincroniza: Excepción fatal: panic_on_oops
Vulnerabilidad en kernel de Linux (CVE-2024-57924)
Severidad: MEDIA
Fecha de publicación: 19/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs: relajar las aserciones en caso de fallo en la codificación de identificadores de archivos La codificación de identificadores de archivos normalmente se realiza mediante un método >encode_fh() del sistema de archivos que puede fallar por varias razones. Los usuarios heredados de exportfs_encode_fh(), es decir, nfsd y la llamada al sistema name_to_handle_at(2) están preparados para hacer frente a la posibilidad de un fallo en la codificación de un identificador de archivo. Hay algunos otros usuarios de exportfs_encode_{fh,fid}() que actualmente tienen una aserción WARN_ON() cuando ->encode_fh() falla. Relajen esas aserciones porque son incorrectas. El segundo informe de error vinculado indica el commit 16aac5ad1fa9 ("ovl: compatibilidad con la codificación de identificadores de archivos no decodificables") en v6.6 como el commit regresiva, pero esto no es exacto. El commit mencionado anteriormente solo aumenta las posibilidades de la aserción y permite activar la aserción con el reproductor usando overlayfs, inotify y drop_caches. Activar esta aserción siempre fue posible con otros sistemas de archivos y otras razones de fallas de ->encode_fh() y, más particularmente, también fue posible con el mismo reproductor exacto usando overlayfs que está montado con las opciones index=on,nfs_export=on también en kernels < v6.6. Por lo tanto, no estoy listando el commit mencionado anteriormente como un commit de correcciones. Sugerencia de retroportación: este parche tendrá un conflicto trivial que se aplica a v6.6.y, y otros conflictos triviales que se aplican a kernels estables < v6.6.
Vulnerabilidad en kernel de Linux (CVE-2024-57928)
Severidad: ALTA
Fecha de publicación: 19/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: Arreglar la gestión de enomem en lecturas en búfer Si netfs_read_to_pagecache() obtiene un error de ->prepare_read() o de netfs_prepare_read_iterator(), necesita decrementar ->nr_outstanding, cancelar la subsolicitud y salir del bucle de emisión. Actualmente, solo hace esto para dos de los casos, pero hay dos más que no se gestionan. Arregle esto moviendo la gestión a un lugar común y saltando a él desde los cuatro lugares. Esto es preferible a insertar un contenedor alrededor de netfs_prepare_read_iterator() como lo propuso Dmitry Antipov[1].
Vulnerabilidad en kernel de Linux (CVE-2024-57929)
Severidad: ALTA
Fecha de publicación: 19/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm array: se corrige la liberación de un bloque de matriz defectuoso dos veces en dm_array_cursor_end Cuando dm_bm_read_lock() falla debido a errores de bloqueo o suma de comprobación, libera el bloque defectuoso implícitamente mientras deja atrás un puntero de salida no válido. El llamador de dm_bm_read_lock() no debe operar en este puntero dm_block no válido, o conducirá a un resultado indefinido. Por ejemplo, dm_array_cursor almacena en caché incorrectamente el puntero no válido al leer un bloque de matriz defectuoso, lo que causa una doble liberación en dm_array_cursor_end(), y luego alcanza el BUG_ON en dm-bufio cache_put(). Reproducir los pasos: 1. inicializar un dispositivo de caché dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc $262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. borrar el segundo bloque de matriz sin conexión dmsteup remove cache cmeta cdata corig mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock 3. Intente volver a abrir el dispositivo de caché dmsetup create cmeta --table "0 8192 lineal /dev/sdc 0" dmsetup create cdata --table "0 65536 lineal /dev/sdc 8192" dmsetup create corig --table "0 524288 lineal /dev/sdc $262144" dmsetup create cache --table "0 524288 caché /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" Registros del kernel: (snip) device-mapper: array: array_block_check failed: blocknr 0 != wanted 10 device-mapper: block manager: array validator check failed for block 10 device-mapper: array: get_ablock failed device-mapper: cache metadata: dm_array_cursor_next for mapping failed ------------[ corte aquí ]------------ ¡ERROR del kernel en drivers/md/dm-bufio.c:638! Se corrige configurando el puntero de bloque en caché en NULL en caso de errores. Además del reproductor descrito anteriormente, esta corrección se puede verificar utilizando la prueba "array_cursor/damaged" en dm-unit: dm-unit run /pdata/array_cursor/damaged --kernel-dir
Vulnerabilidad en kernel de Linux (CVE-2024-57932)
Severidad: MEDIA
Fecha de publicación: 21/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gve: guard XDP xmit NDO on existing xdp queues En GVE, las colas XDP dedicadas solo existen cuando se instala un programa XDP y la interfaz está activa. Como tal, la devolución de llamada NDO XDP XMIT debe regresar temprano si alguna de estas condiciones es falsa. En el caso de que no haya un programa XDP cargado, priv->num_xdp_queues=0 que puede causar un error de división por cero, y en el caso de que la interfaz esté inactiva, num_xdp_queues permanece intacto para persistir el conteo de colas XDP para la siguiente interfaz activa, pero el puntero TX en sí sería NULL. La devolución de llamada XDP xmit también necesita sincronizarse con un dispositivo que esté pasando de abierto a cerrado. Esta sincronización ocurrirá a través del bit GVE_PRIV_FLAGS_NAPI_ENABLED junto con una llamadasynchronous_net(), que espera a que se completen las secciones críticas de RCU en el momento de la llamada.
Vulnerabilidad en kernel de Linux (CVE-2024-57945)
Severidad: ALTA
Fecha de publicación: 21/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: mm: Corrige el problema de salida de límites de la dirección vmemmap En el modelo vmemmap disperso, la dirección virtual de vmemmap se calcula como: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). Y la va de la página de estructura se puede calcular con un desplazamiento: (vmemmap + (pfn)). Sin embargo, al inicializar las páginas de estructura, el kernel en realidad comienza desde la primera página de la misma sección a la que pertenece phys_ram_base. Si la dirección física de la primera página no es (phys_ram_base >> PAGE_SHIFT), obtenemos una va por debajo de VMEMMAP_START al calcular la va para su página de estructura. Por ejemplo, si phys_ram_base comienza desde 0x82000000 con pfn 0x82000, la primera página en la misma sección es en realidad pfn 0x80000. Durante init_unavailable_range(), inicializaremos struct page para pfn 0x80000 con dirección virtual ((struct page *)VMEMMAP_START - 0x2000), que está debajo de VMEMMAP_START y PCI_IO_END. Esta confirmación corrige este error al introducir una nueva variable 'vmemmap_start_pfn' que está alineada con el tamaño de la sección de memoria y la usa para calcular la dirección vmemmap en lugar de phys_ram_base.
Vulnerabilidad en kernel de Linux (CVE-2024-57948)
Severidad: MEDIA
Fecha de publicación: 31/01/2025
Fecha de última actualización: 26/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mac802154: comprobar las interfaces locales antes de eliminar la lista sdata syzkaller informó una lista dañada en ieee802154_if_remove. [1] Eliminar una interfaz de red IEEE 802.15.4 después de anular el registro de un dispositivo de hardware IEEE 802.15.4 del sistema. CPU0 CPU1 ==== ==== genl_family_rcv_msg_doit ieee802154_unregister_hw ieee802154_del_iface ieee802154_remove_interfaces rdev_del_virtual_intf_deprecated list_del(&sdata->list) ieee802154_if_remove list_del_rcu Se ha anulado el registro del dispositivo de red. Desde el período de gracia de rcu, la anulación del registro debe ejecutarse antes de ieee802154_if_remove. Para evitar este problema, agregue una comprobación de local->interfaces antes de eliminar la lista sdata. [1] ¡ERROR del kernel en lib/list_debug.c:58! Oops: código de operación no válido: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 6277 Comm: syz-executor157 No contaminado 6.12.0-rc6-syzkaller-00005-g557329bcecc2 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 RIP: 0010:__list_del_entry_valid_or_report+0xf4/0x140 lib/list_debug.c:56 Código: e8 a1 7e 00 07 90 0f 0b 48 c7 c7 e0 37 60 8c 4c 89 fe e8 8f 7e 00 07 90 0f 0b 48 c7 c7 40 38 60 8c 4c 89 fe e8 7d 7e 00 07 90 <0f> 0b 48 c7 c7 a0 38 60 8c 4c 89 fe e8 6b 7e 00 07 90 0f 0b 48 c7 RSP: 0018:ffffc9000490f3d0 EFLAGS: 00010246 RAX: 00000000000004e RBX: muerto000000000122 RCX: d211eee56bb28d00 RDX: 000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88805b278dd8 R08: ffffffff8174a12c R09: 1ffffffff2852f0d R10: dffffc0000000000 R11: fffffbfff2852f0e R12: dffffc0000000000 R13: dffffc0000000000 R14: muerto000000000100 R15: ffff88805b278cc0 FS: 0000555572f94380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000056262e4a3000 CR3: 0000000078496000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: __list_del_entry_valid include/linux/list.h:124 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000056262e4a3000 CR3: 0000000078496000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __list_del_entry_valid include/linux/list.h:124 [en línea] __list_del_entry include/linux/list.h:215 [en línea] list_del_rcu include/linux/rculist.h:157 [en línea] ieee802154_if_remove+0x86/0x1e0 net/mac802154/iface.c:687 rdev_del_virtual_intf_deprecated net/ieee802154/rdev-ops.h:24 [en línea] ieee802154_del_iface+0x2c0/0x5c0 net/ieee802154/nl-phy.c:323 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [en línea] genl_family_rcv_msg net/netlink/genetlink.c:1195 [en línea] genl_rcv_msg+0xb14/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [en línea] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [en línea] __sock_sendmsg+0x221/0x270 red/socket.c:744 ____sys_sendmsg+0x52a/0x7e0 red/socket.c:2607 ___sys_sendmsg red/socket.c:2661 [en línea] __sys_sendmsg+0x292/0x380 red/socket.c:2690 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Vulnerabilidad en MongoDB Server (CVE-2025-6707)
Severidad: MEDIA
Fecha de publicación: 26/06/2025
Fecha de última actualización: 26/09/2025
En determinadas circunstancias, una solicitud de usuario autenticado podría ejecutarse con privilegios obsoletos tras un cambio intencionado por parte de un administrador autorizado. Este problema afecta a MongoDB Server v5.0 (versión anterior a la 5.0.31), MongoDB Server v6.0 (versión anterior a la 6.0.24), MongoDB Server v7.0 (versión anterior a la 7.0.21) y MongoDB Server v8.0 (versión anterior a la 8.0.5).