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-21956)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Asignar normalized_pix_clk cuando la profundidad de color es 14 [POR QUÉ Y CÓMO] Se produce un mensaje de advertencia "ADVERTENCIA: CPU: 4 PID: 459 en ... /dc_resource.c:3397 calculate_phy_pix_clks+0xef/0x100 [amdgpu]" porque no se gestiona la profundidad de color de la pantalla = COLOR_DEPTH_141414. Esto se observa en la Radeon RX 6600 XT. Se soluciona asignando pix_clk * (14 * 3) / 24, igual que el resto. También se corrige la sangría en get_norm_pix_clk. (Seleccionado de el commit 274a87eb389f58eddcbc5659ab0b180b37e92775)
Vulnerabilidad en kernel de Linux (CVE-2025-21958)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "openvswitch: cambiar al conteo de etiquetas por acción en conntrack". Actualmente, ovs_ct_set_labels() solo se llama para entradas de conntrack confirmadas (ct) dentro de ovs_ct_commit(). Sin embargo, si la entrada de conntrack no tiene la extensión labels_ext, al intentar asignarla en ovs_ct_get_conn_labels() para una entrada confirmada, se genera una advertencia en nf_ct_ext_add(): WARN_ON(nf_ct_is_confirmed(ct)); Esto ocurre cuando la entrada de conntrack se crea externamente antes de que OVS incremente net->ct.labels_used. El problema se ha vuelto más frecuente desde el commit fcb1aa5163b1 ("openvswitch: cambio al conteo de etiquetas por acción en conntrack"), que cambió para usar el conteo de etiquetas por acción e incrementar net->ct.labels_used al agregar un flujo con la acción ct. Dado que actualmente no existe una solución directa para este problema, esta reversión de el commit evita la interrupción de los casos de uso existentes.
Vulnerabilidad en kernel de Linux (CVE-2025-21960)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: bnxt: no actualice la suma de comprobación en bnxt_xdp_build_skb() El bnxt_rx_pkt() actualiza el valor de ip_summed al final si la descarga de suma de comprobación está habilitada. Cuando se adjunta el programa XDP-MB y devuelve XDP_PASS, se llama a bnxt_xdp_build_skb() para actualizar skb_shared_info. El propósito principal de bnxt_xdp_build_skb() es actualizar skb_shared_info, pero también actualiza el valor de ip_summed si la descarga de suma de comprobación está habilitada. En realidad, esto es trabajo duplicado. Cuando bnxt_rx_pkt() actualiza el valor de ip_summed, verifica si ip_summed es CHECKSUM_NONE o no. Significa que ip_summed debería ser CHECKSUM_NONE en este momento. Pero es posible que ip_summed ya esté actualizado a CHECKSUM_UNNECESSARY en la ruta XDP-MB-PASS. Por lo tanto, skb_checksum_none_assert() advierte al respecto. Esto implica trabajo duplicado y no es necesario actualizar ip_summed en bnxt_xdp_build_skb(). El mensaje aparece así: ADVERTENCIA: CPU: 3 PID: 5782 en ./include/linux/skbuff.h:5155 bnxt_rx_pkt+0x479b/0x7610 [bnxt_en] Módulos vinculados: bnxt_re bnxt_en rdma_ucm rdma_cm iw_cm ib_cm ib_uverbs veth xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_] CPU: 3 UID: 0 PID: 5782 Comm: socat Contaminado: GW 6.14.0-rc4+ #27 Contaminado: [W]=WARN Nombre del hardware: Nombre del producto del sistema ASUS/PRIME Z690-P D4, BIOS 0603 11/01/2021 RIP: 0010:bnxt_rx_pkt+0x479b/0x7610 [bnxt_es] Código: 54 24 0c 4c 89 f1 4c 89 ff c1 ea 1f ff d3 0f 1f 00 49 89 c6 48 85 c0 0f 84 4c e5 ff ff 48 89 c7 e8 ca 3d a0 c8 e9 8f f4 ff ff <0f> 0b f RSP: 0018:ffff88881ba09928 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000c7590303 RCX: 0000000000000000 RDX: 1ffff1104e7d1610 RSI: 0000000000000001 RDI: ffff8881c91300b8 RBP: ffff88881ba09b28 R08: ffff888273e8b0d0 R09: ffff888273e8b070 R10: ffff888273e8b010 R11: ffff888278b0f000 R12: ffff888273e8b080 R13: ffff8881c9130e00 R14: ffff8881505d3800 R15: ffff888273e8b000 FS: 00007f5a2e7be080(0000) GS:ffff88881ba00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fff2e708ff8 CR3: 000000013e3b0000 CR4: 00000000007506f0 PKRU: 55555554 Rastreo de llamadas: ? __warn+0xcd/0x2f0 ? bnxt_rx_pkt+0x479b/0x7610 ? report_bug+0x326/0x3c0 ? __pfx_bnxt_rx_pkt+0x10/0x10 ? __bnxt_poll_work+0x4e8/0x1220 ? __pfx___bnxt_poll_work+0x10/0x10 ? El siguiente parche de ping.py agrega el caso xdp-mb-pass, por lo que ping.py podrá reproducir este problema.
Vulnerabilidad en kernel de Linux (CVE-2025-21965)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched_ext: Validar prev_cpu en scx_bpf_select_cpu_dfl(). Si un programador BPF proporciona una CPU no válida (fuera del rango nr_cpu_ids) como prev_cpu a scx_bpf_select_cpu_dfl(), puede provocar un fallo del kernel. Para evitarlo, valide prev_cpu en scx_bpf_select_cpu_dfl() y genere un error scx si se especifica una CPU no válida.
Vulnerabilidad en kernel de Linux (CVE-2025-21970)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Puente, corrige el fallo causado por la comprobación del estado de LAG Al retirar el dispositivo LAG del puente, se activa el evento NETDEV_CHANGEUPPER. El controlador encuentra los dispositivos inferiores (PF) para vaciar todas las entradas descargadas. Y mlx5_lag_is_shared_fdb está marcado, devuelve falso si uno de los PF está descargado. En tal caso, mlx5_esw_bridge_lag_rep_get() y su llamador devuelven NULL, en lugar del PF vivo, y se omite el vaciado. Además, el lastuse de la entrada fdb del puente se actualiza en el controlador de eventos del puente mlx5. Pero este evento SWITCHDEV_FDB_ADD_TO_BRIDGE se puede ignorar en este caso porque se elimina la interfaz superior para el enlace y la entrada nunca se envejecerá porque lastuse nunca se actualiza. Para empeorar las cosas, mientras la entrada esté activa, la cola de trabajo del puente mlx5 sigue enviando ese evento, que luego gestiona el notificador del puente del núcleo. Esto provoca el siguiente fallo al acceder al enlace transferido netdev, que ya está destruido. Para solucionar este problema, elimine estas comprobaciones. El estado de LAG ya se comprobó en el commit 15f8f168952f ("net/mlx5: Puente, verificar el estado de LAG al agregar el enlace al puente"). El controlador aún debe omitir la descarga si el estado de LAG se vuelve inválido después de la inicialización. Ups: segmento de pila: 0000 [#1] CPU SMP: 3 UID: 0 PID: 23695 Comm: kworker/u40:3 Contaminado: G OE 6.11.0_mlnx #1 Contaminado: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_bridge_wq mlx5_esw_bridge_update_work [mlx5_core] RIP: 0010:br_switchdev_event+0x2c/0x110 [bridge] Code: 44 00 00 48 8b 02 48 f7 00 00 02 00 00 74 69 41 54 55 53 48 83 ec 08 48 8b a8 08 01 00 00 48 85 ed 74 4a 48 83 fe 02 48 89 d3 <4c> 8b 65 00 74 23 76 49 48 83 fe 05 74 7e 48 83 fe 06 75 2f 0f b7 RSP: 0018:ffffc900092cfda0 EFLAGS: 00010297 RAX: ffff888123bfe000 RBX: ffffc900092cfe08 RCX: 00000000ffffffff RDX: ffffc900092cfe08 RSI: 0000000000000001 RDI: ffffffffa0c585f0 RBP: 6669746f6e690a30 R08: 0000000000000000 R09: ffff888123ae92c8 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888123ae9c60 R13: 0000000000000001 R14: ffffc900092cfe08 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f15914c8734 CR3: 0000000002830005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __die_body+0x1a/0x60 ? die+0x38/0x60 ? do_trap+0x10b/0x120 ? do_error_trap+0x64/0xa0 ? exc_stack_segment+0x33/0x50 ? asm_exc_stack_segment+0x22/0x30 ? br_switchdev_event+0x2c/0x110 [bridge] ? sched_balance_newidle.isra.149+0x248/0x390 notifier_call_chain+0x4b/0xa0 atomic_notifier_call_chain+0x16/0x20 mlx5_esw_bridge_update+0xec/0x170 [mlx5_core] mlx5_esw_bridge_update_work+0x19/0x40 [mlx5_core] process_scheduled_works+0x81/0x390 worker_thread+0x106/0x250 ? bh_worker+0x110/0x110 kthread+0xb7/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20
Vulnerabilidad en kernel de Linux (CVE-2025-21971)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: Impide la creación de clases con TC_H_ROOT La función qdisc_tree_reduce_backlog() usa TC_H_ROOT como condición de terminación al recorrer el árbol qdisc para actualizar los contadores de backlog primarios. Sin embargo, si se crea una clase con classid TC_H_ROOT, el recorrido termina prematuramente en esta clase en lugar de alcanzar la qdisc root real, lo que provoca que las estadísticas primarias se mantengan incorrectamente. En caso de DRR, esto podría provocar un fallo como lo informó Mingi Cho. Impide la creación de cualquier clase Qdisc con classid TC_H_ROOT (0xFFFFFFFF) en todos los tipos de qdisc, como sugirió Jamal.
Vulnerabilidad en kernel de Linux (CVE-2025-21972)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mctp: paquetes no compartidos al reensamblar. Asegúrese de que la lista de fragmentos utilizada para el reensamblado no se comparta con otros paquetes. Esto evita un reensamblado incorrecto al clonar paquetes y previene una fuga de memoria debido a referencias circulares entre fragmentos y su skb_shared_info. El próximo controlador MCTP sobre USB utiliza skb_clone, lo que puede desencadenar el problema; otros controladores MCTP no comparten los SKB. Se ha añadido una prueba kunit para reproducir el problema.
Vulnerabilidad en kernel de Linux (CVE-2025-21974)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: bnxt: return fail if interface is down in bnxt_queue_mem_alloc(). Se llama a bnxt_queue_mem_alloc() para asignar nueva memoria de cola cuando esta se reinicia. Accede internamente al descriptor de búfer rx correspondiente al índice. El descriptor de búfer rx se asigna y se establece cuando la interfaz está activa y se libera cuando esta se cae. Por lo tanto, si la cola se reinicia mientras la interfaz está caída, se produce un pánico del kernel. El problema se ve así: ERROR: no se puede gestionar el error de página para la dirección: 000000000000b240 #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 CPU: 3 UID: 0 PID: 1563 Comm: ncdevmem2 No contaminado 6.14.0-rc2+ #9 844ddba6e7c459cafd0bf4db9a3198e Nombre del hardware: Nombre del producto del sistema ASUS/PRIME Z690-P D4, BIOS 0603 11/01/2021 RIP: 0010:bnxt_queue_mem_alloc+0x3f/0x4e0 [bnxt_en] Code: 41 54 4d 89 c4 4d 69 c0 c0 05 00 00 55 48 89 f5 53 48 89 fb 4c 8d b5 40 05 00 00 48 83 ec 15 RSP: 0018:ffff9dcc83fef9e8 EFLAGS: 00010202 RAX: ffffffffc0457720 RBX: ffff934ed8d40000 RCX: 0000000000000000 RDX: 000000000000001f RSI: ffff934ea508f800 RDI: ffff934ea508f808 RBP: ffff934ea508f800 R08: 000000000000b240 R09: ffff934e84f4b000 R10: ffff9dcc83fefa30 R11: ffff934e84f4b000 R12: 000000000000001f R13: ffff934ed8d40ac0 R14: ffff934ea508fd40 R15: ffff934e84f4b000 FS: 00007fa73888c740(0000) GS:ffff93559f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000b240 CR3: 0000000145a2e000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x15a/0x460 ? exc_page_fault+0x6e/0x180 ? asm_exc_page_fault+0x22/0x30 ? __pfx_bnxt_queue_mem_alloc+0x10/0x10 [bnxt_en 7f85e76f4d724ba07471d7e39d9e773aea6597b7] ? bnxt_queue_mem_alloc+0x3f/0x4e0 [bnxt_en 7f85e76f4d724ba07471d7e39d9e773aea6597b7] netdev_rx_queue_restart+0xc5/0x240 net_devmem_bind_dmabuf_to_queue+0xf8/0x200 netdev_nl_bind_rx_doit+0x3a7/0x450 genl_family_rcv_msg_doit+0xd9/0x130 genl_rcv_msg+0x184/0x2b0 ? __pfx_netdev_nl_bind_rx_doit+0x10/0x10 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 ...
Vulnerabilidad en kernel de Linux (CVE-2025-22034)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/gup: rechazo de FOLL_SPLIT_PMD con VMAs hugetlb. Serie de parches "mm: correcciones para entradas exclusivas de dispositivo (hmm)", v2. Al hablar con Willy sobre la llamada a PageTail() en make_device_exclusive_range(), descubrí recientemente [1] que la gestión exclusiva de dispositivo no funciona correctamente con THP, lo que provoca que las autopruebas hmm-tests fallen si las THP están habilitadas en el sistema. Al analizar más a fondo, descubrí que hugetlb no está correctamente protegido y me di cuenta de que algo que me había estado molestando durante mucho tiempo (la interacción de las entradas exclusivas de dispositivo con mapcounts) interrumpe por completo la gestión de migración/intercambio/división/hwpoison de estos folios mientras tienen PTE exclusivas de dispositivo. El programa a continuación se puede usar para asignar 1 GiB de páginas y convertirlas en exclusivas de dispositivo en un kernel con CONFIG_TEST_HMM. Una vez que son exclusivos del dispositivo, estos folios no se pueden intercambiar (proc$pid/smaps_rollup siempre indicará 1 GiB RSS sin importar cuánto se fuerce la recuperación de memoria) y cuando se tiene un bloque de memoria en línea en ZONE_MOVABLE, al intentar desconectarlo se repetirá eternamente y se quejará sobre la migración fallida de una página que debería ser movible. # echo offline > /sys/devices/system/memory/memory136/state # echo online_movable > /sys/devices/system/memory/memory136/state # ./hmm-swap & ... wait until everything is device-exclusive # echo offline > /sys/devices/system/memory/memory136/state [ 285.193431][T14882] page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x7f20671f7 pfn:0x442b6a [ 285.196618][T14882] memcg:ffff888179298000 [ 285.198085][T14882] anon flags: 0x5fff0000002091c(referenced|uptodate| dirty|active|owner_2|swapbacked|node=1|zone=3|lastcpupid=0x7ff) [ 285.201734][T14882] raw: ... [ 285.204464][T14882] raw: ... [ 285.207196][T14882] page dumped because: migration failure [ 285.209072][T14882] page_owner tracks the page as allocated [ 285.210915][T14882] page last allocated via order 0, migratetype Movable, gfp_mask 0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), id 14926, tgid 14926 (hmm-swap), ts 254506295376, free_ts 227402023774 [ 285.216765][T14882] post_alloc_hook+0x197/0x1b0 [ 285.218874][T14882] get_page_from_freelist+0x76e/0x3280 [ 285.220864][T14882] __alloc_frozen_pages_noprof+0x38e/0x2740 [ 285.223302][T14882] alloc_pages_mpol+0x1fc/0x540 [ 285.225130][T14882] folio_alloc_mpol_noprof+0x36/0x340 [ 285.227222][T14882] vma_alloc_folio_noprof+0xee/0x1a0 [ 285.229074][T14882] __handle_mm_fault+0x2b38/0x56a0 [ 285.230822][T14882] handle_mm_fault+0x368/0x9f0 ... Esta serie corrige todos los problemas que he encontrado hasta ahora. No hay una solución sencilla sin una revisión o limpieza más profunda. Tengo varias correcciones adicionales (algunas enviadas previamente, otras resultantes de la discusión en la v1) que publicaré por separado una vez que esté disponible y pueda con ello. Ojalá pudiéramos usar algunas PTE PROT_NONE presentes especiales en lugar de estas entradas de intercambio falso (no presentes, no ninguna); pero eso solo resulta en el mismo problema que seguimos teniendo (falta de bits de PTE de repuesto), y al observar otras entradas de intercambio falso similares, ese barco ya pasó. Con esta serie, make_device_exclusive() ya no pertenece a mm/rmap.c, pero lo dejaré para otro día. Solo probé esta serie con las autopruebas hmm-tests debido a la falta de hardware, así que agradecería algunas pruebas, especialmente si la interacción entre dos GPU que buscan una entrada de dispositivo exclusivo funciona como se espera. #include #include #include #include #include #include #include #include #include #include #define HMM_DMIRROR_EXCLUSIVE _IOWR('H', 0x05, ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2025-22044)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: acpi: nfit: corrección de la conversión de restricción en acpi_nfit_ctl. Syzkaller ha informado de una advertencia en to_nfit_bus_uuid(): "Solo se pueden traducir familias de bus secundarias". Esta advertencia se emite si el argumento es igual a NVDIMM_BUS_FAMILY_NFIT == 0. La función acpi_nfit_ctl() verifica primero que el valor proporcionado por el usuario, call_pkg->nd_family, de tipo u64, no sea igual a 0. A continuación, el valor se convierte a int y solo después se compara con NVDIMM_BUS_FAMILY_MAX. Esto puede provocar que se pase un argumento no válido a acpi_nfit_ctl() si call_pkg->nd_family es distinto de cero, mientras que los 32 bits inferiores son cero. Además, se recomienda devolver EINVAL inmediatamente después de detectar la entrada de usuario no válida. La advertencia no es suficiente para evitar un comportamiento indefinido posterior basado en otra entrada de usuario no válida. Todas las comprobaciones del valor de entrada deben aplicarse a la variable original call_pkg->nd_family. [iweiny: actualizar mensaje de confirmación]
Vulnerabilidad en kernel de Linux (CVE-2025-22045)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mm: Arregla flush_tlb_range() cuando se usa para zapping de PMD normales En la siguiente ruta, flush_tlb_range() se puede usar para zapping de entradas PMD normales (entradas PMD que apuntan a tablas de páginas) junto con las entradas PTE en la tabla de páginas apuntada: colapso_pte_mapped_thp pmdp_collapse_flush flush_tlb_range La versión arm64 de flush_tlb_range() tiene un comentario que describe que se puede usar para la eliminación de la tabla de páginas y no usa ninguna optimización de invalidación de último nivel. Arregla la versión X86 haciendo que se comporte de la misma manera. Actualmente, X86 solo usa esta información para los dos propósitos siguientes, lo que creo que significa que el problema no tiene mucho impacto: - En native_flush_tlb_multi() para verificar si las CPU TLB perezosas necesitan ser IPI'd para evitar problemas con recorridos especulativos de la tabla de páginas. En la paravirtualización de TLB de Hyper-V, de nuevo para problemas de TLB lentos. El parche "x86/mm: solo invalidar las traducciones finales con INVLPGB", actualmente en revisión (véase ), probablemente estaría agravando considerablemente el impacto de esto.
Vulnerabilidad en kernel de Linux (CVE-2025-22046)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: uprobes/x86: endurecer la llamada al sistema uretprobe trampoline check Jann informó un posible problema cuando trampoline_check_ip devuelve una dirección cerca del final del espacio de direcciones que puede llamar a la llamada al sistema si no se configuran uretprobes: https://lore.kernel.org/bpf/202502081235.5A6F352985@keescook/T/#m9d416df341b8fbc11737dacbcd29f0054413cbbf Aunque las restricciones de dirección mínima de mmap normalmente evitarán la creación de asignaciones allí, asegurémonos de que la llamada al sistema uretprobe lo verifique.
Vulnerabilidad en kernel de Linux (CVE-2025-22047)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/microcode/AMD: Se corrige el valor de retorno de __apply_microcode_amd() Cuando verify_sha256_digest() falla, __apply_microcode_amd() debe propagar la falla devolviendo falso (y no -1 que se promueve a verdadero).
Vulnerabilidad en kernel de Linux (CVE-2025-22048)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: BPF: No anule el valor de retorno del subprograma La prueba del verificador `calls: div by 0 in subprog` desencadena un pánico en la instrucción ld.bu. La instrucción ld.bu insn intenta cargar un byte desde la dirección de memoria devuelta por el subprograma. El subprograma en realidad estableció la dirección correcta en el registro a5 (registro dedicado para valores de retorno de BPF). Pero en el commit 73c359d1d356 ("LoongArch: BPF: Valores de retorno con signo extendido") también firmamos a5 extendido en el registro a0 (valor de retorno en LoongArch). Para la instrucción de llamada a función insn, luego propagamos el registro a0 de vuelta al registro a5. Esto es correcto para llamadas nativas, pero incorrecto para llamadas bpf2bpf que esperan un valor de retorno extendido cero en el registro a5. Por lo tanto, solo mueva a0 a a5 para llamadas nativas (es decir, no BPF_PSEUDO_CALL).
Vulnerabilidad en kernel de Linux (CVE-2025-22049)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Aumentar ARCH_DMA_MINALIGN hasta 16. ARCH_DMA_MINALIGN es 1 por defecto, pero algunos dispositivos específicos de LoongArch (como APBDMA) requieren una alineación de 16 bytes. Cuando la longitud del búfer de datos es demasiado pequeña, el hardware puede cometer un error al escribir la línea de caché. Por lo tanto, es peligroso asignar un búfer de memoria pequeño para DMA. Siempre es seguro definir ARCH_DMA_MINALIGN como L1_CACHE_BYTES, pero no es necesario (kmalloc() requiere objetos de memoria pequeños). Por lo tanto, simplemente auméntelo a 16.
Vulnerabilidad en kernel de Linux (CVE-2025-22050)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usbnet:fix NPE durante rx_complete. Falta la comprobación usbnet_going_away en la ruta crítica. La función usb_submit_urb carece de la validación usbnet_going_away, mientras que __usbnet_queue_skb sí la incluye. Esta inconsistencia crea una condición de ejecución donde: una solicitud URB puede ser exitosa, pero los datos SKB correspondientes no se ponen en cola. Los procesos posteriores (p. ej., rx_complete ? defer_bh ? __skb_unlink(skb, list)) intentan acceder a skb->next, lo que provoca una desreferencia de puntero nulo (pánico del kernel).
Vulnerabilidad en kernel de Linux (CVE-2025-22053)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ibmveth: hacer que veth_pool_store deje de bloquearse v2: - Se creó un único error al gestionar el desbloqueo y la salida en veth_pool_store - Mensaje de confirmación muy ampliado con texto previo solo explicativo Resumen: Use rtnl_mutex para sincronizar veth_pool_store consigo mismo, ibmveth_close e ibmveth_open, lo que impide varias llamadas seguidas a napi_disable. Antecedentes: Dos (o más) subprocesos podrían llamar a veth_pool_store escribiendo en /sys/devices/vio/30000002/pool*/*. Puede hacerlo fácilmente con un pequeño script de shell. Esto provoca un bloqueo. Configuré LOCKDEP, compilé ibmveth.c con DEBUG y compilé un nuevo kernel. Ejecuté esta prueba nuevamente y vi: Configurando pool0/active a 0 Configurando pool1/active a 1 [ 73.911067][ T4365] ibmveth 30000002 eth0: cerrar iniciando Configurando pool1/active a 1 Configurando pool1/active a 0 [ 73.911367][ T4366] ibmveth 30000002 eth0: cerrar iniciando [ 73.916056][ T4365] ibmveth 30000002 eth0: cerrar completo [ 73.916064][ T4365] ibmveth 30000002 eth0: abrir iniciando [ 110.808564][ T712] systemd-journald[712]: Se envió la notificación WATCHDOG=1. [ 230.808495][ T712] systemd-journald[712]: Se envió la notificación WATCHDOG=1. [ 243.683786][ T123] INFO: la tarea stress.sh:4365 estuvo bloqueada durante más de 122 segundos. [ 243.683827][ T123] No contaminado 6.14.0-01103-g2df0c02dab82-dirty #8 [ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" deshabilita este mensaje. [ 243.683838][ T123] tarea:stress.sh estado:D pila:28096 pid:4365 tgid:4365 ppid:4364 indicadores_de_tarea:0x400040 indicadores:0x00042000 [ 243.683852][ T123] Rastreo de llamadas: [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (no confiable) [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0 [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0 [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210 [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50 [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0 [243.683913][T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60 [243.683921][T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc [243.683928][T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270 [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0 [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0 [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650 [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150 [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340 [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec ... [ 243.684087][ T123] Mostrando todos los bloqueos mantenidos en el sistema: [ 243.684095][ T123] 1 bloqueo mantenido por khungtaskd/123: [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, en: debug_show_all_locks+0x50/0x248 [ 243.684114][ T123] 4 bloqueos mantenidos por stress.sh/4365: [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, en: ksys_write+0x88/0x150 [ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, en: kernfs_fop_write_iter+0x154/0x2d0 [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, en: kernfs_fop_write_iter+0x160/0x2d0 [ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, en: napi_enable+0x30/0x60 [ 243.684166][ T123] 5 bloqueos mantenidos por stress.sh/4366: [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, en: ksys_write+0x88/0x150 [ 243. ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2025-22055)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: fix geneve_opt length entire entire struct geneve_opt usa una longitud de 5 bits para cada opción, lo que significa que cada opción de tamaño variable debe ser menor a 128 bytes. Sin embargo, ninguna de las políticas Netlink actuales relacionadas puede garantizar esta condición de longitud, y el atacante puede explotar una opción de tamaño exacto de 128 bytes para simular una opción de longitud cero y confundir la lógica de análisis, lo que a su vez provoca una lectura fuera de los límites del montón. Un ejemplo de registro de fallos es el siguiente: [3.905425] ======================================================================= [3.905925] ERROR: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0 [ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177 [ 3.906646] [ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1 [ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 3.907784] Call Trace: [ 3.907925] [ 3.908048] dump_stack_lvl+0x44/0x5c [ 3.908258] print_report+0x184/0x4be [ 3.909151] kasan_report+0xc5/0x100 [ 3.909539] kasan_check_range+0xf3/0x1a0 [ 3.909794] memcpy+0x1f/0x60 [ 3.909968] nla_put+0xa9/0xe0 [ 3.910147] tunnel_key_dump+0x945/0xba0 [ 3.911536] tcf_action_dump_1+0x1c1/0x340 [ 3.912436] tcf_action_dump+0x101/0x180 [ 3.912689] tcf_exts_dump+0x164/0x1e0 [ 3.912905] fw_dump+0x18b/0x2d0 [ 3.913483] tcf_fill_node+0x2ee/0x460 [ 3.914778] tfilter_notify+0xf4/0x180 [ 3.915208] tc_new_tfilter+0xd51/0x10d0 [ 3.918615] rtnetlink_rcv_msg+0x4a2/0x560 [ 3.919118] netlink_rcv_skb+0xcd/0x200 [ 3.919787] netlink_unicast+0x395/0x530 [ 3.921032] netlink_sendmsg+0x3d0/0x6d0 [ 3.921987] __sock_sendmsg+0x99/0xa0 [ 3.922220] __sys_sendto+0x1b7/0x240 [ 3.922682] __x64_sys_sendto+0x72/0x90 [ 3.922906] do_syscall_64+0x5e/0x90 [ 3.923814] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 3.924122] RIP: 0033:0x7e83eab84407 [ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407 [ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003 [ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c [ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0 [ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8 Solucione estos problemas aplicando la condición de longitud correcta en las políticas relacionadas.
Vulnerabilidad en kernel de Linux (CVE-2025-22057)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: disminuir los contadores dst en caché en dst_release La corrección ascendente ac888d58869b ("net: no retrasar dst_entries_add() en dst_release()") se movió y disminuyó el recuento dst de dst_destroy a dst_release para evitar acceder a datos ya liberados en caso de desmantelamiento de netns. Sin embargo, en caso de que CONFIG_DST_CACHE esté habilitado y se usen túneles OvS+, esta corrección está incompleta ya que se verá el mismo problema para los dst en caché: No se puede manejar la solicitud de paginación del núcleo en la dirección virtual ffff5aabf6b5c000 Rastreo de llamadas: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30 Corrija esto invalidando el caché y, por lo tanto, disminuyendo los contadores dst en caché. dst_release también.
Vulnerabilidad en kernel de Linux (CVE-2025-22058)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: Se corrige la fuga de contabilidad de memoria. Matt Dowling informó de un extraño problema de uso de memoria UDP. En condiciones normales de funcionamiento, el uso de memoria UDP informado en /proc/net/sockstat se mantiene cercano a cero. Sin embargo, ocasionalmente alcanzaba 524 288 páginas y nunca se reducía. Además, el valor se duplicaba al finalizar la aplicación. Finalmente, causaba pérdidas intermitentes de paquetes. Podemos reproducir el problema con el siguiente script [0]: 1. /proc/net/sockstat informa 0 páginas # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. Ejecute el script hasta que el informe alcance 524 288 # python3 test.py & sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT 3. Matar el socket y confirmar que el número nunca baje # pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288 4. (necesario desde v6.0) Desencadenar proto_memory_pcpu_drain() # python3 test.py & sleep 1 && pkill python3 5. El número se duplica # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 1048577 La aplicación estableció INT_MAX en SO_RCVBUF, lo que desencadenó un desbordamiento de entero en udp_rmem_release(). Cuando se cierra un socket, udp_destruct_common() purga su cola de recepción y suma skb->truesize en ella. Este total se calcula y se almacena en una variable local de entero sin signo. El tamaño total se pasa a udp_rmem_release() para ajustar la memoria. Sin embargo, dado que la función acepta un argumento de entero con signo, el tamaño total puede volver a la normalidad, provocando un desbordamiento. La cantidad liberada se calcula de la siguiente manera: 1) Sumar size a sk->sk_forward_alloc. 2) Redondear sk->sk_forward_alloc al múltiplo inferior más cercano de PAGE_SIZE y asignarlo a amount. 3) Restar amount de sk->sk_forward_alloc. 4) Pasar amount >> PAGE_SHIFT a __sk_mem_reduce_allocated(). Cuando se produjo el problema, el total en udp_destruct_common() era 2147484480 (INT_MAX + 833), que se convirtió a -2147482816 en udp_rmem_release(). En 1) sk->sk_forward_alloc se cambia de 3264 a -2147479552, y 2) se establece -2147479552 en cantidad. 3) revierte el ajuste, por lo que no vemos ninguna advertencia en inet_sock_destruct(). Sin embargo, udp_memory_allocated se duplica en 4). Desde el commit 3cd3399dd7a8 ("net: implementar reservas por CPU para memory_allocated"), el uso de memoria ya no se duplica inmediatamente después de cerrar un socket, ya que __sk_mem_reduce_allocated() almacena en caché la cantidad en udp_memory_per_cpu_fw_alloc. Sin embargo, la siguiente vez que un socket UDP recibe un paquete, la resta se aplica, duplicando el uso de memoria UDP. Este problema provoca que la asignación de memoria posterior falle una vez que el valor de sk->sk_rmem_alloc del socket supere net.ipv4.udp_rmem_min, lo que provoca la pérdida de paquetes. Para evitar este problema, usemos unsigned int para el cálculo y llamemos a sk_forward_alloc_add() solo una vez para la delta pequeña. Tenga en cuenta que first_packet_length() también podría tener el mismo problema. [0]: desde la importación de socket * SO_RCVBUFFORCE = 33 INT_MAX = (2 ** 31) - 1 s = socket(AF_INET, SOCK_DGRAM) s.bind(('', 0)) s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX) c = socket(AF_INET, SOCK_DGRAM) c.connect(s.getsockname()) datos = b'a' * 100 mientras sea verdadero: c.send(datos)
Vulnerabilidad en kernel de Linux (CVE-2025-22060)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mvpp2: Prevenir la corrupción de memoria TCAM del analizador Proteja la memoria TCAM/SRAM del analizador y la información SRAM en caché (shadow) de modificaciones simultáneas. Se accede indirectamente a las tablas TCAM y SRAM configurando un registro de índice que selecciona la fila en la que leer o escribir. Esto significa que las operaciones deben ser atómicas para, por ejemplo, evitar propagar escrituras en varias filas. Dado que la matriz shadow SRAM se utiliza para encontrar filas libres en la tabla de hardware, también debe protegerse para evitar errores TOCTOU en los que varios núcleos asignan la misma fila. Este problema se detectó en una situación en la que `mvpp2_set_rx_mode()` se ejecutaba simultáneamente en dos CPU. En este caso particular, la entrada MVPP2_PE_MAC_UC_PROMISCUOUS estaba dañada, lo que provocaba que la unidad clasificadora descartara toda la unidifusión entrante, lo que se indica mediante el contador `rx_classifier_drops`.
Vulnerabilidad en kernel de Linux (CVE-2025-22061)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: airoha: Se corrige el informe qid en airoha_tc_get_htb_get_leaf_queue() Se corrige la siguiente advertencia del kernel que elimina las hojas descargadas de HTB y/o el qdisc de HTB raíz en el controlador airoha_eth que informa correctamente el qid en la rutina airoha_tc_get_htb_get_leaf_queue. $tc qdisc replace dev eth1 root handle 10: htb offload $tc class add dev eth1 arent 10: classid 10:4 htb rate 100mbit ceil 100mbit $tc qdisc replace dev eth1 parent 10:4 handle 4: ets bands 8 \ quanta 1514 3028 4542 6056 7570 9084 10598 12112 $tc qdisc del dev eth1 root [ 55.827864] ------------[ cortar aquí ]------------ [ 55.832493] ADVERTENCIA: CPU: 3 PID: 2678 en 0xffffffc0798695a4 [ 55.956510] CPU: 3 PID: 2678 Comm: tc Tainted: GO 6.6.71 #0 [ 55.963557] Nombre del hardware: Placa de evaluación Airoha AN7581 (DT) [ 55.969383] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.976344] pc : 0xffffffc0798695a4 [ 55.979851] lr : 0xffffffc079869a20 [ 55.983358] sp : ffffffc0850536a0 [ 55.986665] x29: ffffffc0850536a0 x28: 0000000000000024 x27: 0000000000000001 [ 55.993800] x26: 0000000000000000 x25: ffffff8008b19000 x24: ffffff800222e800 [ 56.000935] x23: 000000000000001 x22: 0000000000000000 x21: ffffff8008b19000 [ 56.008071] x20: ffffff8002225800 x19: ffffff800379d000 x18: 000000000000000 [ 56.015206] x17: ffffffbf9ea59000 x16: ffffffc080018000 x15: 0000000000000000 [ 56.022342] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000001 [ 56.029478] x11: fffffc081471008 x10: fffffc081575a98 x9: 0000000000000000 [ 56.036614] x8: fffffc08167fd40 x7: fffffc08069e104 x6 : ffffff8007f86000 [ 56.043748] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000001 [ 56.050884] x2 : 0000000000000000 x1 : 0000000000000250 x0 : ffffff800222c000 [ 56.058020] Rastreo de llamadas: [ 56.060459] 0xffffffc0798695a4 [ 56.063618] 0xffffffc079869a20 [ 56.066777] __qdisc_destroy+0x40/0xa0 [ 56.070528] qdisc_put+0x54/0x6c [ 56.073748] qdisc_graft+0x41c/0x648 [ 56.077324] tc_get_qdisc+0x168/0x2f8 [ 56.080978] rtnetlink_rcv_msg+0x230/0x330 [ 56.085076] netlink_rcv_skb+0x5c/0x128 [ 56.088913] rtnetlink_rcv+0x14/0x1c [ 56.092490] netlink_unicast+0x1e0/0x2c8 [ 56.096413] netlink_sendmsg+0x198/0x3c8 [ 56.100337] ____sys_sendmsg+0x1c4/0x274 [ 56.104261] ___sys_sendmsg+0x7c/0xc0 [ 56.107924] __sys_sendmsg+0x44/0x98 [ 56.111492] __arm64_sys_sendmsg+0x20/0x28 [ 56.115580] invocar_syscall.constprop.0+0x58/0xfc [ 56.120285] do_el0_svc+0x3c/0xbc [ 56.123592] el0_svc+0x18/0x4c [ 56.126647] el0t_64_sync_handler+0x118/0x124 [ 56.131005] el0t_64_sync+0x150/0x154 [ 56.134660] ---[ fin de seguimiento 0000000000000000 ]---
Vulnerabilidad en kernel de Linux (CVE-2025-22064)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: no anular el registro del gancho cuando la tabla está inactiva. Cuando nf_tables_updchain detecta un error, es necesario revertir el registro del gancho. Esto solo debe hacerse si el gancho ya está registrado, lo cual no ocurrirá si la tabla está inactiva. Simplemente mueva la asignación al bloque de registro.
Vulnerabilidad en kernel de Linux (CVE-2025-22071)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spufs: corrige una fuga en spufs_create_context() Las correcciones de fugas en 2008 pasaron por alto un caso: si estamos tratando de establecer la afinidad y spufs_mkdir() falla, debemos eliminar la referencia al vecino.
Vulnerabilidad en kernel de Linux (CVE-2025-22072)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spufs: corrige la duración del directorio de pandillas. Antes de "[POWERPC] spufs: corrige las fugas de destrucción de pandillas", teníamos un problema con la duración de las pandillas: al crear una pandilla, se devolvía el directorio de pandillas abierto, que normalmente se elimina al cerrarse. Sin embargo, si alguien creaba un contexto perteneciente a esa pandilla y lo mantenía activo hasta que se cerraba, la eliminación fallaba y se producía una fuga. Desafortunadamente, se solucionó incorrectamente. La dentry del directorio de pandillas ya no estaba fijada y rmdir al cerrar se había eliminado. Un problema era que, al fallar la apertura, se seguía llamando a simple_rmdir() como limpieza, lo que implicaba un dput() desequilibrado. Otro error, en el caso de éxito, era que la creación de una pandilla incrementaba el número de enlaces en el directorio raíz, pero esto ya no se deshacía al destruirla. La solución consiste en: * revertir el commit en cuestión * añadir un contador a la pandilla, protegido por ->i_rwsem del inodo del directorio de pandillas. * tenerlo establecido en 1 en el momento de la creación, descartado tanto en spufs_dir_close() como en spufs_gang_close() y agregado en spufs_create_context(), siempre que no sea 0. * usar simple_recursive_removal() para sacar el directorio de pandillas cuando el contador llega a cero.
Vulnerabilidad en kernel de Linux (CVE-2025-22073)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spufs: se corrige una fuga en caso de fallo de spufs_new_file(). Se llama desde spufs_fill_dir(), y quien lo llama ejecutará spufs_rmdir() en caso de fallo. Esto elimina todo lo que habíamos creado, pero el problema de dentry sigue siendo negativo. Es decir, debe eliminarse explícitamente.
Vulnerabilidad en kernel de Linux (CVE-2025-22075)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtnetlink: Asignar tamaño de vfinfo para GUID de VF cuando sea compatible. el commit 30aad41721e0 ("net/core: Agregar soporte para obtener GUID de VF") agregó soporte para obtener GUID de puerto y nodo de VF en mensajes ifinfo de netlink, pero su tamaño no se tuvo en cuenta en la función que asigna el mensaje de netlink, lo que causa la siguiente advertencia cuando un mensaje de netlink se llena con muchos GUID de puerto y nodo de VF: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK responde: Mensaje demasiado largo. No se puede enviar solicitud de obtención de enlace: Mensaje demasiado largo. Advertencia del kernel: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfx___mutex_lock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx___netlink_lookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? __pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ____sys_sendmsg+0x559/0x5a0 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 ___sys_sendmsg+0xe4/0x150 ? __pfx____sys_sendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? __pfx_handle_pte_fault+0x10/0x10 ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2025-22076)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: se corrige la falta de comprobación de apagado. La prueba genérica/730 de xfstests falló porque, tras eliminar el dispositivo que aún contenía datos corruptos, el archivo aún se podía leer sin devolver un error. El motivo es la falta de comprobación de apagado en ->read_iter. También observé que faltaban comprobaciones de apagado en ->write_iter, ->splice_read y ->mmap. Esta confirmación añade comprobaciones de apagado a todas ellas.
Vulnerabilidad en kernel de Linux (CVE-2025-22077)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: Corregir el desequilibrio en el recuento de referencias de netns que causa fugas y use-after-free. el commit ef7134c7fc48 ("smb: cliente: Corregir el use-after-free del espacio de nombres de red") intentó corregir un problema de use-after-free de netns ajustando manualmente los recuentos de referencias mediante sk->sk_net_refcnt y sock_inuse_add(). Sin embargo, una confirmación posterior e9f2517a3e18 ("smb: cliente: Corregir el bloqueo de los temporizadores TCP después de rmmod") indicó que la configuración manual de sk->sk_net_refcnt en la primera confirmación era técnicamente incorrecta, ya que sk->sk_net_refcnt solo debe configurarse para sockets de usuario. Esto provocó problemas como que los temporizadores TCP no se borraran correctamente al cerrar. La segunda confirmación se adaptó a un modelo que simplemente almacena una referencia netns adicional para server->ssocket mediante get_net() y la elimina al desmantelar el servidor. Sin embargo, persisten algunas deficiencias en el equilibrio entre get_net() y put_net(), añadidas por estas confirmaciones. El manejo incompleto de las referencias en estas correcciones genera dos problemas: 1. Fugas de recuento de referencias de netns[1]. El proceso del problema es el siguiente: ``` mount.cifs cifsd cifs_do_mount cifs_mount cifs_mount_get_session cifs_get_tcp_session get_net() /* Primero, obtener net. */ ip_connect generic_ip_connect /* Intentar el puerto 445 */ get_net() ->connect() /* Error */ put_net() generic_ip_connect /* Intentar el puerto 139 */ get_net() /* Falta put_net() coincidente para este get_net().*/ cifs_get_smb_ses cifs_negotiate_protocol smb2_negotiate SMB2_negotiate cifs_send_recv wait_for_response cifs_demultiplex_thread cifs_read_from_socket cifs_readv_from_socket cifs_reconnect cifs_abort_connection sock_release(); server->ssocket = NULL; /* Falta put_net() aquí. */ generic_ip_connect get_net() ->connect() /* Error */ put_net() sock_release(); server->ssocket = NULL; free_rsp_buf ... clean_demultiplex_info /* Solo se llama una vez aquí. */ put_net() ``` Cuando se activa cifs_reconnect(), el servidor->ssocket se libera sin un put_net() correspondiente para la referencia obtenida previamente en generic_ip_connect(). Termina llamando a generic_ip_connect() de nuevo para reintentar get_net(). Después, el servidor->ssocket se establece en NULL en la ruta de error de generic_ip_connect(), y el recuento neto no se puede liberar en la función clean_demultiplex_info() final. 2. Posible use-after-free. El esquema actual de recuento de referencias puede generar un posible problema de use-after-free en el siguiente escenario: ``` cifs_do_mount cifs_mount cifs_mount_get_session cifs_get_tcp_session get_net() /* First get net */ ip_connect generic_ip_connect get_net() bind_socket kernel_bind /* failed */ put_net() /* after out_err_crypto_release label */ put_net() /* after out_err label */ put_net() ``` En el proceso de gestión de excepciones donde falla la vinculación del socket, las llamadas get_net() y put_net() están desequilibradas, lo que puede provocar que el recuento de referencias server->net baje a cero y se libere prematuramente. Para solucionar ambos problemas, este parche vincula el recuento de referencias netns ---truncated---
Vulnerabilidad en kernel de Linux (CVE-2025-22078)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: vchiq_arm: Se corrige un posible NPR del subproceso keep-alive. Si vchiq_platform_conn_state_changed() no se llama nunca o falla antes de la eliminación del controlador, ka_thread no será un puntero válido a una task_struct. Por lo tanto, realice las comprobaciones necesarias antes de llamar a kthread_stop para evitar un bloqueo.
Vulnerabilidad en kernel de Linux (CVE-2025-22079)
Severidad: ALTA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: Validar l_tree_depth para evitar accesos fuera de los límites. El campo l_tree_depth es de 16 bits (__le16), pero la profundidad máxima real está limitada a OCFS2_MAX_PATH_DEPTH. Se ha añadido una comprobación para evitar accesos fuera de los límites si l_tree_depth tiene un valor no válido, lo que puede ocurrir al leer desde un disco montado dañado [1].
Vulnerabilidad en kernel de Linux (CVE-2025-22082)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: backend: asegúrese de terminar el búfer de pila con valor NULL. Asegúrese de terminar el búfer con valor NULL en iio_backend_debugfs_write_reg() antes de pasarlo a sscanf(). Al ser una variable de pila, no debemos asumir que se inicializará a 0.
Vulnerabilidad en kernel de Linux (CVE-2025-22083)
Severidad: ALTA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vhost-scsi: Se corrige la gestión de múltiples llamadas a vhost_scsi_set_endpoint Si vhost_scsi_set_endpoint se llama varias veces sin un vhost_scsi_clear_endpoint entre ellas, podemos encontrar múltiples errores encontrados por Haoran Zhang: 1. use-after-free cuando no se encuentran tpgs: Esto corrige un use-after-free que ocurre cuando vhost_scsi_set_endpoint se llama más de una vez y las llamadas después de la primera llamada no encuentran ningún tpg para agregar al vs_tpg. Cuando vhost_scsi_set_endpoint encuentra primero tpgs para agregar a la matriz vs_tpg match=true, entonces haremos: vhost_vq_set_backend(vq, vs_tpg); ... kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; Si se llama nuevamente a vhost_scsi_set_endpoint y no se encuentran tpgs, match=false, por lo que omitimos la llamada a vhost_vq_set_backend dejando el puntero al vs_tpg que luego liberamos mediante: kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; Si luego se envía una solicitud scsi, hacemos: vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend que ve el vs_tpg en el que acabamos de realizar un kfree. 2. Se bloquea la eliminación del directorio tpg: este parche corrige un problema por el cual no podemos eliminar un directorio tpg de capa LIO/objetivo (y estructuras por encima de él como el objetivo) debido a que el recuento de referencias cae a -1. El problema radica en que si vhost_scsi_set_endpoint detecta que ya hay un TPG en la matriz vs->vs_tpg, o si este se ha eliminado y, por lo tanto, target_depend_item falla, el controlador goto undepend ejecutará `target_undepend_item` en todos los TPG de la matriz vs_tpg, reduciendo su recuento de referencias a 0. En este momento, vs_tpg contiene tanto los TPG que hemos añadido en la llamada actual a vhost_scsi_set_endpoint como los TPG añadidos en llamadas anteriores que también están en vs->vs_tpg. Posteriormente, al ejecutarse vhost_scsi_clear_endpoint, ejecutará `target_undepend_item` en todos los TPG de vs->vs_tpg, lo que reducirá su recuento de referencias a -1. En ese caso, el espacio de usuario no podrá eliminar el TPG y se bloqueará al intentar ejecutar `rmdir` en el directorio del TPG. 3. Fuga de TPG: Esto corrige un error que permitía filtrar TPG y hacer que no se pudieran eliminar, ya que el nombre del objetivo se sobrescribía al llamar a vhost_scsi_set_endpoint varias veces, pero con nombres de objetivo diferentes. El error se produce si un usuario llama a VHOST_SCSI_SET_ENDPOINT y configura un dispositivo vhost-scsi para la asignación de destino/TPG, y luego vuelve a llamar a VHOST_SCSI_SET_ENDPOINT con un nuevo nombre de objetivo que contiene TPG desconocidos (target1 tiene TPG1, pero target2 tiene TPG2). En este caso, no se elimina la antigua asignación de TPG del objetivo, sino que se sobrescribe el nombre del objetivo y la matriz vs->vs_tpg. Posteriormente, al ejecutar vhost_scsi_clear_endpoint, se pasa el nombre de target1 o target2, y solo se coincidirán los TPG de ese objetivo al recorrer vs->vs_tpg. Luego, regresaremos de la función sin ejecutar `target_undepend_item` en los tpgs. Debido a todos estos errores, parece que nunca se permitió llamar a `vhost_scsi_set_endpoint` varias veces. El usuario principal, QEMU, ya cuenta con comprobaciones para evitar este caso de uso. Por lo tanto, para solucionar los problemas, este parche impide que se llame a `vhost_scsi_set_endpoint` si ya se han agregado correctamente los tpgs. Para agregar, eliminar o cambiar la configuración de `tpg` o el nombre del destino, primero debe ejecutar `vhost_scsi_clear_endpoint`.
Vulnerabilidad en kernel de Linux (CVE-2025-22084)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: w1: corrección de la desreferencia de puntero nulo en la sonda. La función w1_uart_probe() llama a w1_uart_serdev_open() (que incluye devm_serdev_device_open()) antes de configurar las operaciones del cliente mediante serdev_device_set_client_ops(). Este orden puede desencadenar una desreferencia de puntero nulo en el controlador receive_buf del controlador serdev, ya que asume que serdev->ops es válido cuando SERPORT_ACTIVE está configurado. Esto es similar al problema corregido en el commit 5e700b384ec1 ("platform/chrome: cros_ec_uart: corregir correctamente la condición de ejecución") donde se llamó a devm_serdev_device_open() antes de inicializar completamente el dispositivo. Corrija la ejecución asegurándose de que las operaciones del cliente estén configuradas antes de habilitar el puerto mediante w1_uart_serdev_open().
Vulnerabilidad en kernel de Linux (CVE-2025-22086)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/mlx5: Arreglar el flujo de actualización de mlx5_poll_one() cur_qp Cuando cur_qp no es NULL, para evitar obtener el QP del árbol de radix de nuevo, verificamos si el siguiente QP de cqe es idéntico al que ya tenemos. Sin embargo, el error es que estamos verificando si el QP es idéntico al comparar el número de QP dentro del CQE con el número de QP dentro de mlx5_ib_qp, pero eso es incorrecto ya que el número de QP del CQE es de FW, por lo que debe coincidir con mlx5_core_qp, que es nuestro número de QP de FW. De lo contrario, podríamos usar el QP incorrecto al gestionar un CQE, lo que podría causar el siguiente rastreo del kernel. Este problema se nota principalmente en los QP 0 y 1, ya que por ahora son los únicos QP en nuestro controlador, mientras que el número de QP dentro de mlx5_ib_qp no coincide con el número de QP dentro de mlx5_core_qp. ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000012 #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] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 No contaminado 6.14.0-rc3+ #189 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Cola de trabajo: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Código: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 00000000000000000 RCX: 0000000000000000 RDX: 00000000000000000 RSI: ffff88885fa1b3c0 RDI: fffffffa06e894a RBP: 00000000000000b0 R08: 00000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 00000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Seguimiento de llamadas: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20
Vulnerabilidad en kernel de Linux (CVE-2025-22087)
Severidad: ALTA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Corrección del error de los límites de la matriz con may_goto. may_goto utiliza 8 bytes adicionales en la pila, lo que provoca que la matriz interpreters[] salga de los límites al calcular el índice mediante stack_size. 1. Si se reescribe un programa BPF, reevalúe el tamaño de la pila. En casos que no sean JIT, rechace la carga directamente. 2. En casos que no sean JIT, el cálculo de interpreters[idx] puede seguir provocando un acceso a la matriz fuera de los límites y simplemente advertir al respecto. 3. En casos con jit_requested, también se debe advertir la ejecución de bpf_func. Por lo tanto, mueva la definición de la función __bpf_prog_ret0_warn fuera de la definición de la macro CONFIG_BPF_JIT_ALWAYS_ON.
Vulnerabilidad en kernel de Linux (CVE-2025-22089)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/core: No exponga hw_counters fuera del espacio de nombres init net. el commit 467f432a521a ("RDMA/core: Dividir los atributos sysfs del contador de puerto y dispositivo") casi expuso accidentalmente los contadores hw a espacios de nombres que no son init net. No los expuso completamente, ya que un intento de leer cualquiera de esos contadores conduce a un fallo como este: [42021.807566] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000028 [42021.814463] #PF: acceso de lectura del supervisor en modo kernel [42021.819549] #PF: error_code(0x0000) - página no presente [42021.824636] PGD 0 P4D 0 [42021.827145] Oops: 0000 [#1] SMP PTI [42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: cargado Tainted: GSWI XXX [42021.841697] Nombre del hardware: XXX [42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core] [42021.855362] Código: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48 [42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287 [42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 000000000000000 [42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0 [42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000 [42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530 [42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000 [42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000 [42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 000000000003726f0 [42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [42021.949324] Rastreo de llamadas: [42021.951756] [42021.953842] [] ? show_regs+0x64/0x70 [42021.959030] [] ? __die+0x78/0xc0 [42021.963874] [] ? page_fault_oops+0x2b5/0x3b0 [42021.969749] [] ? asm_exc_page_fault+0x26/0x30 [42021.981517] [] ? __pfx_show_hw_stats+0x10/0x10 [ib_core] [42021.988482] [] ? hw_stat_device_show+0x1e/0x40 [ib_core] [42021.995438] [] dev_attr_show+0x1e/0x50 [42022.000803] [] sysfs_kf_seq_show+0x81/0xe0 [42022.006508] [] seq_read_iter+0xf4/0x410 [42022.011954] [] vfs_read+0x16e/0x2f0 [42022.017058] [] ksys_read+0x6e/0xe0 [42022.022073] [] do_syscall_64+0x6a/0xa0 [42022.027441] [] entry_SYSCALL_64_after_hwframe+0x78/0xe2 El problema se puede reproducir siguiendo estos pasos: ip netns add foo ip netns exec foo bash cat /sys/class/infiniband/mlx4_0/hw_counters/* El pánico se produce porque la conversión del puntero del dispositivo en un puntero ib_device al usar container_of() en hw_stat_device_show() es incorrecta y provoca una corrupción de memoria. Sin embargo, el verdadero problema radica en que los contadores hw nunca deberían exponerse fuera del espacio de nombres de red no init. Para solucionarlo, guarde el índice del grupo de atributos correspondiente (podría ser 1 o 2, dependiendo de la presencia de atributos específicos del controlador) y ponga a cero el puntero al grupo hw_counters para dispositivos compatibles durante la inicialización. Con esta corrección, los contadores hw_counters no están disponibles en un espacio de nombres de red no init: find /sys/class/infiniband/mlx4_0/ -name hw_counters /sys/class/infiniband/mlx4_0/ports/1/hw_counters /sys/class/infiniband/mlx4_0/ports/2/hw_counters /sys/class/infiniband/mlx4_0/hw_counters ip netns add foo ip netns exec foo bash find /sys/class/infiniband/mlx4_0/ -name hw_counters
Vulnerabilidad en kernel de Linux (CVE-2025-22090)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mm/pat: Se corrige la gestión de VM_PAT cuando fork() falla en copy_page_range(). Si track_pfn_copy() falla, ya se agregó el VMA dst al árbol de maple. Si fork() falla, se limpiará el árbol de maple y se encontrará con el VMA dst para el cual no se realizó ninguna reserva ni se copió ninguna tabla de páginas. En consecuencia, untrack_pfn() detectará VM_PAT e intentará obtener la información de PAT de la tabla de páginas, lo cual falla porque esta no se copió. La solución más sencilla sería simplemente borrar el indicador VM_PAT del VMA dst si track_pfn_copy() falla. Sin embargo, la cuestión de simplemente borrar el indicador VM_PAT también es problemática: si pasamos track_pfn_copy() y realizamos una reserva, pero la copia de las tablas de páginas falla, simplemente borraremos el indicador VM_PAT, sin deshacer la reserva correctamente, lo cual también es incorrecto. Así que vamos a solucionarlo correctamente: configuremos el indicador VM_PAT solo si la reserva se realizó correctamente (dejándolo inicialmente en blanco) y deshagámosla si algo sale mal al copiar las tablas de páginas: borremos el indicador VM_PAT después de deshacer la reserva. Tenga en cuenta que cualquier entrada copiada de la tabla de páginas se eliminará cuando se elimine el VMA posteriormente, después de que copy_page_range() se haya ejecutado correctamente; como VM_PAT no está configurado en ese momento, no intentaremos borrarlo de nuevo y untrack_pfn() funcionará correctamente. Tenga en cuenta que dejar estas tablas de páginas sin una reserva no es un problema, ya que estamos cancelando fork(); este proceso nunca se ejecutará. Un reproductor puede activar esto generalmente en el primer intento: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c ADVERTENCIA: CPU: 26 PID: 11650 en arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 Módulos vinculados: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 No contaminado 6.12.0-rc5+ #92 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 01/04/2014 RIP: 0010:get_pat_info+0xf6/0x110 ... Seguimiento de llamadas: ... untrack_pfn+0x52/0x110 unmap_single_vma+0xa6/0xe0 unmap_vmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copy_process+0x1bf6/0x2aa0 kernel_clone+0xab/0x440 __do_sys_clone+0x66/0x90 do_syscall_64+0x95/0x180 Es probable que este caso no se haya encontrado en: d155df53f310 ("x86/mm/pat: borrar VM_PAT si copy_p4d_range falló") ... y en lugar de deshacer la reserva simplemente borramos el indicador VM_PAT. Mantenga la documentación de estas funciones en include/linux/pgtable.h, un lugar es más que suficiente; deberíamos limpiarlo para las otras funciones como track_pfn_remap/untrack_pfn por separado.
Vulnerabilidad en kernel de Linux (CVE-2025-22091)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/mlx5: Corrección del desbordamiento de la variable page_size. Se modifican todas las variables que almacenan el resultado de mlx5_umem_mkc_find_best_pgsz() a unsigned long para admitir valores superiores a 31 y evitar el desbordamiento. Por ejemplo: si intentamos registrar 4 GB de memoria contiguos a la memoria física, el controlador optimizará page_size e intentará usar una clave mkey con un tamaño de entidad de 4 GB. La variable page_size (unsigned int) se desbordará a 0 y se activará la función WARN_ON() en alloc_cacheable_mr(). ADVERTENCIA: CPU: 2 PID: 1203 at drivers/infiniband/hw/mlx5/mr.c:1124 alloc_cacheable_mr+0x22/0x580 [mlx5_ib] Modules linked in: mlx5_ib mlx5_core bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre rdma_rxe rdma_ucm ib_uverbs ib_ipoib ib_umad rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm fuse ib_core [last unloaded: mlx5_core] CPU: 2 UID: 70878 PID: 1203 Comm: rdma_resource_l Tainted: G W 6.14.0-rc4-dirty #43 Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:alloc_cacheable_mr+0x22/0x580 [mlx5_ib] Code: 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 41 52 53 48 83 ec 30 f6 46 28 04 4c 8b 77 08 75 21 <0f> 0b 49 c7 c2 ea ff ff ff 48 8d 65 d0 4c 89 d0 5b 41 5a 41 5c 41 RSP: 0018:ffffc900006ffac8 EFLAGS: 00010246 RAX: 0000000004c0d0d0 RBX: ffff888217a22000 RCX: 0000000000100001 RDX: 00007fb7ac480000 RSI: ffff8882037b1240 RDI: ffff8882046f0600 RBP: ffffc900006ffb28 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000007e0 R11: ffffea0008011d40 R12: ffff8882037b1240 R13: ffff8882046f0600 R14: ffff888217a22000 R15: ffffc900006ffe00 FS: 00007fb7ed013340(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb7ed1d8000 CR3: 00000001fd8f6006 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __warn+0x81/0x130 ? alloc_cacheable_mr+0x22/0x580 [mlx5_ib] ? report_bug+0xfc/0x1e0 ? handle_bug+0x55/0x90 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? alloc_cacheable_mr+0x22/0x580 [mlx5_ib] create_real_mr+0x54/0x150 [mlx5_ib] ib_uverbs_reg_mr+0x17f/0x2a0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xca/0x140 [ib_uverbs] ib_uverbs_run_method+0x6d0/0x780 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x19b/0x360 [ib_uverbs] ? walk_system_ram_range+0x79/0xd0 ? ___pte_offset_map+0x1b/0x110 ? __pte_offset_map_lock+0x80/0x100 ib_uverbs_ioctl+0xac/0x110 [ib_uverbs] __x64_sys_ioctl+0x94/0xb0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fb7ecf0737b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 2a 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffdbe03ecc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffdbe03edb8 RCX: 00007fb7ecf0737b RDX: 00007ffdbe03eda0 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffdbe03ed80 R08: 00007fb7ecc84010 R09: 00007ffdbe03eed4 R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffdbe03eed4 R13: 000000000000000c R14: 000000000000000c R15: 00007fb7ecc84150
Vulnerabilidad en kernel de Linux (CVE-2025-22092)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: Se corrige la desreferencia de NULL en la ruta de error de creación de VF de SR-IOV. Se limpia cuando falla la configuración de virtfn para evitar la desreferencia de punteros NULL durante la eliminación del dispositivo. El error del kernel que se muestra a continuación se produjo debido a un flujo de gestión de errores incorrecto cuando falla pci_setup_device(). Se ha añadido pci_iov_scan_device(), que gestiona la asignación y configuración de virtfn y realiza la limpieza si falla pci_setup_device(), de modo que pci_iov_add_virtfn() no necesite llamar a pci_stop_and_remove_bus_device(). Esto impide el acceso a dispositivos virtfn parcialmente inicializados durante la eliminación. ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000000d0 RIP: 0010:device_del+0x3d/0x3d0 Rastreo de llamadas: pci_remove_bus_device+0x7c/0x100 pci_iov_add_virtfn+0xfa/0x200 sriov_enable+0x208/0x420 mlx5_core_sriov_configure+0x6a/0x160 [mlx5_core] sriov_numvfs_store+0xae/0x1a0 [bhelgaas: registro de confirmaciones, devuelve ERR_PTR(-ENOMEM) directamente]
Vulnerabilidad en kernel de Linux (CVE-2025-22093)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: evitar NPD cuando el ASIC no es compatible con DMUB. ctx->dmub_srv devuelve NULL si el ASIC no es compatible con DMUB, lo cual se prueba en dm_dmub_sw_init. Sin embargo, se desreferenciará en dmub_hw_lock_mgr_cmd si should_use_dmub_lock devuelve verdadero. Esto ha sido así desde que se añadió la compatibilidad con dmub para PSR1. Para solucionarlo, verifique dmub_srv en should_use_dmub_lock. [ 37.440832] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000058 [ 37.447808] #PF: acceso de lectura del supervisor en modo kernel [ 37.452959] #PF: error_code(0x0000) - página no presente [ 37.458112] PGD 0 P4D 0 [ 37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI [ 37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread No contaminado 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88 [ 37.478324] Nombre del hardware: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 26/10/2023 [ 37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.492074] Código: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 <48> 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5 [ 37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202 [ 37.516052] RAX: 000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358 [ 37.523185] RDX: ffff969442853368 RSI: 00000000000000001 RDI: 0000000000000000 [ 37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5 [ 37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000 [ 37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000 [ 37.551725] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000 [ 37.559814] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.565562] CR2: 000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0 [ 37.572697] Rastreo de llamadas: [ 37.575152] [ 37.577258] ¿__die_body+0x66/0xb0 [ 37.580756] ? page_fault_oops+0x3e7/0x4a0 [ 37.584861] ? exc_page_fault+0x3e/0xe0 [ 37.588706] ? exc_page_fault+0x5c/0xe0 [ 37.592550] ? asm_exc_page_fault+0x22/0x30 [ 37.596742] ? dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.601107] dcn10_cursor_lock+0x1e1/0x240 [ 37.605211] program_cursor_attributes+0x81/0x190 [ 37.609923] commit_planes_for_stream+0x998/0x1ef0 [ 37.614722] update_planes_and_stream_v2+0x41e/0x5c0 [ 37.619703] dc_update_planes_and_stream+0x78/0x140 [ 37.624588] amdgpu_dm_atomic_commit_tail+0x4362/0x49f0 [ 37.629832] ? srso_return_thunk+0x5/0x5f [ 37.633847] ? mark_held_locks+0x6d/0xd0 [ 37.637774] ? _raw_spin_unlock_irq+0x24/0x50 [ 37.642135] ? srso_return_thunk+0x5/0x5f [ 37.646148] ? lockdep_hardirqs_on+0x95/0x150 [ 37.650510] ? srso_return_thunk+0x5/0x5f [ 37.654522] ? _raw_spin_unlock_irq+0x2f/0x50 [ 37.658883] ? srso_return_thunk+0x5/0x5f [ 37.662897] ? esperar_a_común+0x186/0x1c0 [ 37.666998] ? srso_return_thunk+0x5/0x5f [ 37.671009] ? drm_crtc_next_vblank_start+0xc3/0x170 [ 37.675983] confirmación_cola+0xf5/0x1c0 [ 37.679478] drm_atomic_helper_commit+0x2a2/0x2b0 [ 37.684186] drm_atomic_commit+0xd6/0x100 [ 37.688199] ? __cfi___drm_printfn_info+0x10/0x10 [ 37.692911] drm_atomic_helper_update_plane+0xe5/0x130 [ 37.698054] drm_mode_cursor_common+0x501/0x670 [ 37.702600] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10 [ 37.707572] drm_mode_cursor_ioctl+0x48/0x70 [ 37.711851] drm_ioctl_kernel+0xf2/0x150 [ 37.715781] drm_ioctl+0x363/0x590 [ 37.719189] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10 [ 37.724165] amdgpu_drm_ioctl+0x41/0x80 [ 37.728013] __se_sys_ioctl+0x7f/0xd0 [ 37.731685] do_syscall_64+0x87/0x100 [ 37.735355] ? vma_end_read+0x12/0xe0 [ 37.739024] ? srso_return_thunk+0x5/0x5f [ 37.743041] ? find_held_lock+0x47/0xf0 [ 37.746884] ? vma_end_read+0x12/0xe0 [37.750552] ? srso_return_thunk+0x5/0 ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2025-22094)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/perf: Se corrige el conteo de referencias en la PMU 'vpa_pmu'. El commit 176cda0619b6 ("powerpc/perf: Añadir interfaz perf para exponer contadores vpa") introdujo 'vpa_pmu' para exponer los contadores de latencia de cambio de contexto L1<->L2 proporcionados por la APIv2 anidada de Book3s-HV al espacio de usuario L1 mediante eventos perf. Sin embargo, la nueva PMU, denominada 'vpa_pmu', no asigna la propiedad de la PMU al módulo 'vpa_pmu'. En consecuencia, el módulo 'vpa_pmu' se puede descargar mientras uno de los eventos de rendimiento aún está activo, lo que puede provocar errores y pánico en el kernel del formato siguiente en un Pseries-LPAR: ERROR: Desreferencia de puntero NULL del kernel en lectura en 0x00000058 NIP [c000000000506cb8] event_sched_out+0x40/0x258 LR [c00000000050e8a4] __perf_remove_from_context+0x7c/0x2b0 Rastreo de llamadas: [c00000025fc3fc30] [c00000025f8457a8] 0xc00000025f8457a8 (no confiable) [c00000025fc3fc80] [ffffffffffffffee0] 0xffffffffffffffee0 [c00000025fc3fcd0] [c000000000501e70] event_function+0xa8/0x120 Pánico del kernel: no se sincroniza: ¡Ay, se está eliminando el controlador de interrupciones! Para solucionarlo, agregue la propiedad del módulo a 'vpa_pmu' para que se contabilice y se evite su descarga al inicializar eventos de rendimiento.
Vulnerabilidad en kernel de Linux (CVE-2025-22095)
Severidad: MEDIA
Fecha de publicación: 16/04/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: brcmstb: Corrección de la ruta de error tras una llamada a regulator_bulk_get(). Si regulator_bulk_get() devuelve un error y no se crean reguladores, debemos establecer su número en cero. Si no lo hacemos y falla la conexión PCIe, una llamada a regulator_bulk_free() provocará un pánico del kernel. Mientras tanto, imprima el valor del error, ya que no podemos devolver un error hacia arriba, ya que el kernel emitirá una advertencia WARN() en caso de un error de add_bus(). [kwilczynski: registro de confirmaciones, usar coma en el mensaje para que coincida con el estilo de otros mensajes similares]
Vulnerabilidad en kernel de Linux (CVE-2025-37786)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: tabla de enrutamiento libre en caso de fallo de sondeo. Si "complete" es verdadero en dsa_tree_setup(), significa que somos el último conmutador del árbol que está sondeando correctamente, y deberíamos estar configurando todos los conmutadores desde nuestra ruta de sondeo. Una vez que "complete" es verdadero, dsa_tree_setup_cpu_ports() o cualquier función posterior puede fallar. Si esto ocurre, toda la configuración del árbol queda en el limbo: los primeros N-1 conmutadores han finalizado el sondeo correctamente (sin hacer nada más que asignar memoria persistente en dst->ports del árbol, y quizás en dst->rtable), y el conmutador N no ha podido sondear, finalizando el proceso de configuración del árbol antes de que el usuario pueda ver nada tangible. Si el conmutador N no puede sondear, su memoria (puertos) se liberará y se eliminará de dst->ports. Sin embargo, los elementos dst->rtable que apuntan a sus puertos, tal como los creó dsa_link_touch(), permanecerán allí y darán lugar a un use-after-free si se desreferencian. Si dsa_tree_setup_switches() devuelve -EPROBE_DEFER, lo cual es completamente posible porque es donde está ds->ops->setup(), obtenemos un informe de kasan como este: ===================================================================== ERROR: KASAN: slab-use-after-free en mv88e6xxx_setup_upstream_port+0x240/0x568 Lectura de tamaño 8 en la dirección ffff000004f56020 por la tarea kworker/u8:3/42 Rastreo de llamadas: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 La forma más sencilla de corregir el error es eliminar la tabla de enrutamiento en su totalidad. dsa_tree_setup_routing_table() no tiene problemas para regenerarla incluso si eliminamos enlaces entre puertos distintos a los del switch N, ya que dsa_link_touch() primero comprueba si el par de puertos ya existe en dst->rtable, y la asigna en caso contrario. La eliminación completa de la tabla de enrutamiento ya existe en dsa_tree_teardown(), por lo que se debe refactorizar en una función que también pueda llamarse desde la ruta de error de configuración del árbol. En mi análisis de la confirmación responsable, es la que añadió elementos dsa_link a dst->rtable. Antes de eso, cada switch tenía su propia ds->rtable, que se libera cuando el switch falla al sondear. Sin embargo, el árbol es potencialmente memoria persistente.
Vulnerabilidad en kernel de Linux (CVE-2025-37787)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: mv88e6xxx: evitar anular el registro de regiones devlink que nunca se registraron Russell King informa que un sistema con mv88e6xxx desreferencia un puntero NULL al desvincular este controlador: https://lore.kernel.org/netdev/Z_lRkMlTJ1KQ0kVX@shell.armlinux.org.uk/ El fallo parece estar en devlink_region_destroy(), que no tolera NULL pero se le asigna un puntero de región global devlink NULL. Al menos en algunos chips, algunas regiones devlink se registran condicionalmente desde la confirmación culpable, consulte mv88e6xxx_setup_devlink_regions_global(): if (cond && !cond(chip)) continue; Estos son MV88E6XXX_REGION_STU y MV88E6XXX_REGION_PVT. Si el chip no tiene una STU o PVT, debería fallar de esta manera. Para solucionar el problema, evite anular el registro de las regiones nulas, es decir, las que se omitieron al ejecutar mv88e6xxx_setup_devlink_regions_global().
Vulnerabilidad en kernel de Linux (CVE-2025-37793)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: Intel: avs: Se corrige la desreferencia de puntero null en avs_component_probe(). Devm_kasprintf() devuelve NULL cuando falla la asignación de memoria. Actualmente, avs_component_probe() no verifica este caso, lo que resulta en una desreferencia de puntero NULL.
Vulnerabilidad en kernel de Linux (CVE-2025-37794)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: Purgar la txq de vif en ieee80211_do_stop(). Después de ieee80211_do_stop(), el SKB de la txq de vif aún podía procesarse. De hecho, otra llamada simultánea a vif schedule_and_wake_txq podría provocar que esos paquetes se descolgaran (véase ieee80211_handle_wake_tx_queue()) sin comprobar el estado actual de sdata. Dado que vif.drv_priv se borra en esta función, esto podría provocar un fallo del controlador. Por ejemplo, en ath12k, ahvif se almacena en vif.drv_priv. Por lo tanto, si se llama ath12k_mac_op_tx() después de ieee80211_do_stop(), ahvif->ah puede ser NULL, lo que lleva a la llamada ath12k_warn(ahvif->ah,...) en esta función a activar la deref NULL a continuación. No se puede gestionar la solicitud de paginación del núcleo en la dirección virtual dfffffc000000001 KASAN: null-ptr-deref en el rango [0x000000000000008-0x000000000000000f] batman_adv: bat0: Interfaz desactivada: brbh1337 Información de aborto de memoria: ESR = 0x0000000096000004 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: fallo de traducción de nivel 0 Información de aborto de datos: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] dirección entre rangos de direcciones de usuario y kernel Error interno: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd No contaminado 6.13.0-g633f875b8f1e #114 Nombre del hardware: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 000000000000000 x12: ffffffb003a0bf03 x11: 000000000000000 x10: ffffffb003a0bf02 x9: ffffff8034a19f40 x8: ffffff801d05f818 x7: 1ffffff0069433dc x6: ffffff8034a19ee0 x5: ffffff801d05f7f0 x4: 0000000000000000 x3: 0000000000000001 x2: 0000000000000000 x1: dfffffc000000000 x0: 0000000000000008 Rastreo de llamadas: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158 Para evitar eso, vacíe el txq de vif en ieee80211_do_stop() para que ningún paquete pueda sacarse de la cola después de ieee80211_do_stop() (los paquetes nuevos no pueden ponerse en cola porque SDATA_STATE_RUNNING se borra en este punto).
Vulnerabilidad en kernel de Linux (CVE-2025-37796)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 31/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: at76c50x: se corrige el use after free en at76_disconnect. La memoria a la que apunta priv se libera al final de la función at76_delete_device (mediante ieee80211_free_hw). Sin embargo, el código accede al campo udev del objeto liberado para colocar el dispositivo USB. Esto también puede provocar una fuga de memoria del dispositivo USB. Se soluciona usando udev desde la interfaz.
Vulnerabilidad en ponaravindb Hospital Management System 1.0 (CVE-2025-6339)
Severidad: MEDIA
Fecha de publicación: 20/06/2025
Fecha de última actualización: 31/10/2025
Se encontró una vulnerabilidad en ponaravindb Hospital Management System 1.0. Se ha clasificado como crítica. Este problema afecta a una funcionalidad desconocida del archivo /func3.php. La manipulación del argumento username1 provoca una inyección SQL. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado.
Vulnerabilidad en chatchat-space Langchain-Chatchat (CVE-2025-6854)
Severidad: MEDIA
Fecha de publicación: 29/06/2025
Fecha de última actualización: 31/10/2025
Se encontró una vulnerabilidad clasificada como problemática en chatchat-space Langchain-Chatchat hasta la versión 0.3.1. Esta vulnerabilidad afecta al código desconocido del archivo /v1/files?purpose=assistants. La manipulación provoca path traversal. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado.
Vulnerabilidad en chatchat-space Langchain-Chatchat (CVE-2025-6855)
Severidad: MEDIA
Fecha de publicación: 29/06/2025
Fecha de última actualización: 31/10/2025
Se ha detectado una vulnerabilidad clasificada como crítica en chatchat-space Langchain-Chatchat hasta la versión 0.3.1. Este problema afecta a un procesamiento desconocido del archivo /v1/file. La manipulación del indicador de argumento provoca un path traversal. Se ha hecho público el exploit y puede que sea utilizado.
Vulnerabilidad en Salesforce Tableau Server (CVE-2025-52446)
Severidad: ALTA
Fecha de publicación: 25/07/2025
Fecha de última actualización: 31/10/2025
La vulnerabilidad de omisión de autorización a través de una clave controlada por el usuario en Salesforce Tableau Server en Windows, Linux (módulos de API tab-doc) permite la manipulación de la interfaz (acceso a los datos del clúster de la base de datos de producción). Este problema afecta a Tableau Server: antes de 2025.1.3, antes de 2024.2.12, antes de 2023.3.19.
Vulnerabilidad en Salesforce Tableau Server (CVE-2025-52448)
Severidad: ALTA
Fecha de publicación: 25/07/2025
Fecha de última actualización: 31/10/2025
La vulnerabilidad omisión de autorización a través de una clave controlada por el usuario en Salesforce Tableau Server para Windows y Linux (módulos de la API de Validate-Initial-SQL) permite la manipulación de la interfaz (acceso a datos del clúster de la base de datos de producción). Este problema afecta a Tableau Server: versiones anteriores a 2025.1.3, 2024.2.12 y 2023.3.19.
Vulnerabilidad en Salesforce Tableau Server (CVE-2025-52447)
Severidad: ALTA
Fecha de publicación: 25/07/2025
Fecha de última actualización: 31/10/2025
La vulnerabilidad Omisión de autorización mediante clave controlada por el usuario en Salesforce Tableau Server para Windows y Linux (módulos del comando set-initial-sql tabdoc) permite la manipulación de la interfaz (acceso a datos del clúster de la base de datos de producción). Este problema afecta a Tableau Server: versiones anteriores a 2025.1.3, 2024.2.12 y 2023.3.19.
Vulnerabilidad en Salesforce Tableau Server (CVE-2025-52449)
Severidad: ALTA
Fecha de publicación: 25/07/2025
Fecha de última actualización: 31/10/2025
La vulnerabilidad de carga sin restricciones de archivos con tipos peligrosos en Salesforce Tableau Server para Windows y Linux (módulos de Servicio de Protocolo Extensible) permite la ejecución alternativa debido a nombres de archivo engañosos (RCE). Este problema afecta a Tableau Server: versiones anteriores a 2025.1.3, 2024.2.12 y 2023.3.19.
Vulnerabilidad en jerryshensjf JPACookieShop ????JPA? (CVE-2025-8222)
Severidad: MEDIA
Fecha de publicación: 27/07/2025
Fecha de última actualización: 31/10/2025
Se ha encontrado una vulnerabilidad clasificada como problemática en jerryshensjf JPACookieShop ????JPA? hasta 24a15c02b4f75042c9f7f615a3fed2ec1cefb999. Este problema afecta a una funcionalidad desconocida del archivo GoodsController.java. La manipulación provoca cross site scripting. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado. Este producto utiliza un sistema de entrega continua con versiones continuas. Por lo tanto, no se dispone de detalles de las versiones afectadas ni de versiones actualizadas. Varios endpoints están afectados.
Vulnerabilidad en jerryshensjf JPACookieShop ????JPA? (CVE-2025-8223)
Severidad: MEDIA
Fecha de publicación: 27/07/2025
Fecha de última actualización: 31/10/2025
Se encontró una vulnerabilidad clasificada como problemática en jerryshensjf JPACookieShop ????JPA? hasta 24a15c02b4f75042c9f7f615a3fed2ec1cefb999. Esta vulnerabilidad afecta a una parte desconocida del archivo AdminTypeCustController.java. La manipulación provoca cross-site request forgery. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado. Este producto no utiliza control de versiones. Por ello, no hay información disponible sobre las versiones afectadas y no afectadas.
Vulnerabilidad en jerryshensjf JPACookieShop ????JPA? (CVE-2025-8221)
Severidad: MEDIA
Fecha de publicación: 27/07/2025
Fecha de última actualización: 31/10/2025
Se encontró una vulnerabilidad clasificada como problemática en jerryshensjf JPACookieShop ????JPA? hasta 24a15c02b4f75042c9f7f615a3fed2ec1cefb999. Esta vulnerabilidad afecta a la función "goodsSearch" del archivo GoodsCustController.java. La manipulación de la palabra clave del argumento provoca cross site scripting. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado. Este producto utiliza el enfoque de lanzamiento continuo para garantizar una entrega continua. Por lo tanto, no se dispone de detalles de las versiones afectadas ni de las actualizadas.
Vulnerabilidad en elunez eladmin (CVE-2025-9239)
Severidad: MEDIA
Fecha de publicación: 20/08/2025
Fecha de última actualización: 31/10/2025
Se identificó una vulnerabilidad en elunez eladmin hasta la versión 2.7. Esta vulnerabilidad afecta la función EncryptUtils del archivo eladmin-common/src/main/java/me/zhengjie/utils/EncryptUtils.java del componente DES Key Handler. La manipulación del argumento STR_PARAM con la entrada Passw0rd produce una seguridad de cifrado insuficiente. El ataque puede ejecutarse en remoto. Es un ataque de complejidad bastante alta. Parece difícil de explotar.
Vulnerabilidad en elunez eladmin (CVE-2025-9240)
Severidad: MEDIA
Fecha de publicación: 20/08/2025
Fecha de última actualización: 31/10/2025
Se ha descubierto una falla de seguridad en elunez eladmin hasta la versión 2.7. Este problema afecta a una funcionalidad desconocida del archivo /auth/info. La manipulación da como resultado la divulgación de información. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado.
Vulnerabilidad en elunez eladmin (CVE-2025-9241)
Severidad: MEDIA
Fecha de publicación: 20/08/2025
Fecha de última actualización: 31/10/2025
Se ha identificado una vulnerabilidad en elunez eladmin (hasta la versión 2.7). Esta vulnerabilidad afecta a la función exportUser. Esta manipulación provoca la inyección de archivos CSV. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado.