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-2023-53067)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: solo llamar a get_timer_irq() una vez en constant_clockevent_init() Bajo CONFIG_DEBUG_ATOMIC_SLEEP=y y CONFIG_DEBUG_PREEMPT=y, podemos ver los siguientes mensajes en LoongArch, esto se debe a que se usa might_sleep() en el contexto de deshabilitación de preempción. [ 0.001127] smp: Activando CPU secundarias... [ 0.001222] Arrancando CPU#1... [ 0.001244] Procesador Loongson de 64 bits probado (núcleo LA464) [ 0.001247] La revisión de CPU1 es: 0014c012 (Loongson-64bit) [ 0.001250] La revisión de FPU1 es: 00000000 [ 0.001252] ERROR: función de suspensión llamada desde un contexto no válido en kernel/locking/mutex.c:283 [ 0.001255] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 [ 0.001257] preempt_count: 1, expected: 0 [ 0.001258] Profundidad de anidamiento de RCU: 0, esperado: 0 [ 0.001259] Preempción deshabilitada en: [ 0.001261] [<9000000000223800>] arch_dup_task_struct+0x20/0x110 [ 0.001272] CPU: 1 PID: 0 Comm: swapper/1 No contaminado 6.2.0-rc7+ #43 [ 0.001275] Nombre del hardware: Loongson Loongson-3A5000-7A1000-1w-A2101/Loongson-LS3A5000-7A1000-1w-A2101, BIOS vUDK2018-LoongArch-V4.0.05132-beta10 12/13/202 [ 0.001277] Pila: 0072617764726148 0000000000000000 9000000000222f1c 90000001001e0000 [ 0.001286] 90000001001e3be0 90000001001e3be8 0000000000000000 000000000000000 [ 0.001292] 90000001001e3be8 0000000000000040 90000001001e3cb8 90000001001e3a50 [ 0.001297] 9000000001642000 90000001001e3be8 be694d10ce4139dd 9000000100174500 [ 0.001303] 0000000000000001 000000000000001 000000000ffffe0a2 0000000000000020 [ 0.001309] 00000000000002f 9000000001354116 00000000056b0000 ffffffffffffffffff [ 0.001314] 0000000000000000 0000000000000000 90000000014f6e90 9000000001642000 [ 0.001320] 900000000022b69c 0000000000000001 000000000000000 9000000001736a90 [ 0.001325] 9000000100038000 000000000000000 9000000000222f34 000000000000000 [ 0.001331] 00000000000000b0 0000000000000004 0000000000000000 0000000000070000 [ 0.001337] ... [ 0.001339] Rastreo de llamadas: [ 0.001342] [<9000000000222f34>] show_stack+0x5c/0x180 [ 0.001346] [<90000000010bdd80>] dump_stack_lvl+0x60/0x88 [ 0.001352] [<9000000000266418>] __might_resched+0x180/0x1cc [ 0.001356] [<90000000010c742c>] mutex_lock+0x20/0x64 [ 0.001359] [<90000000002a8ccc>] irq_find_matching_fwspec+0x48/0x124 [ 0.001364] [<90000000002259c4>] constant_clockevent_init+0x68/0x204 [ 0.001368] [<900000000022acf4>] start_secondary+0x40/0xa8 [ 0.001371] [<90000000010c0124>] smpboot_entry+0x60/0x64 Estas son las cadenas de llamadas completas: Para evitar el problema anterior, debemos romper las cadenas de llamadas, utilizando la variable timer_irq_installed como condición de verificación para llamar a get_timer_irq() solo una vez en constant_clockevent_init() es una forma simple y adecuada.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53068)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: usb: lan78xx: Limitar la longitud del paquete a skb->len. La longitud del paquete obtenida del descriptor puede ser mayor que la longitud real del búfer del socket. En tal caso, el skb clonado que se pasa a la pila de red filtrará el contenido de la memoria del kernel. Además, se evita el subdesbordamiento de enteros cuando el tamaño es menor que ETH_FCS_LEN.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53069)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-vf: Agregar libre faltante para alloc_percpu Agregue libre_percpu para el "vf->hw.lmt_info" asignado para evitar fugas de memoria, igual que "pf->hw.lmt_info" en `drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c`.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53070)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: PPTT: Corrección para evitar la suspensión en el contexto atómico cuando PPTT está ausente. el commit 0c80f9e165f8 ("ACPI: PPTT: Dejar la tabla asignada para el uso en tiempo de ejecución") habilitó la asignación de PPTT una vez en la primera invocación de acpi_get_pptt() y nunca la desasignó, lo que permite su uso en tiempo de ejecución sin la molestia de asignar y desasignar la tabla. Esto era necesario para obtener información de LLC del PPTT en la ruta cpuhotplug, que se ejecuta en el contexto atómico, ya que acpi_get_table() podría estar en suspensión esperando un mutex. Sin embargo, no logró gestionar el caso en que no hay PPTT en el sistema, lo que provoca que acpi_get_pptt() se llame desde todas las CPU secundarias que intentan obtener la información de LLC en el contexto atómico sin conocer la ausencia de PPTT, lo que resulta en un error como el siguiente: | ERROR: función inactiva llamada desde contexto no válido en kernel/locking/semaphore.c:164 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 | preempt_count: 1, expected: 0 | Profundidad de anidamiento de RCU: 0, expected: 0 | swapper/1/0 no tiene bloqueos. | marca de evento irq: 0 | hardirqs habilitado por última vez en (0): 0x0 | hardirqs deshabilitado por última vez en (0): copy_process+0x61c/0x1b40 | softirqs habilitado por última vez en (0): copy_process+0x61c/0x1b40 | softirqs deshabilitado por última vez en (0): 0x0 | CPU: 1 PID: 0 Comm: swapper/1 No contaminado 6.3.0-rc1 #1 | Rastreo de llamadas: | dump_backtrace+0xac/0x138 | show_stack+0x30/0x48 | dump_stack_lvl+0x60/0xb0 | dump_stack+0x18/0x28 | __might_resched+0x160/0x270 | __might_sleep+0x58/0xb0 | down_timeout+0x34/0x98 | acpi_os_wait_semaphore+0x7c/0xc0 | acpi_ut_acquire_mutex+0x58/0x108 | acpi_get_table+0x40/0xe8 | acpi_get_pptt+0x48/0xa0 | acpi_get_cache_info+0x38/0x140 | init_cache_level+0xf4/0x118 | detect_cache_attributes+0x2e4/0x640 | update_siblings_masks+0x3c/0x330 | store_cpu_topology+0x88/0xf0 | secondary_start_kernel+0xd0/0x168 | __secondary_switched+0xb8/0xc0 Actualice acpi_get_pptt() para considerar el hecho de que PPTT se verifica una vez y no está disponible en el sistema y devuelve NULL evitando cualquier intento de obtener PPTT y, por lo tanto, evitando cualquier posible suspensión esperando un mutex en el contexto atómico.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53071)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: no ejecutar mt76_unregister_device() en hardware no registrado. Al intentar sondear una tarjeta PCI mt7921e sin firmware, se obtiene un sondeo exitoso donde no se ha llamado a ieee80211_register_hw. Al desinstalar el controlador, se llama a ieee802111_unregister_hw incondicionalmente, lo que provoca una desreferencia de puntero nulo en el kernel. Se solucionó el problema al ejecutar la rutina mt76_unregister_device solo para hardware registrado.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53072)
    Severidad: ALTA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: usa workqueue para destruir sockets no aceptados Christoph informó un UaF en el momento de la búsqueda del token después de haber refactorizado la parte de inicialización del socket pasivo: ERROR: KASAN: use-after-free en __token_bucket_busy+0x253/0x260 Lectura de tamaño 4 en la dirección ffff88810698d5b0 por la tarea syz-executor653/3198 CPU: 1 PID: 3198 Comm: syz-executor653 No contaminado 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 Rastreo de llamadas: dump_stack_lvl+0x6e/0x91 print_report+0x16a/0x46f kasan_report+0xad/0x130 __token_bucket_busy+0x253/0x260 mptcp_token_new_connect+0x13d/0x490 mptcp_connect+0x4ed/0x860 __inet_stream_connect+0x80e/0xd90 tcp_sendmsg_fastopen+0x3ce/0x710 mptcp_sendmsg+0xff1/0x1a20 inet_sendmsg+0x11d/0x140 __sys_sendto+0x405/0x490 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Necesitamos limpiar correctamente todos los recursos emparejados de nivel MPTCP y asegurarnos de liberar el msk al final, incluso cuando el subflujo no aceptado es destruido por los procesos internos de TCP mediante inet_child_forget(). Podemos reutilizar la infra MPTCP_WORK_CLOSE_SUBFLOW existente, comprobando explícitamente que para el escenario crítico: el subflujo cerrado es el de MPC, el msk no es aceptado y finalmente se realiza una limpieza completa. Con este cambio, __mptcp_destroy_sock() siempre se llama en los sockets msk, incluso en los aceptados. Ya no es necesario eliminar temporalmente una referencia sk al clonar msk. Tenga en cuenta que esta confirmación depende de la principal: mptcp: refactorizar la inicialización pasiva del socket.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53073)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/x86/amd/core: Siempre borrar el estado de idx. La variable 'status' (que contiene los bits de desbordamiento no controlados) no se enmascara correctamente en algunos casos, mostrando la siguiente advertencia: ADVERTENCIA: CPU: 156 PID: 475601 en arch/x86/events/amd/core.c:972 amd_pmu_v2_handle_irq+0x216/0x270. Esto parece estar sucediendo porque el bucle continúa antes de que se desactive el bit de estado, en caso de que x86_perf_event_set_period() devuelva 0. Esto también causa una inconsistencia porque el contador "controlado" se incrementa, pero el bit de estado no se limpia. Mueva la limpieza de bits junto arriba, junto cuando se incrementa el contador "controlado".
  • Vulnerabilidad en kernel de Linux (CVE-2023-53074)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: se corrige la advertencia de seguimiento de llamadas ttm_bo en psp_hw_fini. El seguimiento de llamadas se produce al eliminar amdgpu tras el reinicio en modo 1. Durante el reinicio en modo 1, desde la suspensión hasta la reanudación, no es necesario reinicializar el búfer de firmware ta, lo que provocaba un aumento redundante en el recuento de pines de bo. [ 489.885525] Seguimiento de llamadas: [ 489.885525] [ 489.885526] amdttm_bo_put+0x34/0x50 [amdttm] [ 489.885529] amdgpu_bo_free_kernel+0xe8/0x130 [amdgpu] [ 489.885620] psp_free_shared_bufs+0xb7/0x150 [amdgpu] [ 489.885720] psp_hw_fini+0xce/0x170 [amdgpu] [ 489.885815] amdgpu_device_fini_hw+0x2ff/0x413 [amdgpu] [ 489.885960] ? blocking_notifier_chain_unregister+0x56/0xb0 [ 489.885962] amdgpu_driver_unload_kms+0x51/0x60 [amdgpu] [ 489.886049] amdgpu_pci_remove+0x5a/0x140 [amdgpu] [ 489.886132] ? __pm_runtime_resume+0x60/0x90 [ 489.886134] pci_device_remove+0x3e/0xb0 [ 489.886135] __device_release_driver+0x1ab/0x2a0 [ 489.886137] driver_detach+0xf3/0x140 [ 489.886138] bus_remove_driver+0x6c/0xf0 [ 489.886140] driver_unregister+0x31/0x60 [ 489.886141] pci_unregister_driver+0x40/0x90 [ 489.886142] amdgpu_exit+0x15/0x451 [amdgpu]
  • Vulnerabilidad en kernel de Linux (CVE-2023-53075)
    Severidad: ALTA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftrace: Se corrige el acceso a direcciones no válidas en lookup_rec() cuando el índice es 0 KASAN informó el siguiente problema: BUG: KASAN: use-after-free en lookup_rec Lectura de tamaño 8 en la dirección ffff000199270ff0 por la tarea modprobe CPU: 2 Comm: modprobe Rastreo de llamadas: kasan_report __asan_load8 lookup_rec ftrace_location arch_check_ftrace_location check_kprobe_address_safe register_kprobe Al verificar pg->records[pg->index - 1].ip en lookup_rec(), puede obtener un pg que se agregó recientemente a ftrace_pages_start en ftrace_process_locs(). Antes del primer pg->index++, el índice es 0 y acceder a pg->records[-1].ip causará este problema. No verifique la IP cuando pg->index sea 0.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53077)
    Severidad: ALTA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: corregir desplazamiento fuera de los límites en CalculateVMAndRowBytes [POR QUÉ] Cuando PTEBufferSizeInRequests es cero, UBSAN informa la siguiente advertencia porque dml_log2 devuelve un valor negativo inesperado: el exponente de desplazamiento 4294966273 es demasiado grande para el tipo de 32 bits 'int' [CÓMO] En el caso de que PTEBufferSizeInRequests sea cero, omita dml_log2() y asigne el resultado directamente.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53078)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: scsi_dh_alua: Se corrige la fuga de memoria para 'qdata' en alua_activate(). Si alua_rtpg_queue() falla desde alua_activate(), entonces 'qdata' no se libera, lo que causará la siguiente fuga de memoria: objeto sin referencia 0xffff88810b2c6980 (tamaño 32): comm "kworker/u16:2", pid 635322, jiffies 4355801099 (edad 1216426.076s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$............. backtrace: [<0000000098f3a26d>] alua_activate+0xb0/0x320 [<000000003b529641>] scsi_dh_activate+0xb2/0x140 [<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath] [<000000007adc9ace>] process_one_work+0x3c5/0x730 [<00000000c457a985>] worker_thread+0x93/0x650 [<00000000cb80e628>] kthread+0x1ba/0x210 [<00000000a1e61077>] ret_from_fork+0x22/0x30 Solucione el problema liberando 'qdata' en la ruta de error.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53079)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Se corrige la eliminación de las reglas de direccionamiento de las reglas de limpieza de vport mc, uc y multicast en la ruta de desmontaje cuando se produce EEH. Dado que la configuración promisc del vport (uc, mc y todas) en el firmware se restablece después de EEH, el controlador mlx5 intentará eliminar las reglas mencionadas en la ruta de inicialización. Esto provoca un fallo del kernel porque estas reglas de software ya no son válidas. Se corrige anulando estas reglas justo después de la eliminación para evitar el acceso a punteros colgantes. Rastreo de llamadas: __list_del_entry_valid+0xcc/0x100 (unreliable) tree_put_node+0xf4/0x1b0 [mlx5_core] tree_remove_node+0x30/0x70 [mlx5_core] mlx5_del_flow_rules+0x14c/0x1f0 [mlx5_core] esw_apply_vport_rx_mode+0x10c/0x200 [mlx5_core] esw_update_vport_rx_mode+0xb4/0x180 [mlx5_core] esw_vport_change_handle_locked+0x1ec/0x230 [mlx5_core] esw_enable_vport+0x130/0x260 [mlx5_core] mlx5_eswitch_enable_sriov+0x2a0/0x2f0 [mlx5_core] mlx5_device_enable_sriov+0x74/0x440 [mlx5_core] mlx5_load_one+0x114c/0x1550 [mlx5_core] mlx5_pci_resume+0x68/0xf0 [mlx5_core] eeh_report_resume+0x1a4/0x230 eeh_pe_dev_traverse+0x98/0x170 eeh_handle_normal_event+0x3e4/0x640 eeh_handle_event+0x4c/0x370 eeh_event_handler+0x14c/0x210 kthread+0x168/0x1b0 ret_from_kernel_thread+0x5c/0x84
  • Vulnerabilidad en kernel de Linux (CVE-2023-53080)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xsk: Se ha añadido una comprobación de desbordamiento faltante en xdp_umem_reg. El número de fragmentos puede desbordar u32. Asegúrese de devolver -EINVAL en caso de desbordamiento. También se ha eliminado una conversión u32 redundante que asigna umem->npgs.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53081)
    Severidad: ALTA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: se corrige la corrupción de datos tras una escritura fallida. Cuando una escritura en búfer no copia los datos en la página de caché de la página subyacente, ocfs2_write_end_nolock() simplemente pone a cero y contamina la página. Esto puede dejar una página contaminada más allá del EOF. Si la escritura diferida intenta escribir en esta página antes de que la escritura tenga éxito y expande i_size, la página entra en un estado inconsistente donde el bit de página contaminada se borra, pero los bits de búfer contaminados permanecen activos, lo que resulta en que los datos de la página nunca se escriban y, por lo tanto, se pierdan los datos copiados. Se soluciona el problema invalidando la página más allá del EOF tras una escritura fallida.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53083)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: no reemplace la página en rq_pages si es una continuación de la última página la lectura de empalme llama a nfsd_splice_actor para poner las páginas que contienen datos de archivo en la matriz svc_rqst->rq_pages. Sin embargo, es posible obtener un resultado de empalme que solo tenga una página parcial al final, si (p. ej.) el sistema de archivos devuelve una lectura corta que no cubre toda la página. nfsd_splice_actor colocará la página parcial en su matriz rq_pages y retornará. Luego, más tarde, cuando se vuelva a llamar a nfsd_splice_actor, el resto de la página puede terminar llenándose. En este punto, nfsd_splice_actor colocará la página en array _again_ corrompiendo la respuesta. Si esto se repite varias veces, rq_next_page saturará el array y corromperá los campos finales: los punteros rq_respages y rq_next_page. Si ya añadimos la página al array en la última pasada, no la añadamos una segunda vez al tratar con una continuación de empalme. Esto se gestionaba correctamente en nfsd_splice_actor, pero el commit 91e23b1c3982 ("NFSD: Limpiar nfsd_splice_actor()") eliminó la comprobación.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53084)
    Severidad: ALTA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/shmem-helper: Eliminar otro objeto errante en la ruta de error drm_gem_shmem_mmap() no posee una referencia en la ruta del código de error, lo que da como resultado que el objeto GEM shmem dma-buf se libere prematuramente y genere un use-after-free posterior.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53086)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: connac: no verifique el estado de WED para dispositivos que no sean mmio WED solo es compatible con dispositivos mmio, por lo que no lo verifique para dispositivos usb o sdio. Este parche corrige el fallo informado a continuación: [ 21.946627] wlp0s3u1i3: autenticar con c4:41:1e:f5:2b:1d [ 22.525298] wlp0s3u1i3: enviar autenticación a c4:41:1e:f5:2b:1d (intentar 1/3) [ 22.548274] wlp0s3u1i3: autenticar con c4:41:1e:f5:2b:1d [ 22.557694] wlp0s3u1i3: enviar autenticación a c4:41:1e:f5:2b:1d (intentar 1/3) [ 22.565885] wlp0s3u1i3: autenticado [ 22.569502] wlp0s3u1i3: asociar con c4:41:1e:f5:2b:1d (try 1/3) [ 22.578966] wlp0s3u1i3: RX AssocResp de c4:41:1e:f5:2b:1d (capab=0x11 status=30 aid=3) [ 22.579113] wlp0s3u1i3: c4:41:1e:f5:2b:1d rechazó la asociación temporalmente; duración del regreso 1000 TU (1024 ms) [ 23.649518] wlp0s3u1i3: asociado con c4:41:1e:f5:2b:1d (intento 2/3) [ 23.752528] wlp0s3u1i3: RX AssocResp de c4:41:1e:f5:2b:1d (capab=0x11 status=0 aid=3) [ 23.797450] wlp0s3u1i3: asociado [ 24.959527] el kernel intentó ejecutar página protegida por NX - ¿intento de explotación? (uid: 0) [24.959640] ERROR: no se puede manejar el error de página para la dirección: ffff88800c223200 [24.959706] #PF: obtención de instrucción de supervisor en modo kernel [24.959788] #PF: error_code(0x0011) - violación de permisos [24.959846] PGD 2c01067 P4D 2c01067 PUD 2c02067 PMD c2a8063 PTE 800000000c223163 [24.959957] Oops: 0011 [#1] PREEMPT SMP [24.960009] CPU: 0 PID: 391 Comm: wpa_supplicant No contaminado 6.2.0-kvm #18 [ 24.960089] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 01/04/2014 [ 24.960191] RIP: 0010:0xffff88800c223200 [ 24.960446] RSP: 0018:ffffc90000ff7698 EFLAGS: 00010282 [ 24.960513] RAX: ffff888028397010 RBX: ffff88800c26e630 RCX: 0000000000000058 [ 24.960598] RDX: ffff88800c26f844 RSI: 0000000000000006 RDI: ffff888028397010 [ 24.960682] RBP: ffff88800ea72f00 R08: 18b873fbab2b964c R09: be06b38235f3c63c [ 24.960766] R10: 18b873fbab2b964c R11: be06b38235f3c63c R12: 000000000000001 [ 24.960853] R13: ffff88800c26f84c R14: ffff8880063f0ff8 R15: ffff88800c26e644 [24.960950] FS: 00007effcea327c0(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 [24.961036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [24.961106] CR2: ffff88800c223200 CR3: 000000000eaa2000 CR4: 00000000000006b0 [24.961190] Rastreo de llamadas: [24.961219] [ 24.961245] ? mt76_connac_mcu_add_key+0x2cf/0x310 [ 24.961313] ? mt7921_set_key+0x150/0x200 [ 24.961365] ? drv_set_key+0xa9/0x1b0 [ 24.961418] ? ieee80211_key_enable_hw_accel+0xd9/0x240 [ 24.961485] ? ieee80211_key_replace+0x3f3/0x730 [ 24.961541] ? crypto_shash_setkey+0x89/0xd0 [ 24.961597] ? ieee80211_key_link+0x2d7/0x3a0 [ 24.961664] ? crypto_aead_setauthsize+0x31/0x50 [ 24.961730] ? sta_info_hash_lookup+0xa6/0xf0 [ 24.961785] ? ieee80211_add_key+0x1fc/0x250 [ 24.961842] ? rdev_add_key+0x41/0x140 [ 24.961882] ? nl80211_parse_key+0x6c/0x2f0 [ 24.961940] ? nl80211_new_key+0x24a/0x290 [ 24.961984] ? genl_rcv_msg+0x36c/0x3a0 [ 24.962036] ? rdev_mod_link_station+0xe0/0xe0 [ 24.962102] ? nl80211_set_key+0x410/0x410 [ 24.962143] ? nl80211_pre_doit+0x200/0x200 [ 24.962187] ? genl_bind+0xc0/0xc0 [ 24.962217] ? netlink_rcv_skb+0xaa/0xd0 [ 24.962259] ? genl_rcv+0x24/0x40 [ 24.962300] ? netlink_unicast+0x224/0x2f0 [ 24.962345] ? netlink_sendmsg+0x30b/0x3d0 [ 24.962388] ? ____sys_sendmsg+0x109/0x1b0 [ 24.962388] ? ____sys_sendmsg+0x109/0x1b0 [ 24.962440] ? __import_iovec+0x2e/0x110 [ 24.962482] ? ___sys_sendmsg+0xbe/0xe0 [ 24.962525] ? mod_objcg_state+0x25c/0x330 [ 24.962576] ? __dentry_kill+0x19e/0x1d0 [ 24.962618] ? call_rcu+0x18f/0x270 [ 24.962660] ? __dentry_kill+0x19e/0x1d0 [ 24.962702] ? __x64_sys_sendmsg+0x70/0x90 [ 24.962744] ? do_syscall_64+0x3d/0x80 [ 24.962796] ? exit_to_user_mode_prepare+0x1b/0x70 [ 24.962852] ? entry_SYSCA ---truncado---
  • Vulnerabilidad en kernel de Linux (CVE-2023-53087)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/active: Arregla el mal uso de barreras no inactivas como rastreadores de vallas Los usuarios informaron errores en las corrupciones de listas al usar i915 perf con varias aplicaciones gráficas que se ejecutan simultáneamente. El análisis de la causa raíz apuntó a un problema en el código de procesamiento de barreras: una ejecución entre la apertura/cierre de perf que reemplaza las barreras activas con solicitudes de perf en el contexto del kernel y las operaciones de preasignación/adquisición de barreras simultáneas realizadas durante el primer pin/último desanclaje del contexto del usuario. Al agregar una solicitud a un rastreador compuesto, intentamos reutilizar un rastreador de vallas existente, ya asignado y registrado con ese compuesto. El rastreador que obtenemos puede que ya rastree otra valla, puede ser una barrera inactiva o una barrera activa. Si el rastreador que obtenemos ocurre con una barrera no inactiva, entonces intentamos eliminar esa barrera de una lista de tareas de barrera a la que pertenece. Sin embargo, mientras hacemos eso no respetamos el valor de retorno de una función que realiza la eliminación de la barrera. Si la eliminación falla, terminaríamos reutilizando el rastreador aún registrado como tarea de barrera. Dado que el mismo campo de estructura se reutiliza tanto con las listas de devolución de llamadas de valla como con la lista de tareas de barrera, es probable que se produzcan daños en la lista. Ahora, las barreras se eliminan de una lista de tareas de barrera eliminando temporalmente su contenido, recorriéndolo con la omisión del nodo que se va a eliminar y, a continuación, rellenando la lista con el contenido modificado. Si estos intentos de eliminación concurrentes, intencionalmente agresivos, no se serializan, uno o más de ellos podrían fallar debido a que la lista está temporalmente vacía. El código relacionado que ignora los resultados de la eliminación de barrera se introdujo inicialmente en la versión 5.4 mediante el commit d8af05ff38ae ("drm/i915: Permitir compartir la barrera inactiva con otras solicitudes del kernel"). Sin embargo, todos los usuarios de la rutina de eliminación de barrera aparentemente estaban serializados en ese momento, por lo que el problema no se manifestó. Los resultados de git bisect con la ayuda de una prueba IGT igt@gem_barrier_race@remote-request recientemente desarrollada indican que podrían aparecer corrupciones en la lista después deel commit 311770173fac ("drm/i915/gt: Retirada de solicitud de programación cuando la línea de tiempo está inactiva"), introducida en la v5.5. Respetar los resultados de los intentos de eliminación de barreras: marcar la barrera como inactiva solo si se elimina correctamente de la lista. Luego, antes de configurar nuestra barrera como la que se rastrea actualmente, asegurarse de que el rastreador que tenemos no sea una barrera no inactiva. Si la comprobación falla, no usar ese rastreador, sino volver atrás e intentar obtener uno nuevo y utilizable. v3: usar Unlikely() para documentar el resultado esperado (Andi). Corregir errores gramaticales en la descripción de la confirmación. v2: sin cambios de código, - culpar a el commit 311770173fac ("drm/i915/gt: Programar el retiro de solicitudes cuando la línea de tiempo está inactiva"), v5.5, no confirmar d8af05ff38ae ("drm/i915: Permitir compartir la barrera de inactividad con otras solicitudes del kernel"), v5.4, - reformular la descripción deel commit. (Seleccionado de la confirmación 506006055769b10d1b2b4e22f636f3b45e0e9fc7)
  • Vulnerabilidad en kernel de Linux (CVE-2023-53088)
    Severidad: ALTA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: corrección de UaF en el apagado del oyente Como informó Christoph después de haber refactorizado la inicialización del socket pasivo, la ruta de apagado del oyente mptcp es propensa a un problema de UaF. ERROR: KASAN: use-after-free en _raw_spin_lock_bh+0x73/0xe0 Escritura de tamaño 4 en la dirección ffff88810cb23098 por la tarea syz-executor731/1266 CPU: 1 PID: 1266 Comm: syz-executor731 No contaminado 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 Rastreo de llamadas: dump_stack_lvl+0x6e/0x91 print_report+0x16a/0x46f kasan_report+0xad/0x130 kasan_check_range+0x14a/0x1a0 _raw_spin_lock_bh+0x73/0xe0 subflow_error_report+0x6d/0x110 sk_error_report+0x3b/0x190 tcp_disconnect+0x138c/0x1aa0 inet_child_forget+0x6f/0x2e0 inet_csk_listen_stop+0x209/0x1060 __mptcp_close_ssk+0x52d/0x610 mptcp_destroy_common+0x165/0x640 mptcp_destroy+0x13/0x80 __mptcp_destroy_sock+0xe7/0x270 __mptcp_close+0x70e/0x9b0 mptcp_close+0x2b/0x150 inet_release+0xe9/0x1f0 __sock_release+0xd2/0x280 sock_close+0x15/0x20 __fput+0x252/0xa20 task_work_run+0x169/0x250 exit_to_user_mode_prepare+0x113/0x120 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc puede expirar legítimamente entre el último recuento de referencias introducido en mptcp_subflow_queue_clean() y el acceso eventual posterior en inet_csk_listen_stop(). Tras la actualización anterior, ya no necesitamos la limpieza de sockets del receptor MSK con casos especiales: el trabajador de mptcp procesará cada uno de los sockets MSK no aceptados. Simplemente elimine el código innecesario. Tenga en cuenta que esta confirmación depende de las dos principales: mptcp: refactorizar la inicialización pasiva de sockets. mptcp: usar la cola de trabajo para eliminar los sockets no aceptados.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53089)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de tarea bloqueada en ext4_xattr_delete_inode. Syzbot informó de un problema de tarea bloqueada: =================================================================== INFORMACIÓN: La tarea syz-executor232:5073 se bloqueó durante más de 143 segundos. No contaminada. 6.2.0-rc2-syzkaller-00024-g512dee0c00ad #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:syz-exec232 estado:D pila:21024 pid:5073 ppid:5072 indicadores:0x00004004 Rastreo de llamadas: context_switch kernel/sched/core.c:5244 [en línea] __schedule+0x995/0xe20 kernel/sched/core.c:6555 schedule+0xcb/0x190 kernel/sched/core.c:6631 __wait_on_freeing_inode fs/inode.c:2196 [en línea] find_inode_fast+0x35a/0x4c0 fs/inode.c:950 iget_locked+0xb1/0x830 fs/inode.c:1273 __ext4_iget+0x22e/0x3ed0 fs/ext4/inode.c:4861 ext4_xattr_inode_iget+0x68/0x4e0 fs/ext4/xattr.c:389 ext4_xattr_inode_dec_ref_all+0x1a7/0xe50 fs/ext4/xattr.c:1148 ext4_xattr_delete_inode+0xb04/0xcd0 fs/ext4/xattr.c:2880 ext4_evict_inode+0xd7c/0x10b0 fs/ext4/inode.c:296 evict+0x2a4/0x620 fs/inode.c:664 ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474 __ext4_fill_super fs/ext4/super.c:5516 [en línea] ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644 get_tree_bdev+0x400/0x620 fs/super.c:1282 vfs_get_tree+0x88/0x270 fs/super.c:1489 do_new_mount+0x289/0xad0 fs/namespace.c:3145 do_mount fs/namespace.c:3488 [en línea] __do_sys_mount fs/namespace.c:3697 [en línea] __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa5406fd5ea RSP: 002b:00007ffc7232f968 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fa5406fd5ea RDX: 0000000020000440 RSI: 0000000020000000 RDI: 00007ffc7232f970 RBP: 00007ffc7232f970 R08: 00007ffc7232f9b0 R09: 0000000000000432 R10: 0000000000804a03 R11: 0000000000000202 R12: 000000000000004 R13: 0000555556a7a2c0 R14: 00007ffc7232f9b0 R15: 000000000000000 == ... Para resolver este problema, solo necesitamos verificar si el ino del inodo EA y el padre es el mismo antes de obtener el inodo EA.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53090)
    Severidad: ALTA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Se corrige un acceso ilegal a memoria En la función kfd_wait_on_events(), la estructura kfd_event_waiter es asignada por alloc_event_waiters(), pero el campo de evento de la estructura waiter no se inicializa; Cuando copy_from_user() falla en la función kfd_wait_on_events(), ingresará al control de excepciones para liberar la memoria previamente asignada de la estructura waiter; Debido a que se accede al campo de evento de la estructura waiters en la función free_waiters(), esto da como resultado un acceso ilegal a la memoria y un bloqueo del sistema. Aquí está el registro de bloqueo: kernel localhost: RIP: 0010:native_queued_spin_lock_slowpath+0x185/0x1e0 kernel localhost: RSP: 0018:ffffaa53c362bd60 EFLAGS: 00010082 kernel localhost: RAX: ff3d3d6bff4007cb RBX: 0000000000000282 RCX: 00000000002c0000 kernel localhost: RDX: ffff9e855eeacb80 RSI: 000000000000279c RDI: ffffe7088f6a21d0 kernel localhost: RBP: ffffe7088f6a21d0 R08: 00000000002c0000 R09: ffffaa53c362be64 núcleo del host local: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002 núcleo del host local: R13: ffff9e7ead15d600 R14: 0000000000000000 R15: ffff9e7ead15d698 núcleo del host local: FS: 0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:0000000000000000 núcleo localhost: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 núcleo localhost: CR2: 0000152938000010 CR3: 000000044d7a4000 CR4: 00000000003506e0 núcleo localhost: Seguimiento de llamadas: núcleo localhost: _raw_spin_lock_irqsave+0x30/0x40 núcleo localhost: remove_wait_queue+0x12/0x50 núcleo localhost: kfd_wait_on_events+0x1b6/0x490 [hydcu] núcleo localhost: ? ftrace_graph_caller+0xa0/0xa0 núcleo local del host: kfd_ioctl+0x38c/0x4a0 [hydcu] núcleo local del host: ? kfd_ioctl_set_trap_handler+0x70/0x70 [hydcu] núcleo local del host: ? kfd_ioctl_create_queue+0x5a0/0x5a0 [hydcu] núcleo local del host: ? ftrace_graph_caller+0xa0/0xa0 núcleo local del host: __x64_sys_ioctl+0x8e/0xd0 núcleo local del host: ? syscall_trace_enter.isra.18+0x143/0x1b0 kernel localhost: do_syscall_64+0x33/0x80 kernel localhost: entry_SYSCALL_64_after_hwframe+0x44/0xa9 kernel localhost: RIP: 0033:0x152a4dff68d7 Asigne la estructura con kcalloc y elimine la inicialización 0 redundante y una verificación de condición de bucle redundante.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53091)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: actualizar s_journal_inum si cambia después de la reproducción del diario. Al montar una imagen ext4 manipulada, s_journal_inum puede cambiar después de la reproducción del diario, lo cual es obviamente irrazonable porque hemos cargado y reproducido correctamente el diario a través del antiguo s_journal_inum. Y el nuevo s_journal_inum omite algunas de las comprobaciones en ext4_get_journal(), lo que puede desencadenar un problema de desreferencia de puntero nulo. Por lo tanto, si s_journal_inum cambia después de la reproducción del diario, ignoramos el cambio y reescribimos el journal_inum actual en el superbloque.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53092)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: interconexión: exynos: se corrige la pérdida de nodo en la ruta de error de QoS de PM de la sonda Asegúrese de agregar el nodo de interconexión recién asignado al proveedor antes de agregar la solicitud de QoS de PM para que el nodo se libere en caso de errores.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53093)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: No permitir que los valores del histograma tengan modificadores. Los valores del histograma no pueden ser cadenas, seguimientos de pila, gráficos, símbolos, llamadas al sistema ni agruparse en contenedores o registros. Se genera un error si se configura un valor para ello. Tenga en cuenta que el código del histograma no estaba preparado para manejar estos modificadores, lo que provocó un error. Mark Rutland informó: # echo 'p:copy_to_user __arch_copy_to_user n=$arg2' >> /sys/kernel/tracing/kprobe_events # echo 'hist:keys=n:vals=hitcount.buckets=8:sort=hitcount' > /sys/kernel/tracing/events/kprobes/copy_to_user/trigger # cat /sys/kernel/tracing/events/kprobes/copy_to_user/hist [ 143.694628] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000000 [ 143.695190] Información de aborto de memoria: [ 143.695362] ESR = 0x0000000096000004 [ 143.695604] EC = 0x25: DABT (EL actual), IL = 32 bits [ 143.695889] SET = 0, FnV = 0 [ 143.696077] EA = 0, S1PTW = 0 [ 143.696302] FSC = 0x04: fallo de traducción de nivel 0 [ 143.702381] Información de cancelación de datos: [ 143.702614] ISV = 0, ISS = 0x00000004 [ 143.702832] CM = 0, WnR = 0 [ 143.703087] pgtable de usuario: páginas de 4k, VA de 48 bits, pgdp=00000000448f9000 [ 143.703407] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 143.704137] Error interno: Oops: 0000000096000004 [#1] PREEMPT SMP [ 143.704714] Módulos vinculados: [ 143.705273] CPU: 0 PID: 133 Comm: cat No contaminado 6.2.0-00003-g6fc512c10a7c #3 [ 143.706138] Nombre del hardware: linux,dummy-virt (DT) [ 143.706723] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 143.707120] pc : nombre_campo_hist.parte.0+0x14/0x140 [ 143.707504] lr : nombre_campo_hist.parte.0+0x104/0x140 [ 143.707774] sp : ffff800008333a30 [ 143.707952] x29: ffff800008333a30 x28: 0000000000000001 x27: 0000000000400cc0 [ 143.708429] x26: ffffd7a653b20260 x25: 0000000000000000 x24: ffff10d303ee5800 [ 143.708776] x23: ffffd7a6539b27b0 x22: ffff10d303fb8c00 x21: 0000000000000001 [ 143.709127] x20: ffff10d303ec2000 x19: 0000000000000000 x18: 0000000000000000 [ 143.709478] x17: 000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 143.709824] x14: 0000000000000000 x13: 203a6f666e692072 x12: 6567676972742023 [ 143.710179] x11: 0a230a6d6172676f x10: 000000000000002c x9: ffffd7a6521e018c [143.710584] x8: 000000000000002c x7: 7f7f7f7f7f7f7f7f x6: 000000000000002c [ 143.710915] x5 : ffff10d303b0103e x4 : ffffd7a653b20261 x3 : 000000000000003d [ 143.711239] x2 : 0000000000020001 x1 : 0000000000000001 x0 : 0000000000000000 [ 143.711746] Rastreo de llamadas:[ 143.712115] hist_field_name.part.0+0x14/0x140 [ 143.712642] hist_field_name.part.0+0x104/0x140 [ 143.712925] hist_field_print+0x28/0x140 [ 143.713125] event_hist_trigger_print+0x174/0x4d0 [ 143.713348] hist_show+0xf8/0x980 [ 143.713521] seq_read_iter+0x1bc/0x4b0 [ 143.713711] seq_read+0x8c/0xc4 [ 143.713876] vfs_read+0xc8/0x2a4 [ 143.714043] ksys_read+0x70/0xfc [ 143.714218] __arm64_sys_read+0x24/0x30 [ 143.714400] invoke_syscall+0x50/0x120 [ 143.714587] el0_svc_common.constprop.0+0x4c/0x100 [ 143.714807] do_el0_svc+0x44/0xd0 [ 143.714970] el0_svc+0x2c/0x84 [ 143.715134] el0t_64_sync_handler+0xbc/0x140 [ 143.715334] el0t_64_sync+0x190/0x194 [ 143.715742] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (f9400000) [ 143.716510]--- Fallo de segmentación
  • Vulnerabilidad en kernel de Linux (CVE-2023-53094)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: serial: fsl_lpuart: fix race on RX DMA shutting De vez en cuando, la finalización de DMA puede llegar en medio del shutting de DMA: : : lpuart32_shutdown() lpuart_dma_shutdown() del_timer_sync() lpuart_dma_rx_complete() lpuart_copy_rx_to_tty() mod_timer() lpuart_dma_rx_free() Cuando el temporizador se activa un poco más tarde, sport->dma_rx_desc es NULL: No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000004 pc : lpuart_copy_rx_to_tty+0xcc/0x5bc lr : lpuart_timer_func+0x1c/0x2c Rastreo de llamadas: lpuart_copy_rx_to_tty lpuart_timer_func call_timer_fn __run_timers.part.0 run_timer_softirq __do_softirq __irq_exit_rcu irq_exit handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler ... Para solucionar esto, incorpore del_timer_sync() en lpuart_dma_rx_free() después de dmaengine_terminate_sync() para asegurarse de que el temporizador no se reinicie en lpuart_copy_rx_to_tty() <= lpuart_dma_rx_complete().
  • Vulnerabilidad en kernel de Linux (CVE-2023-53095)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/ttm: Corregir una desreferencia de puntero NULL. El mecanismo LRU puede buscar un recurso en proceso de ser eliminado de un objeto. Las reglas de bloqueo aquí son un poco confusas, pero actualmente parece que la asignación res->bo está protegida por el bloqueo LRU, mientras que bo->resource está protegida por el bloqueo de objeto, mientras que la *limpieza* de bo->resource también está protegida por el bloqueo LRU. Esto significa que si comprobamos que bo->resource apunta al recurso LRU bajo el bloqueo LRU, deberíamos estar seguros. Así que realice esa comprobación antes de decidir intercambiar un bo. Esto evita la desreferencia de un bo->resource NULL en ttm_bo_swapout().
  • Vulnerabilidad en kernel de Linux (CVE-2023-53096)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: interconexión: se corrige una pérdida de memoria al liberar nodos. La matriz de enlaces de nodos se asigna cuando se agregan enlaces a un nodo, pero no se desasigna cuando se destruyen los nodos.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53097)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/iommu: se corrige una fuga de memoria con debugfs_lookup(). Al llamar a debugfs_lookup(), se debe ejecutar dput() en el resultado; de lo contrario, la fuga de memoria se producirá con el tiempo. Para simplificar, simplemente llame a debugfs_lookup_and_remove(), que gestiona toda la lógica a la vez.
  • Vulnerabilidad en kernel de Linux (CVE-2023-53098)
    Severidad: MEDIA
    Fecha de publicación: 02/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: rc: gpio-ir-recv: agregar función de eliminación En caso de que PM en tiempo de ejecución esté habilitado, realice una limpieza de PM en tiempo de ejecución para eliminar la solicitud de calidad de servicio de latencia de la CPU; de lo contrario, la eliminación del controlador puede tener el siguiente volcado de kernel: [19.463299] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000048 [19.472161] Información de aborto de memoria: [19.474985] ESR = 0x0000000096000004 [19.478754] EC = 0x25: DABT (EL actual), IL = 32 bits [19.484081] SET = 0, FnV = 0 [19.487149] EA = 0, S1PTW = 0 [ [19.490361] FSC = 0x04: error de traducción de nivel 0 [19.495256] Información de cancelación de datos: [19.498149] ISV = 0, ISS = 0x00000004 [19.501997] CM = 0, WnR = 0 [19.504977] usuario pgtable: páginas de 4k, VA de 48 bits, pgdp=0000000049f81000 [ 19.511432] [0000000000000048] pgd=0000000000000000, p4d=0000000000000000 [ 19.518245] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 19.524520] Modules linked in: gpio_ir_recv(+) rc_core [last unloaded: rc_core] [ 19.531845] CPU: 0 PID: 445 Comm: insmod Not tainted 6.2.0-rc1-00028-g2c397a46d47c #72 [ 19.531854] Hardware name: FSL i.MX8MM EVK board (DT) [ 19.531859] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.551777] pc : cpu_latency_qos_remove_request+0x20/0x110 [ 19.557277] lr : gpio_ir_recv_runtime_suspend+0x18/0x30 [gpio_ir_recv] [ 19.557294] sp : ffff800008ce3740 [ 19.557297] x29: ffff800008ce3740 x28: 0000000000000000 x27: ffff800008ce3d50 [ 19.574270] x26: ffffc7e3e9cea100 x25: 00000000000f4240 x24: ffffc7e3f9ef0e30 [ 19.574284] x23: 0000000000000000 x22: ffff0061803820f4 x21: 0000000000000008 [ 19.574296] x20: ffffc7e3fa75df30 x19: 0000000000000020 x18: ffffffffffffffff [ 19.588570] x17: 0000000000000000 x16: ffffc7e3f9efab70 x15: ffffffffffffffff [ 19.595712] x14: ffff800008ce37b8 x13: ffff800008ce37aa x12: 0000000000000001 [ 19.602853] x11: 0000000000000001 x10: ffffcbe3ec0dff87 x9 : 0000000000000008 [ 19.609991] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 000000000f0bfe9f [ 19.624261] x5 : 00ffffffffffffff x4 : 0025ab8e00000000 x3 : ffff006180382010 [ 19.631405] x2 : ffffc7e3e9ce8030 x1 : ffffc7e3fc3eb810 x0 : 0000000000000020 [ 19.638548] Call trace: [ 19.640995] cpu_latency_qos_remove_request+0x20/0x110 [ 19.646142] gpio_ir_recv_runtime_suspend+0x18/0x30 [gpio_ir_recv] [ 19.652339] pm_generic_runtime_suspend+0x2c/0x44 [ 19.657055] __rpm_callback+0x48/0x1dc [ 19.660807] rpm_callback+0x6c/0x80 [ 19.664301] rpm_suspend+0x10c/0x640 [ 19.667880] rpm_idle+0x250/0x2d0 [ 19.671198] update_autosuspend+0x38/0xe0 [ 19.675213] pm_runtime_set_autosuspend_delay+0x40/0x60 [ 19.680442] gpio_ir_recv_probe+0x1b4/0x21c [gpio_ir_recv] [ 19.685941] platform_probe+0x68/0xc0 [ 19.689610] really_probe+0xc0/0x3dc [ 19.693189] __driver_probe_device+0x7c/0x190 [ 19.697550] driver_probe_device+0x3c/0x110 [ 19.701739] __driver_attach+0xf4/0x200 [ 19.705578] bus_for_each_dev+0x70/0xd0 [ 19.709417] driver_attach+0x24/0x30 [ 19.712998] bus_add_driver+0x17c/0x240 [ 19.716834] driver_register+0x78/0x130 [ 19.720676] __platform_driver_register+0x28/0x34 [ 19.725386] gpio_ir_recv_driver_init+0x20/0x1000 [gpio_ir_recv] [ 19.731404] do_one_initcall+0x44/0x2ac [ 19.735243] do_init_module+0x48/0x1d0 [ 19.739003] load_module+0x19fc/0x2034 [ 19.742759] __do_sys_finit_module+0xac/0x12c [ 19.747124] __arm64_sys_finit_module+0x20/0x30 [ 19.751664] invoke_syscall+0x48/0x114 [ 19.755420] el0_svc_common.constprop.0+0xcc/0xec [ 19.760132] do_el0_svc+0x38/0xb0 [ 19.763456] el0_svc+0x2c/0x84 [ 19.766516] el0t_64_sync_handler+0xf4/0x120 [ 19.770789] el0t_64_sync+0x190/0x194 [ 19.774460] Code: 910003fd a90153f3 aa0003f3 91204021 (f9401400) [ 19.780556] ---[ fin de seguimiento 0000000000000000 ]---
  • Vulnerabilidad en kernel de Linux (CVE-2025-37809)
    Severidad: MEDIA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: class: Fix. Acceso a punteros nulos. Las llamadas simultáneas a typec_partner_unlink_device pueden provocar una desreferencia de punteros nulos. Este parche añade un mutex para proteger los punteros de dispositivos USB y evitar este problema. Este mismo mutex protege tanto los punteros de dispositivo como el registro del dispositivo asociado.
  • Vulnerabilidad en kernel de Linux (CVE-2025-37810)
    Severidad: ALTA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: gadget: comprobar que el recuento de eventos no supere la longitud del búfer de eventos. El recuento de eventos se lee del registro DWC3_GEVNTCOUNT. Se comprueba que el recuento sea cero, pero no que supere la longitud del búfer de eventos. Se comprueba que el recuento de eventos no supere la longitud del búfer de eventos, lo que evita un acceso fuera de los límites al copiar el evento a memoria. Registro de fallos: No se puede gestionar la solicitud de paginación del núcleo en la dirección virtual ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Rastreo de llamadas: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34
  • Vulnerabilidad en kernel de Linux (CVE-2025-37811)
    Severidad: MEDIA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: chipidea: ci_hdrc_imx: corrección del manejo de usbmisc. usbmisc es una propiedad opcional del dispositivo, por lo que es totalmente válido que el valor correspondiente de data->usbmisc_data sea nulo. Verifique esto antes de desreferenciar el puntero. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con la herramienta de análisis estático Svace.
  • Vulnerabilidad en kernel de Linux (CVE-2025-37812)
    Severidad: MEDIA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: cdns3: Corrección de interbloqueo al usar el gadget NCM. El controlador cdns3 presenta el mismo interbloqueo NCM corregido en cdnsp mediante el commit 58f2fcb3a845 ("usb: cdnsp: Corrección de un problema de interbloqueo durante el uso del gadget NCM"). Bajo PREEMPT_RT, el interbloqueo puede activarse fácilmente por tráfico de red intenso, por ejemplo, al usar "iperf --bidir" a través de un enlace Ethernet NCM. El interbloqueo se produce porque el manejador de interrupciones en subprocesos es interrumpido por un softirq, pero ambos están protegidos por el mismo bloqueo de giro. Para evitar el interbloqueo, desactive el softirq durante el controlador de interrupciones en subprocesos.
  • Vulnerabilidad en kernel de Linux (CVE-2025-37813)
    Severidad: MEDIA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: xhci: Corregir desreferencia de puntero no válida en el workaround de Etron Esta comprobación se realiza antes de prepare_transfer() y prepare_ring(), por lo que enqueue ya puede apuntar al TRB de enlace final de un segmento. Y de hecho lo hará, alrededor del 0,4% de las veces que se llama a este código. Entonces enqueue + 1 es un puntero no válido. Hará que el kernel se caiga de inmediato o cargará algo basura que puede parecer un TRB de enlace y hacer que el TRB de enlace real se reemplace con un NOOP. Esto no terminaría bien. Utilice una prueba funcionalmente equivalente que no desreferencia el puntero y siempre dé un resultado correcto. Algo ha hecho que mi máquina se caiga dos veces en los últimos días mientras jugaba con un Etron HC, y una prueba de estrés de transferencia de control ejecutada para confirmación la acaba de hacer caer de nuevo. La misma prueba pasa con este parche aplicado.
  • Vulnerabilidad en kernel de Linux (CVE-2025-37814)
    Severidad: MEDIA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: Requerir CAP_SYS_ADMIN para todos los usos de TIOCL_SELMOUSEREPORT Este requisito se flexibilizó con mucho entusiasmo en el commit 2f83e38a095f ("tty: Permitir algunos modos TIOCL_SETSEL sin CAP_SYS_ADMIN"), pero resulta que (1) la lógica que implementé allí era inconsistente (¡disculpas!), (2) TIOCL_SELMOUSEREPORT en realidad puede ser un pequeño riesgo de seguridad después de todo, y (3) TIOCL_SELMOUSEREPORT solo está destinado a ser utilizado por el demonio del mouse (GPM o Consolation), que ya se ejecuta como CAP_SYS_ADMIN. Más detalles: 1. El parche anterior tiene una lógica inconsistente: En el commit 2f83e38a095f ("tty: Permitir algunos modos TIOCL_SETSEL sin CAP_SYS_ADMIN"), verificamos que sel_mode == TIOCL_SELMOUSEREPORT, pero pasamos por alto que los cuatro bits inferiores de este parámetro "mode" se usaban como una forma adicional de pasar un argumento. Por lo tanto, el parche seguía requiriendo CAP_SYS_ADMIN si alguno de los bits del botón del ratón estaba configurado, pero no lo requería si ninguno de los bits del botón del ratón estaba configurado. Esta lógica es inconsistente y no fue intencional. Deberíamos tener las mismas políticas para usar TIOCL_SELMOUSEREPORT, independientemente del valor del argumento "oculto" del botón del ratón. Envié un parche de documentación aparte a la lista de páginas del manual con más detalles sobre TIOCL_SELMOUSEREPORT: https://lore.kernel.org/all/20250223091342.35523-2-gnoack3000@gmail.com/ 2. TIOCL_SELMOUSEREPORT constituye un riesgo de seguridad potencial que puede permitir a un atacante simular la entrada de teclado en aplicaciones de línea de comandos en la misma terminal, como TIOCSTI y otras IOCTL de "modo de selección" de TIOCLINUX. Al habilitar los informes del ratón en una terminal y luego inyectarlos mediante TIOCL_SELMOUSEREPORT, un atacante puede simular los movimientos del ratón en la misma terminal, de forma similar a los ataques de inyección de pulsaciones de teclas de TIOCSTI que antes eran posibles con TIOCSTI y otros modos de selección de TIOCL_SETSEL. Muchos programas (incluidos libreadline/bash) tienden a malinterpretar estos informes del ratón como una entrada normal del teclado, ya que no esperan una entrada en el formato del protocolo X11. El atacante no tiene control total sobre la secuencia de escape, pero al menos puede controlar los valores de dos bytes consecutivos en la secuencia de escape binaria del informe del ratón. Entré en más detalles sobre eso en la discusión en https://lore.kernel.org/all/20250221.0a947528d8f3@gnoack.org/ No es igualmente trivial simular pulsaciones de teclas arbitrarias como lo fue con TIOCSTI (commit 83efeeeb3d04 ("tty: Permitir que TIOCSTI sea deshabilitado")), pero el mecanismo general está ahí, y junto con la pequeña cantidad de casos de uso legítimos existentes (ver a continuación), sería mejor volver a requerir CAP_SYS_ADMIN para TIOCL_SELMOUSEREPORT, como ya era el caso antes del commit 2f83e38a095f ("tty: Permitir algunos modos TIOCL_SETSEL sin CAP_SYS_ADMIN"). 3. TIOCL_SELMOUSEREPORT solo lo utilizan los daemons de ratón (GPM o Consolation), y son el único caso de uso legítimo: Para citar console_codes(4): La función de seguimiento del ratón está diseñada para devolver informes de estado del ratón compatibles con xterm(1). Dado que el controlador de consola no puede conocer el dispositivo ni el tipo de ratón, estos informes se devuelven en el flujo de entrada de la consola solo cuando el controlador del terminal virtual recibe una instrucción ioctl de actualización del ratón. Estas instrucciones ioctl deben ser generadas por una aplicación en modo usuario que admita el ratón, como el daemon gpm(8). Jared Finder también ha confirmado en https://lore.kernel.org/all/491f3df9de6593df8e70dbe77614b026@finder.org/ que Emacs no llama a TIOCL_SELMOUSEREPORT directamente, y sería difícil encontrar buenas razones para hacerlo, dado que interferiría con los ---truncado---
  • Vulnerabilidad en kernel de Linux (CVE-2025-37815)
    Severidad: MEDIA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: microchip: pci1xxxx: Se corrige el pánico del kernel durante el registro del controlador de IRQ. Se resuelve el pánico del kernel al acceder al controlador de IRQ asociado con la IRQ generada. Esto se logra adquiriendo el bloqueo de giro y almacenando el estado actual de la interrupción antes de procesar la solicitud de interrupción mediante generic_handle_irq. Se envió un parche de corrección anterior donde 'generic_handle_irq' se reemplazó por 'handle_nested_irq'. Sin embargo, este cambio también causa el pánico del kernel, que, tras determinar qué GPIO activó la interrupción e intentar llamar a handle_nested_irq con el número de IRQ asignado, provoca un error al localizar el controlador registrado.
  • Vulnerabilidad en kernel de Linux (CVE-2025-37816)
    Severidad: MEDIA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mei: vsc: Se corrige el problema de fortify-panic causado por el uso no válido de counted_by() gcc 15 respeta el atributo __counted_by(len) en vsc_tp_packet.buf[] y el código vsc-tp.c lo usa de manera incorrecta. len no contiene el tamaño disponible en el búfer, contiene la longitud real del paquete *sin* el crc. Entonces, tan pronto como vsc_tp_xfer() intenta agregar el crc a buf[], se activa el controlador fortify-panic: [80.842193] memcpy: desbordamiento de búfer detectado: escritura de 4 bytes de tamaño de búfer 0 [80.842243] ADVERTENCIA: CPU: 4 PID: 272 en lib/string_helpers.c:1032 __fortify_report+0x45/0x50 ... [80.843175] __fortify_panic+0x9/0xb [80.843186] vsc_tp_xfer.cold+0x67/0x67 [mei_vsc_hw] [80.843210] ? lockdep_hardirqs_on+0x7c/0x110 [ 80.843250] mei_vsc_hw_start+0x98/0x120 [mei_vsc] [ 80.843270] mei_reset+0x11d/0x420 [mei] La solución más fácil sería simplemente omitir el conteo, pero con la excepción del búfer de reconocimiento en vsc_tp_xfer_helper() que solo contiene suficiente espacio para el encabezado del paquete, todos los demás usos de vsc_tp_packet siempre usan un búfer de VSC_TP_MAX_XFER_SIZE bytes para el paquete. En lugar de simplemente eliminar el conteo, divida la definición de la estructura vsc_tp_packet en un encabezado y una definición de paquete completo y use un buf[] de tamaño fijo en la definición del paquete, de esta manera la verificación de desbordamiento del búfer de fortify-source aún funciona cuando está habilitada.
  • Vulnerabilidad en kernel de Linux (CVE-2025-37817)
    Severidad: ALTA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mcb: se corrige un error de doble liberación en chameleon_parse_gdd(). En chameleon_parse_gdd(), si mcb_device_register() falla, se libera 'mdev' en mcb_device_register() mediante put_device(). Por lo tanto, ir a la etiqueta 'err' y liberar 'mdev' de nuevo provoca una doble liberación. Simplemente retorne si mcb_device_register() falla.
  • Vulnerabilidad en kernel de Linux (CVE-2025-37818)
    Severidad: MEDIA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Devuelve NULL desde huge_pte_offset() para PMD no válido. La función huge_pte_offset() de LoongArch actualmente devuelve un puntero a una ranura PMD incluso si la entrada subyacente apunta a invalid_pte_table (lo que indica que no hay asignación). Llamadores como smaps_hugetlb_range() obtienen este valor de entrada no válido (la dirección de invalid_pte_table) a través de este puntero. La comprobación genérica is_swap_pte() identifica incorrectamente esta dirección como una entrada de intercambio en LoongArch, ya que cumple las condiciones "!pte_present() && !pte_none()". Esta interpretación errónea, combinada con una coincidencia de is_migration_entry() en los bits de dirección, provoca fallos del kernel en pfn_swap_entry_to_page(). Solucione esto a nivel de arquitectura modificando huge_pte_offset() para comprobar el contenido de la entrada PMD mediante pmd_none() antes de regresar. Si la entrada no es válida (es decir, apunta a invalid_pte_table), devuelva NULL en lugar del puntero a la ranura.
  • Vulnerabilidad en kernel de Linux (CVE-2025-37819)
    Severidad: ALTA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: irqchip/gic-v2m: Impedir el uso tras la liberación de gicv2m_get_fwnode() Con ACPI en su lugar, gicv2m_get_fwnode() se registra en el subsistema pci como pci_msi_get_fwnode_cb(), que puede invocarse en tiempo de ejecución durante un sondeo de puente de host PCI. Pero, la devolución de llamada se marca erróneamente como __init, lo que provoca que se libere, mientras se registra en el subsistema PCI y podría desencadenar: No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548 Esto es fácilmente reproducible en una placa Juno con arranque ACPI. Conserve la función para uso posterior.
  • Vulnerabilidad en kernel de Linux (CVE-2025-37820)
    Severidad: MEDIA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen-netfront: manejador NULL devuelto por xdp_convert_buff_to_frame(). La función xdp_convert_buff_to_frame() puede devolver NULL si no convierte correctamente el búfer XDP en un marco XDP debido a limitaciones de memoria, errores internos o datos no válidos. No comprobar si hay NULL puede provocar una desreferencia de puntero NULL si el resultado se utiliza más adelante en el procesamiento, lo que puede causar fallos, corrupción de datos o un comportamiento indefinido. En caso de fallo en la redirección XDP, la página asociada debe liberarse explícitamente si se retuvo previamente mediante get_page(). No hacerlo puede provocar una fuga de memoria, ya que el recuento de referencias de páginas no se reduce.
  • Vulnerabilidad en kernel de Linux (CVE-2025-37821)
    Severidad: MEDIA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/eevdf: Se soluciona que se->slice se establezca en U64_MAX y el bloqueo resultante Hay una ruta de código en dequeue_entities() que puede establecer el slice de un sched_entity en U64_MAX, lo que a veces resulta en un bloqueo. El caso ofensivo es cuando se llama a dequeue_entities() para sacar de la cola una entidad de grupo retrasada y luego se retrasa la salida de la cola del padre de la entidad. En ese caso: 1. En el bloque if (entity_is_task(se)) else al comienzo de dequeue_entities(), slice se establece en cfs_rq_min_slice(group_cfs_rq(se)). Si la entidad se retrasó, entonces no tiene tareas en cola, por lo que cfs_rq_min_slice() devuelve U64_MAX. 2. El primer bucle for_each_sched_entity() saca de la cola la entidad. 3. Si la entidad era la única hija de su padre, la siguiente iteración intenta sacar de la cola al padre. 4. Si es necesario retrasar la salida de la cola del padre, se interrumpe desde el primer bucle for_each_sched_entity() _sin actualizar la porción_. 5. El segundo bucle for_each_sched_entity() establece la porción -> del padre en la porción guardada, que sigue siendo U64_MAX. Esto altera los cálculos posteriores con resultados potencialmente catastróficos. Una manifestación que vimos en producción fue: 6. En update_entity_lag(), se->slice se usa para calcular el límite, que termina como un número negativo enorme. 7. limit se usa en se->vlag = clamp(vlag, -limit, limit). Como limit es negativo, vlag > limit, por lo que se->vlag se establece en el mismo número negativo enorme. 8. En place_entity(), se->vlag se escala, lo que se desborda y da como resultado otro número enorme (positivo o negativo). 9. El retardo ajustado se resta de se->vruntime, lo que aumenta o disminuye se->vruntime considerablemente. 10. pick_eevdf() llama a entity_eligible()/vruntime_eligible(), que devuelve incorrectamente "false" debido a la gran distancia entre el vruntime y los demás vruntimes de la cola, lo que provoca un desbordamiento del cálculo de carga (vruntime - cfs_rq->min_vruntime) *. 11. Nada parece ser elegible, por lo que pick_eevdf() devuelve NULL. 12. pick_next_entity() intenta desreferenciar el valor de retorno de pick_eevdf() y se bloquea. Volcar los estados de cfs_rq desde los volcados de núcleo con drgn mostró rangos de tiempo de ejecución virtuales enormes y valores de vlag falsos, y también rastreé que se->slice se configuraba en U64_MAX en sistemas en vivo (lo cual solía ser "benigno", ya que el resto de la cola de ejecución debía estar en un estado específico para fallar). Corríjalo en dequeue_entities() configurando siempre slice desde el primer cfs_rq no vacío.
  • Vulnerabilidad en kernel de Linux (CVE-2025-37826)
    Severidad: MEDIA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: Añadir comprobación de valores nulos en ufshcd_mcq_compl_pending_transfer(). Añadir una comprobación de valores nulos para el puntero hwq devuelto por ufshcd_mcq_req_to_hwq(). Esto es similar a la corrección en el commit 74736103fb41 ("scsi: ufs: core: Corregir el problema de ejecuciones de ufshcd_abort_one").
  • Vulnerabilidad en kernel de Linux (CVE-2025-37827)
    Severidad: MEDIA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zoned: return EIO on RAID1 block group write pointer mismatch Hubo un informe de error sobre una desreferencia de puntero NULL en __btrfs_add_free_space_zoned() que en última instancia ocurre debido a una conversión del perfil de metadatos predeterminado DUP a un perfil RAID1 en dos discos. El seguimiento de la pila tiene la siguiente firma: Error BTRFS (dispositivo sdc): zoned: desajuste del desplazamiento del puntero de escritura de las zonas en el perfil raid1 ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000058 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:__btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 RSP: 0018:ffffa236b6f3f6d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff96c8132f3400 RCX: 0000000000000001 RDX: 0000000010000000 RSI: 0000000000000000 RDI: ffff96c8132f3410 RBP: 0000000010000000 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000 R13: ffff96c758f65a40 R14: 0000000000000001 R15: 000011aac0000000 FS: 00007fdab1cb2900(0000) GS:ffff96e60ca00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000058 CR3: 00000001a05ae000 CR4: 0000000000350ef0 Seguimiento de llamadas: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15c/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 btrfs_add_free_space_async_trimmed+0x34/0x40 btrfs_add_new_free_space+0x107/0x120 btrfs_make_block_group+0x104/0x2b0 btrfs_create_chunk+0x977/0xf20 btrfs_chunk_alloc+0x174/0x510 ? srso_return_thunk+0x5/0x5f btrfs_inc_block_group_ro+0x1b1/0x230 btrfs_relocate_block_group+0x9e/0x410 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x8ac/0x12b0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? __kmalloc_cache_noprof+0x14c/0x3e0 btrfs_ioctl+0x2686/0x2a80 ? srso_return_thunk+0x5/0x5f ? ioctl_has_perm.constprop.0.isra.0+0xd2/0x120 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x82/0x160 ? srso_return_thunk+0x5/0x5f ? __memcg_slab_free_hook+0x11a/0x170 ? srso_return_thunk+0x5/0x5f ? kmem_cache_free+0x3f0/0x450 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? sysfs_emit+0xaf/0xc0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? seq_read_iter+0x207/0x460 ? srso_return_thunk+0x5/0x5f ? vfs_read+0x29c/0x370 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? srso_return_thunk+0x5/0x5f ? exc_page_fault+0x7e/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdab1e0ca6d RSP: 002b:00007ffeb2b60c80 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdab1e0ca6d RDX: 00007ffeb2b60d80 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 00007ffeb2b60cd0 R08: 0000000000000000 R09: 0000000000000013 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffeb2b6343b R14: 00007ffeb2b60d80 R15: 0000000000000001 CR2: 0000000000000058 ---[ fin del seguimiento 000000000000000 ]--- La primera línea es la más interesante aquí: Error BTRFS (dispositivo sdc): zoned: discrepancia en el desplazamiento del puntero de escritura de las zonas en el perfil RAID1. Cuando se crea un grupo de bloques RAID1 y se detecta una discrepancia en el desplazamiento del puntero de escritura entre los discos del conjunto RAID, btrfs establece el valor de alloc_offset en la longitud del grupo de bloques, marcándolo como lleno. Posteriormente, el código espera que una operación de balance evacue los datos de este grupo de bloques y solucione los problemas. Sin embargo, antes de que esto sea posible, el nuevo espacio de este grupo de bloques se contabilizará en la caché de espacio libre. ---truncado---
  • Vulnerabilidad en kernel de Linux (CVE-2025-37829)
    Severidad: MEDIA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: scpi: Corregir null-ptr-deref en scpi_cpufreq_get_rate() cpufreq_cpu_get_raw() puede devolver NULL cuando la CPU de destino no está presente en la máscara policy->cpus. scpi_cpufreq_get_rate() no verifica este caso, lo que da como resultado una desreferencia de puntero NULL.
  • Vulnerabilidad en kernel de Linux (CVE-2025-37830)
    Severidad: MEDIA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: scmi: Se corrige la corrección de null-ptr-deref en scmi_cpufreq_get_rate(). cpufreq_cpu_get_raw() puede devolver NULL cuando la CPU de destino no está presente en la máscara policy->cpus. scmi_cpufreq_get_rate() no comprueba este caso, lo que resulta en una desreferencia de puntero NULL. Añadir la comprobación de NULL después de cpufreq_cpu_get_raw() para evitar este problema.
  • Vulnerabilidad en kernel de Linux (CVE-2025-37831)
    Severidad: MEDIA
    Fecha de publicación: 08/05/2025
    Fecha de última actualización: 12/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: apple-soc: Se corrige null-ptr-deref en apple_soc_cpufreq_get_rate() cpufreq_cpu_get_raw() puede devolver NULL cuando la CPU de destino no está presente en la máscara policy->cpus. apple_soc_cpufreq_get_rate() no verifica este caso, lo que da como resultado una desreferencia de puntero NULL.