Instituto Nacional de ciberseguridad. Sección Incibe

017 - Ir a la línea de ayuda en Ciberseguridad    Ir a Agenda     Ir a Sala de prensa     Ir a suscripción de boletines

Ir al buscador

Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

No hay vulnerabilidades nuevas para los productos a los que está suscrito.



Otras vulnerabilidades de los productos a los que usted está suscrito, y cuya información ha sido actualizada recientemente:

  • Vulnerabilidad en kernel de Linux (CVE-2025-21803)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Se corrigen advertencias durante la suspensión de S3 La función enable_gpe_wakeup() llama a acpi_enable_all_wakeup_gpes(), y la última puede llamar a la función preempt_schedule_common(), lo que da como resultado un cambio de hilo y hace que la CPU esté en un estado de interrupción habilitada después de que la función enable_gpe_wakeup() regrese, lo que genera las advertencias siguientes. [ C0] ADVERTENCIA: ... en kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8 [ C0] ... [ C0] Call Trace: [ C0] [<90000000002243b4>] show_stack+0x64/0x188 [ C0] [<900000000164673c>] dump_stack_lvl+0x60/0x88 [ C0] [<90000000002687e4>] __warn+0x8c/0x148 [ C0] [<90000000015e9978>] report_bug+0x1c0/0x2b0 [ C0] [<90000000016478e4>] do_bp+0x204/0x3b8 [ C0] [<90000000025b1924>] exception_handlers+0x1924/0x10000 [ C0] [<9000000000343bbc>] ktime_get+0xbc/0xc8 [ C0] [<9000000000354c08>] tick_sched_timer+0x30/0xb0 [ C0] [<90000000003408e0>] __hrtimer_run_queues+0x160/0x378 [ C0] [<9000000000341f14>] hrtimer_interrupt+0x144/0x388 [ C0] [<9000000000228348>] constant_timer_interrupt+0x38/0x48 [ C0] [<90000000002feba4>] __handle_irq_event_percpu+0x64/0x1e8 [ C0] [<90000000002fed48>] handle_irq_event_percpu+0x20/0x80 [ C0] [<9000000000306b9c>] handle_percpu_irq+0x5c/0x98 [ C0] [<90000000002fd4a0>] generic_handle_domain_irq+0x30/0x48 [ C0] [<9000000000d0c7b0>] handle_cpu_irq+0x70/0xa8 [ C0] [<9000000001646b30>] handle_loongarch_irq+0x30/0x48 [ C0] [<9000000001646bc8>] do_vint+0x80/0xe0 [ C0] [<90000000002aea1c>] finish_task_switch.isra.0+0x8c/0x2a8 [ C0] [<900000000164e34c>] __schedule+0x314/0xa48 [ C0] [<900000000164ead8>] schedule+0x58/0xf0 [ C0] [<9000000000294a2c>] worker_thread+0x224/0x498 [ C0] [<900000000029d2f0>] kthread+0xf8/0x108 [ C0] [<9000000000221f28>] ret_from_kernel_thread+0xc/0xa4 [ C0] [ C0] ---[ end trace 0000000000000000 ]--- The root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect acpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause a thread switch. Dado que ya no hay ejecución simultánea durante loongarch_acpi_suspend(), podemos llamar a acpi_hw_enable_all_wakeup_gpes() directamente en enable_gpe_wakeup(). La solución es similar a el commit 22db06337f590d01 ("ACPI: sleep: evitar interrumpir la activación de S3 debido a might_sleep()").
  • Vulnerabilidad en kernel de Linux (CVE-2025-21804)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: rcar-ep: Se corrige la variable incorrecta utilizada al llamar a devm_request_mem_region(). rcar_pcie_parse_outbound_ranges() utiliza la macro devm_request_mem_region() para solicitar un recurso necesario. Luego, se utiliza una variable de cadena que se encuentra en la pila para almacenar un nombre de recurso calculado dinámicamente, que luego se pasa como uno de los argumentos de la macro. Esto puede provocar un comportamiento indefinido. Según el contenido actual de la memoria, las manifestaciones de los errores pueden variar. Una posible salida puede ser la siguiente: $ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff : A veces, puede aparecer basura después de los dos puntos. En casos muy raros, si no se encuentra un terminador NULL en la memoria, el sistema puede bloquearse porque el iterador de cadena se desbordará, lo que puede provocar el acceso a la memoria no asignada por encima de la pila. Por lo tanto, solucione este problema reemplazando outbound_name con el nombre del recurso solicitado anteriormente. Con los cambios aplicados, el resultado será el siguiente: $ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3 [kwilczynski: commit log]
  • Vulnerabilidad en kernel de Linux (CVE-2025-21805)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/rtrs: Agregar llamada deinit() faltante Se activa una advertencia al conectar y desconectar repetidamente rnbd: corrupción de list_add. prev->next debería ser next (ffff88800b13e480), pero era ffff88801ecd1338. (prev=ffff88801ecd1340). ADVERTENCIA: CPU: 1 PID: 36562 at lib/list_debug.c:32 __list_add_valid_or_report+0x7f/0xa0 Workqueue: ib_cm cm_work_handler [ib_cm] RIP: 0010:__list_add_valid_or_report+0x7f/0xa0 ? __list_add_valid_or_report+0x7f/0xa0 ib_register_event_handler+0x65/0x93 [ib_core] rtrs_srv_ib_dev_init+0x29/0x30 [rtrs_server] rtrs_ib_dev_find_or_add+0x124/0x1d0 [rtrs_core] __alloc_path+0x46c/0x680 [rtrs_server] ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server] ? rcu_is_watching+0xd/0x40 ? __mutex_lock+0x312/0xcf0 ? get_or_create_srv+0xad/0x310 [rtrs_server] ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server] rtrs_rdma_connect+0x23c/0x2d0 [rtrs_server] ? __lock_release+0x1b1/0x2d0 cma_cm_event_handler+0x4a/0x1a0 [rdma_cm] cma_ib_req_handler+0x3a0/0x7e0 [rdma_cm] cm_process_work+0x28/0x1a0 [ib_cm] ? _raw_spin_unlock_irq+0x2f/0x50 cm_req_handler+0x618/0xa60 [ib_cm] cm_work_handler+0x71/0x520 [ib_cm] Commit 667db86bcbe8 ("RDMA/rtrs: Register ib event handler") introdujo un nuevo elemento .deinit pero nunca lo usó. Arréglelo invocando `deinit()` para anular el registro del controlador de eventos IB de manera adecuada.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21806)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: deje que net.core.dev_weight siempre sea distinto de cero. Se encontró el siguiente problema durante la prueba de estabilidad: (NULL net_device): la función de sondeo NAPI process_backlog+0x0/0x530 \ devolvió 1, excediendo su presupuesto de 0. ------------[ cortar aquí ]------------ list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \ __list_add_valid_or_report+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:__list_add_valid_or_report+0xf3/0x130 Call Trace: ? __warn+0xcd/0x250 ? __list_add_valid_or_report+0xf3/0x130 enqueue_to_backlog+0x923/0x1070 netif_rx_internal+0x92/0x2b0 __netif_rx+0x15/0x170 loopback_xmit+0x2ef/0x450 dev_hard_start_xmit+0x103/0x490 __dev_queue_xmit+0xeac/0x1950 ip_finish_output2+0x6cc/0x1620 ip_output+0x161/0x270 ip_push_pending_frames+0x155/0x1a0 raw_sendmsg+0xe13/0x1550 __sys_sendto+0x3bf/0x4e0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x5b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1 This is because when the napi's weight is set to 0, process_backlog() may return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this napi to be re-polled in net_rx_action() until __do_softirq() times out. Dado que el bit NAPI_STATE_SCHED se ha borrado, napi_schedule_rps() se puede volver a activar en enqueue_to_backlog(), lo que causa este problema. Hacer que el peso de napi siempre sea distinto de cero resuelve este problema. Para desencadenar este problema se requiere un administrador de todo el sistema (la configuración no tiene espacio de nombres).
  • Vulnerabilidad en kernel de Linux (CVE-2025-21807)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block: fix queue freeze vs limits lock order in sysfs store methods queue_attr_store() siempre congela una cola de dispositivos antes de llamar a la operación de almacenamiento de atributos. Para los atributos que controlan los límites de la cola, la operación de almacenamiento también bloqueará los límites de la cola con una llamada a queue_limits_start_update(). Sin embargo, algunos controladores (por ejemplo, SCSI sd) pueden necesitar emitir comandos a un dispositivo para obtener valores límite del hardware con los límites de la cola bloqueados. Esto crea una posible situación de bloqueo ABBA si un usuario intenta modificar un límite (congelando así la cola del dispositivo) mientras el controlador del dispositivo inicia una revalidación de los límites de la cola del dispositivo. Evite dicho bloqueo al no congelar la cola antes de llamar al método ->store_limit() en struct queue_sysfs_entry y, en su lugar, utilice el asistente queue_limits_commit_update_frozen para congelar la cola después de tomar el bloqueo de los límites. Esto también elimina la posibilidad de tomar el bloqueo de sysfs para el método store_limit, ya que no protege nada aquí, pero crea aún más anidamiento. Con suerte, desaparecerá por completo de los métodos sysfs reales pronto. (registro de confirmación adaptado de un parche similar de Damien Le Moal)
  • Vulnerabilidad en kernel de Linux (CVE-2025-21808)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: xdp: No permitir adjuntar programas vinculados al dispositivo en modo genérico Los programas vinculados al dispositivo se utilizan para admitir las kfuncs de metadatos RX. Estas kfuncs son específicas del controlador y dependen del contexto del controlador para leer los metadatos. Esto significa que no pueden funcionar en modo XDP genérico. Sin embargo, no hay ninguna verificación para no permitir que dichos programas se adjunten en modo genérico, en cuyo caso las kfuncs de metadatos se llamarán en un contexto no válido, lo que provocará fallas. Solucione esto agregando una verificación para no permitir adjuntar programas vinculados al dispositivo en modo genérico.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21810)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: núcleo del controlador: clase: Arreglar desreferencias de punteros salvajes en la API class_dev_iter_next() Hay un posible problema de desreferencias de punteros salvajes con respecto a las API class_dev_iter_(init|next|exit()), como se explica a continuación en el uso típico: // Todos los miembros de @iter son punteros salvajes. struct class_dev_iter iter; // class_dev_iter_init(@iter, @class, ...) comprueba el parámetro @class en busca de un posible error class_to_subsys(), y devuelve el tipo void y no inicializa su parámetro de salida @iter, por lo que el llamador no puede detectar el error y continúa invocando class_dev_iter_next(@iter) incluso si @iter todavía contiene punteros salvajes. class_dev_iter_init(&iter, ...); // Desreferencia estos punteros salvajes en @iter aquí una vez que sufre el error. mientras (dev = class_dev_iter_next(&iter)) { ... }; // También desreferencia estos punteros salvajes aquí. class_dev_iter_exit(&iter); En realidad, todos los que llaman a estas API tienen ese patrón de uso en el árbol del kernel. Solucione esto: - Inicialice el parámetro de salida @iter con memset() en class_dev_iter_init() y dé a los que llaman un aviso con pr_crit() para el error. - Verifique si @iter es válido en class_dev_iter_next().
  • Vulnerabilidad en kernel de Linux (CVE-2025-21813)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: timers/migration: Fix another race between hotplug and idle entry/exit (temporizadores/migración: Arreglar otra ejecución entre hotplug y entrada/salida inactiva) Antes de adjuntar una nueva raíz a la raíz anterior, se comprueba el contador de hijos de la nueva raíz para verificar que solo el grupo superior de la próxima CPU se haya conectado a ella. Sin embargo, desde el commit b729cc1ec21a agregada recientemente ("timers/migration: Fix another race between hotplug and idle entry/exit"), esta comprobación ya no es válida porque la raíz anterior se contabiliza previamente como un hijo de la nueva raíz. Por lo tanto, después de conectar el grupo superior de la próxima CPU a la nueva raíz, el recuento de hijos que se espera debe ser 2 y no 1. Esta omisión da como resultado que la raíz anterior no se conecte a la nueva raíz. Luego, eventualmente, el sistema puede ejecutarse con más de un nivel superior, lo que frustra el propósito de un solo migrador inactivo. Además, la raíz anterior se contabiliza previamente pero no se conecta al momento de la creación de la nueva raíz. Pero se puede conectar a la nueva raíz más adelante. Por lo tanto, la raíz antigua puede contabilizarse dos veces para la nueva raíz. La propagación de dicha sobreasignación puede terminar creando una raíz de nivel superior final doble con una máscara de grupo inicializada incorrectamente. Aunque es inofensiva dado que las raíces de nivel superior finales nunca tendrán un padre al que llegar, esta rareza informó oportunistamente el problema principal: ADVERTENCIA: CPU: 8 PID: 0 at kernel/time/timer_migration.c:543 tmigr_requires_handle_remote CPU: 8 UID: 0 PID: 0 Comm: swapper/8 RIP: 0010:tmigr_requires_handle_remote Call Trace: ? tmigr_requires_handle_remote ? hrtimer_run_queues update_process_times tick_periodic tick_handle_periodic __sysvec_apic_timer_interrupt sysvec_apic_timer_interrupt Solucione el problema teniendo en cuenta la raíz antigua en el recuento de hijos de la nueva raíz para que no se omita la conexión. También advierta cuando exista más de un grupo de nivel superior para detectar mejor problemas similares en el futuro.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21815)
    Severidad: ALTA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/compaction: se corrige la advertencia de cambio fuera de los límites de UBSAN syzkaller informó una advertencia de cambio fuera de los límites de UBSAN de (1UL << order) en isolate_freepages_block(). El compuesto falso puede ser cualquier valor porque es una unión con indicadores. Vuelva a agregar la verificación MAX_PAGE_ORDER para corregir la advertencia.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21816)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hrtimers: fuerza la migración de los hrtimers en cola después de CPUHP_AP_HRTIMERS_DYING. Los hrtimers se migran desde la CPU que se está muriendo a cualquier destino en línea en la etapa CPUHP_AP_HRTIMERS_DYING para no retrasar las tareas de gestión de los temporizadores de ancho de banda involucradas en el progreso de avance de la conexión en caliente de la CPU. Sin embargo, las reactivaciones aún pueden ser realizadas por la CPU saliente después de CPUHP_AP_HRTIMERS_DYING. Esto puede dar como resultado nuevamente que los temporizadores de ancho de banda se activen. Dependiendo de varias consideraciones (elección basada en administración de energía de Crystal Ball, temporizador más antiguo ya en cola, migración de temporizador habilitada o no), el destino puede eventualmente ser la CPU actual incluso si está fuera de línea. Si eso sucede, el temporizador eventualmente se ignora. El ejemplo más notable es RCU, que tuvo que lidiar con todos y cada uno de esos despertares difiriéndolos a una CPU en línea, junto con workarounds relacionados: _ e787644caf76 (rcu: Diferir el despertar de kthreads de RCU cuando la CPU está muriendo) _ 9139f93209d1 (rcu/nocb: Reparar la limitación de RT de hrtimer armado desde una CPU fuera de línea) _ f7345ccc62a4 (rcu/nocb: Reparar el despertar de rcuog desde softirq fuera de línea) El problema no se limita a RCU, ya que el kthread de la máquina de detención (que ejecuta CPUHP_AP_HRTIMERS_DYING) informa su finalización al final de su trabajo a través de cpu_stop_signal_done() y realiza un despertar que eventualmente arma el temporizador del servidor de fecha límite: ADVERTENCIA: CPU: 94 PID: 588 en kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0 CPU: 94 UID: 0 PID: 588 Comm: immigration/94 No contaminado Detenedor: multi_cpu_stop+0x0/0x120 <- stop_machine_cpuslocked+0x66/0xc0 RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0 Rastreo de llamadas: start_dl_timer enqueue_dl_entity dl_server_start enqueue_task_fair enqueue_task ttwu_do_activate try_to_wake_up complete cpu_stopper_thread En lugar de proporcionar otro workaround para solucionar la situación, corríjala en la infraestructura de hrtimers: siempre migre un temporizador a un destino en línea cuando se ponga en cola desde una CPU fuera de línea. Esto también permitirá revertir todos los vergonzosos hackeos de RCU mencionados anteriormente.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21817)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block: mark GFP_NOIO around sysfs ->store() sysfs ->store se llama con la cola congelada, mientras tanto tenemos varias devoluciones de llamadas ->store() (update_nr_requests, wbt, scheduler) para asignar memoria con GFP_KERNEL que puede ejecutarse en una ruta de código de recuperación directa, lo que puede provocar un posible bloqueo. Solucione el problema marcando NOIO alrededor de sysfs ->store()
  • Vulnerabilidad en kernel de Linux (CVE-2025-21819)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "drm/amd/display: Use HW lock mgr for PSR1" Esto revierte el commit a2b5a9956269 ("drm/amd/display: Use HW lock mgr for PSR1") porque puede provocar que el sistema se cuelgue al conectarse con dos paneles edp.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21821)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: omap: usar IRQ enhebrado para DMA de LCD Al usar la pantalla táctil y el framebuffer, Nokia 770 se bloquea fácilmente con: ERROR: scheduling while atomic: irq/144-ads7846/82/0x00010000 Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2 Hardware name: Nokia 770 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x54/0x5c dump_stack_lvl from __schedule_bug+0x50/0x70 __schedule_bug from __schedule+0x4d4/0x5bc __schedule from schedule+0x34/0xa0 schedule from schedule_preempt_disabled+0xc/0x10 schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4 __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4 clk_prepare_lock from clk_set_rate+0x18/0x154 clk_set_rate from sossi_read_data+0x4c/0x168 sossi_read_data from hwa742_read_reg+0x5c/0x8c hwa742_read_reg from send_frame_handler+0xfc/0x300 send_frame_handler from process_pending_requests+0x74/0xd0 process_pending_requests from lcd_dma_irq_handler+0x50/0x74 lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130 __handle_irq_event_percpu from handle_irq_event+0x28/0x68 handle_irq_event from handle_level_irq+0x9c/0x170 handle_level_irq from generic_handle_domain_irq+0x2c/0x3c generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c generic_handle_arch_irq from call_with_stack+0x1c/0x24 call_with_stack from __irq_svc+0x94/0xa8 Exception stack(0xc5255da0 to 0xc5255de8) 5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248 5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94 5de0: 60000013 ffffffff __irq_svc from clk_prepare_lock+0x4c/0xe4 clk_prepare_lock from clk_get_rate+0x10/0x74 clk_get_rate from uwire_setup_transfer+0x40/0x180 uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664 spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498 __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8 __spi_sync from spi_sync+0x24/0x40 spi_sync from ads7846_halfd_read_state+0x5c/0x1c0 ads7846_halfd_read_state from ads7846_irq+0x58/0x348 ads7846_irq from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x120/0x228 irq_thread from kthread+0xc8/0xe8 kthread from ret_from_fork+0x14/0x28 Como solución rápida, cambie a una IRQ con subprocesos que proporcione un sistema estable.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21822)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ptp: vmclock: Establecer datos del controlador antes de su uso Si vmclock_ptp_register() falla durante el sondeo, se llama a vmclock_remove() para limpiar el reloj ptp y el dispositivo misceláneo. Utiliza dev_get_drvdata() para acceder al estado de vmclock. Sin embargo, los datos del controlador aún no están establecidos en este punto. Asigne los datos del controlador antes.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21823)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: batman-adv: eliminar un trabajador de métricas ELP no administrado El trabajador ELP necesita calcular nuevos valores de métricas para todos los vecinos "alcanzables" a través de una interfaz. Algunas de las fuentes de métricas utilizadas requieren bloqueos que podrían necesitar dormir. Esta suspensión es incompatible con el iterador de lista RCU utilizado para los vecinos registrados. El enfoque inicial para solucionar este problema fue poner en cola otro elemento de trabajo por vecino y luego ejecutarlo en un nuevo contexto. Incluso cuando esto resolvió el conflicto RCU vs might_sleep(), tiene un problema importante: nada detenía el elemento de trabajo en caso de que ya no fuera necesario, por ejemplo, porque se eliminó una de las interfaces relacionadas o se descargó el módulo batman-adv, lo que resultó en posibles accesos de memoria no válidos. Cancelar directamente el trabajador de métricas también tiene varios problemas: * cancel_work_sync para una interfaz que se desactivará se llama con rtnl_lock retenido. Pero el código en el trabajador de métricas ELP también intenta usar rtnl_lock() - que nunca regresará en este caso. Esto también significa que cancel_work_sync nunca regresaría porque está esperando que el trabajador termine. * iterar sobre la lista de vecinos para la interfaz que se va a desactivar se realiza actualmente utilizando los métodos específicos de RCU. Lo que significa que es posible omitir elementos al iterarla sin el spinlock asociado - un comportamiento que es aceptable para una verificación periódica de métricas pero no para una rutina de limpieza (que debe "detener" todos los trabajadores que aún se están ejecutando) El mejor enfoque es deshacerse del trabajador de métricas de vecinos por interfaz y manejar todo en el trabajador de interfaz. Los problemas originales se resuelven: * creando una lista de vecinos que requieren nueva información métrica dentro del contexto protegido de RCU, recopilando la métrica de acuerdo con la nueva lista fuera del contexto protegido de RCU * solo use rcu_trylock dentro del código de recopilación de métricas para evitar un bloqueo cuando se llama a cancel_delayed_work_sync en el código de eliminación de interfaz (que se llama con rtnl_lock retenido)
  • Vulnerabilidad en kernel de Linux (CVE-2024-58051)
    Severidad: MEDIA
    Fecha de publicación: 06/03/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipmi: ipmb: Agregar verificación del valor devuelto por devm_kasprintf() devm_kasprintf() puede devolver un puntero NULL en caso de error, pero este valor devuelto no se verifica.
  • Vulnerabilidad en kernel de Linux (CVE-2024-58053)
    Severidad: MEDIA
    Fecha de publicación: 06/03/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Se ha corregido la gestión de la interrupción de la conexión recibida Se ha corregido la gestión de una interrupción de la conexión que hemos recibido. Aunque la interrupción se produce a nivel de conexión, es necesario propagarla a las llamadas de esa conexión. Mientras se realiza el bit de propagación, las llamadas no se activan para procesar su finalización y, como no se recibe ninguna otra entrada, simplemente se cuelgan. También se ha añadido algún seguimiento para el registro de las interrupciones de la conexión.
  • Vulnerabilidad en kernel de Linux (CVE-2024-58056)
    Severidad: MEDIA
    Fecha de publicación: 06/03/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: remoteproc: core: Se corrige en ida_free call while not allocated In the rproc_alloc() function, on error, put_device(&rproc->dev) is called, leading to the call of the rproc_type_release() function. An error can occurs before ida_alloc is called. In such case in rproc_type_release(), the condition (rproc->index >= 0) is true as rproc->index has been initialized to 0. ida_free() is called reporting a warning: [ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 ida_free+0x100/0x164 [ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0 [ 4.188854] ida_free called for id=0 which is not allocated. [ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000 [ 4.203556] Modules linked in: panel_orisetech_otm8009a dw_mipi_dsi_stm(+) gpu_sched dw_mipi_dsi stm32_rproc stm32_crc32 stm32_ipcc(+) optee(+) [ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442 [ 4.231481] Hardware name: STM32 (Device Tree Support) [ 4.236627] Workqueue: events_unbound deferred_probe_work_func [ 4.242504] Call trace: [ 4.242522] unwind_backtrace from show_stack+0x10/0x14 [ 4.250218] show_stack from dump_stack_lvl+0x50/0x64 [ 4.255274] dump_stack_lvl from __warn+0x80/0x12c [ 4.260134] __warn from warn_slowpath_fmt+0x114/0x188 [ 4.265199] warn_slowpath_fmt from ida_free+0x100/0x164 [ 4.270565] ida_free from rproc_type_release+0x38/0x60 [ 4.275832] rproc_type_release from device_release+0x30/0xa0 [ 4.281601] device_release from kobject_put+0xc4/0x294 [ 4.286762] kobject_put from rproc_alloc.part.0+0x208/0x28c [ 4.292430] rproc_alloc.part.0 from devm_rproc_alloc+0x80/0xc4 [ 4.298393] devm_rproc_alloc from stm32_rproc_probe+0xd0/0x844 [stm32_rproc] [ 4.305575] stm32_rproc_probe [stm32_rproc] from platform_probe+0x5c/0xbc Llamar a ida_alloc antes en rproc_alloc garantiza que rproc->index está configurado correctamente.