Instituto Nacional de ciberseguridad. Sección Incibe

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

Ir al buscador

Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

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



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

  • Vulnerabilidad en Delinea Secret Server (CVE-2024-33891)
    Severidad: ALTA
    Fecha de publicación: 28/04/2024
    Fecha de última actualización: 28/10/2025
    Delinea Secret Server anterior a 11.7.000001 permite a los atacantes eludir la autenticación a través de la API SOAP en SecretServer/webservices/SSWebService.asmx. Esto está relacionado con una clave codificada, el uso del número entero 2 para el usuario administrador y la eliminación del atributo oauthExpirationId.
  • Vulnerabilidad en HCL Connections (CVE-2024-30112)
    Severidad: MEDIA
    Fecha de publicación: 25/06/2024
    Fecha de última actualización: 28/10/2025
    HCL Connections es vulnerable a un ataque de Cross-Site Scripting en el que un atacante puede aprovechar este problema para ejecutar código de script arbitrario en el navegador de un usuario desprevenido, lo que lleva a la ejecución de código de scripts maliciosos. Esto puede permitir al atacante robar credenciales de autenticación basadas en cookies, acceder a la cuenta del usuario y luego lanzar otros ataques.
  • Vulnerabilidad en SAP Business Warehouse (CVE-2024-39595)
    Severidad: MEDIA
    Fecha de publicación: 09/07/2024
    Fecha de última actualización: 28/10/2025
    SAP Business Warehouse: la aplicación de simulación y planificación empresarial no codifica suficientemente las entradas controladas por el usuario, lo que genera una vulnerabilidad de Cross Site Scripting almacenado (XSS). Esta vulnerabilidad permite a los usuarios modificar el contenido del sitio web y, si se explota con éxito, un atacante puede causar poco impacto en la confidencialidad y la integridad de la aplicación.
  • Vulnerabilidad en SAP NetWeaver Application Server para ABAP (CVE-2024-39599)
    Severidad: MEDIA
    Fecha de publicación: 09/07/2024
    Fecha de última actualización: 28/10/2025
    Debido a un fallo en el mecanismo de protección en SAP NetWeaver Application Server para ABAP y la plataforma ABAP, un desarrollador puede omitir la API del escáner de malware configurada debido a un error de programación. Esto conduce a un bajo impacto en la confidencialidad, integridad y disponibilidad de la aplicación.
  • Vulnerabilidad en SAP BusinessObjects Business Intelligence Platform (CVE-2024-45281)
    Severidad: MEDIA
    Fecha de publicación: 10/09/2024
    Fecha de última actualización: 28/10/2025
    SAP BusinessObjects Business Intelligence Platform permite a un usuario con privilegios elevados ejecutar aplicaciones de escritorio de cliente incluso si algunas de las DLL no están firmadas digitalmente o si la firma está rota. El atacante debe tener acceso local al sistema vulnerable para realizar tareas relacionadas con las DLL. Esto podría tener un gran impacto en la confidencialidad e integridad de la aplicación.
  • Vulnerabilidad en HCL Connections (CVE-2024-42188)
    Severidad: BAJA
    Fecha de publicación: 14/11/2024
    Fecha de última actualización: 28/10/2025
    HCL Connections es vulnerable a una vulnerabilidad de control de acceso roto que puede permitir que un usuario no autorizado actualice datos en ciertos escenarios.
  • Vulnerabilidad en ESM 11.6.10 (CVE-2024-11481)
    Severidad: ALTA
    Fecha de publicación: 29/11/2024
    Fecha de última actualización: 28/10/2025
    Una vulnerabilidad en ESM 11.6.10 permite el acceso no autenticado a la API interna de Snowservice. Esto genera un manejo inadecuado de path traversal, un reenvío inseguro a un backend AJP sin la validación adecuada y una falta de autenticación para acceder a los endpoints de la API interna.
  • Vulnerabilidad en kernel de Linux (CVE-2024-58019)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvkm/gsp: avanza correctamente el puntero de lectura de la cola de mensajes GSP Un mensaje de evento GSP consta de tres partes: encabezado del mensaje, encabezado RPC, cuerpo del mensaje. GSP calcula el número de páginas a escribir a partir del tamaño total de un mensaje GSP. Este comportamiento se puede observar a partir del movimiento del puntero de escritura. Sin embargo, nvkm solo toma el tamaño del encabezado RPC y el cuerpo del mensaje como el tamaño del mensaje al avanzar el puntero de lectura. Al manejar un mensaje GSP de dos páginas en el caso de no reversión, toma erróneamente el cuerpo del mensaje anterior como el encabezado del mensaje del siguiente mensaje. Como la "longitud del mensaje" tiende a ser cero, en el cálculo del tamaño que se debe copiar (0 - tamaño de (encabezado del mensaje)), el tamaño que se debe copiar será "0xffffffxx". También desencadena un pánico del kernel debido a un error de puntero NULL. [ 547.614102] mensaje: 00000f90: ff ff ff ff ff ff ff ff 40 d7 18 fb 8b 00 00 00 ........@....... [ 547.622533] mensaje: 00000fa0: 00 00 00 00 ff ff ff ff ff ff ff 00 00 00 00 ................ [ 547.630965] msj: 00000fb0: ff ff ff ff ff ff ff ff 00 00 00 00 ff ff ff ff ................ [ 547.639397] msj: 00000fc0: ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff ff ................ [ 547.647832] nvkm 0000:c1:00.0: gsp: peek msg rpc fn:0 len:0x0/0xffffffffffffffe0 [ 547.655225] nvkm 0000:c1:00.0: gsp: get msg rpc fn:0 len:0x0/0xffffffffffffffe0 [ 547.662532] ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000020 [ 547.669485] #PF: acceso de lectura del supervisor en modo núcleo [ 547.674624] #PF: error_code(0x0000) - página no presente [ 547.679755] PGD 0 P4D 0 [ 547.682294] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 547.686643] CPU: 22 PID: 322 Comm: kworker/22:1 Contaminado: GE 6.9.0-rc6+ #1 [ 547.694893] Nombre del hardware: ASRockRack 1U1G-MILAN/N/ROMED8-NL, BIOS L3.12E 09/06/2022 [ 547.702626] Cola de trabajo: eventos r535_gsp_msgq_work [nvkm] [ 547.707921] RIP: 0010:r535_gsp_msg_recv+0x87/0x230 [nvkm] [ 547.713375] Código: 00 8b 70 08 48 89 e1 31 d2 4c 89 f7 e8 12 f5 ff ff 48 89 c5 48 85 c0 0f 84 cf 00 00 00 48 81 fd 00 f0 ff ff 0f 87 c4 00 00 00 <8b> 55 10 41 8b 46 30 85 d2 0f 85 f6 00 00 00 83 f8 04 76 10 ba 05 [ 547.732119] RSP: 0018:ffffabe440f87e10 EFLAGS: 00010203 [ 547.737335] RAX: 0000000000000010 RBX: 000000000000000008 RCX: 000000000000003f [ 547.744461] RDX: 0000000000000000 RSI: ffffabe4480a8030 RDI: 0000000000000010 [ 547.751585] RBP: 0000000000000010 R08: 0000000000000000 R09: ffffabe440f87bb0 [ 547.758707] R10: ffffabe440f87dc8 R11: 0000000000000010 R12: 0000000000000000 [ 547.765834] R13: 0000000000000000 R14: ffff9351df1e5000 R15: 0000000000000000 [ 547.772958] FS: 0000000000000000(0000) GS:ffff93708eb00000(0000) knlGS:0000000000000000 [ 547.781035] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 547.786771] CR2: 0000000000000020 CR3: 00000003cc220002 CR4: 0000000000770ef0 [ 547.793896] PKRU: 55555554 [ 547.796600] Rastreo de llamadas: [ 547.799046] [ 547.801152] ? __die+0x20/0x70 [ 547.804211] ? page_fault_oops+0x75/0x170 [ 547.808221] ? print_hex_dump+0x100/0x160 [ 547.812226] ? exc_page_fault+0x64/0x150 [ 547.816152] ? asm_exc_page_fault+0x22/0x30 [ 547.820341] ? r535_gsp_msg_recv+0x87/0x230 [nvkm] [ 547.825184] r535_gsp_msgq_work+0x42/0x50 [nvkm] [ 547.829845] process_one_work+0x196/0x3d0 [ 547.833861] worker_thread+0x2fc/0x410 [ 547.837613] ? __pfx_worker_thread+0x10/0x10 [ 547.841885] kthread+0xdf/0x110 [ 547.845031] ? __pfx_kthread+0x10/0x10 [ 547.848775] ret_from_fork+0x30/0x50 [ 547.852354] ? __pfx_kthread+0x10/0x10 [ 547.856097] ret_from_fork_asm+0x1a/0x30 [ 547.860019] [ 547.862208] Módulos vinculados en: nvkm(E) gsp_log(E) snd_seq_dummy(E) snd_hrtimer(E) snd_seq(E) snd_timer(E) snd_seq_device(E) snd(E) soundcore(E) rfkill(E) qrtr(E) vfat(E) fat(E) ipmi_ssif(E) amd_atl(E) intel_rapl_msr(E) intel_rapl_common(E) amd64_edac(E) mlx5_ ---truncado---
  • Vulnerabilidad en kernel de Linux (CVE-2025-21732)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/mlx5: corrige una ejecución para un MR de ODP que conduce a un CQE con error Este parche soluciona una condición de ejecución para un MR de ODP que puede resultar en un CQE con un error en el QP de UMR. Durante el flujo __mlx5_ib_dereg_mr(), ocurre la siguiente secuencia de llamadas: mlx5_revoke_mr() mlx5r_umr_revoke_mr() mlx5r_umr_post_send_wait() En este punto, la lkey se libera desde la perspectiva del hardware. Sin embargo, al mismo tiempo, mlx5_ib_invalidate_range() podría ser activado por otra tarea que intente invalidar un rango para la misma lkey liberada. Esta tarea: - Adquirirá el bloqueo umem_odp->umem_mutex. - Llamará a mlx5r_umr_update_xlt() en el QP de UMR. - Dado que la lkey ya se ha liberado, esto puede provocar un error de CQE, lo que hace que el QP de UMR entre en un estado de error [1]. Para resolver esta condición de ejecución, el bloqueo umem_odp->umem_mutex ahora también se adquiere como parte del ámbito mlx5_revoke_mr(). Tras una revocación exitosa, configuramos umem_odp->private que apunta a ese MR en NULL, lo que evita cualquier otro intento de invalidación en su lkey. [1] De dmesg: infiniband rocep8s0f0: dump_cqe:277:(pid 0): Error de WC: 6, Mensaje: error de operación de enlace de memoria cqe_dump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2 ADVERTENCIA: CPU: 15 PID: 1506 en drivers/infiniband/hw/mlx5/umr.c:394 mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib] Módulos vinculados en: ip6table_mangle ip6table_natip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss superposición de oid_registry rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core CPU: 15 UID: 0 PID: 1506 Comm: ibv_rc_pingpong No contaminado 6.12.0-rc7+ #1626 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 RIP: 0010:mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib] [..] Llamada Rastreo: mlx5r_umr_update_xlt+0x23c/0x3e0 [mlx5_ib] mlx5_ib_invalidate_range+0x2e1/0x330 [mlx5_ib] __mmu_notifier_invalidate_range_start+0x1e1/0x240 zap_page_range_single+0xf1/0x1a0 madvise_vma_behavior+0x677/0x6e0 do_madvise+0x1a2/0x4b0 __x64_sys_madvise+0x25/0x30 do_syscall_64+0x6b/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e
  • Vulnerabilidad en kernel de Linux (CVE-2025-21733)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing/osnoise: Arreglar el restablecimiento de los puntos de seguimiento Si se inicia un rastreador timerlat con la opción de osnoise OSNOISE_WORKLOAD deshabilitada, pero luego se habilita esa opción y se elimina timerlat, los puntos de seguimiento que se habilitaron en el registro de timerlat no se deshabilitan. Si la opción se deshabilita nuevamente y se inicia timelat, entonces se activa una advertencia en el código del punto de seguimiento debido a que se registra nuevamente el punto de seguimiento sin deshabilitarlo nunca. No use las mismas opciones definidas en el espacio de usuario para saber que debe deshabilitar los puntos de seguimiento cuando se elimina timerlat. En su lugar, configure un indicador global cuando esté habilitado y use ese indicador para saber que debe deshabilitar los eventos. ~# echo NO_OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo timerlat > /sys/kernel/tracing/current_tracer ~# echo OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo nop > /sys/kernel/tracing/current_tracer ~# echo NO_OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo timerlat > /sys/kernel/tracing/current_tracer Desencadenadores: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 6 PID: 1337 en kernel/tracepoint.c:294 tracepoint_add_func+0x3b6/0x3f0 Módulos vinculados: CPU: 6 UID: 0 PID: 1337 Comm: rtla No contaminado 6.13.0-rc4-test-00018-ga867c441128e-dirty #73 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 RIP: 0010:tracepoint_add_func+0x3b6/0x3f0 Código: 48 8b 53 28 48 8b 73 20 4c 89 04 24 e8 23 59 11 00 4c 8b 04 24 e9 36 fe ff ff 0f 0b b8 ea ff ff ff 45 84 e4 0f 84 68 fe ff ff <0f> 0b e9 61 fe ff ff 48 8b 7b 18 48 85 ff 0f 84 4f ff ff ff 49 8b RSP: 0018:ffffb9b003a87ca0 EFLAGS: 00010202 RAX: 00000000ffffffef RBX: ffffffff92f30860 RCX: 000000000000000 RDX: 000000000000000 RSI: ffff9bf59e91ccd0 RDI: ffffffff913b6410 RBP: 000000000000000a R08: 00000000000005c7 R09: 0000000000000002 R10: ffffb9b003a87ce0 R11: 0000000000000002 R12: 0000000000000001 R13: ffffb9b003a87ce0 R14: ffffffffffffffff R15: 0000000000000008 FS: 00007fce81209240(0000) GS:ffff9bf6fdd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055e99b728000 CR3: 00000001277c0002 CR4: 0000000000172ef0 Seguimiento de llamadas: ? __warn.cold+0xb7/0x14d ? tracepoint_add_func+0x3b6/0x3f0 ? report_bug+0xea/0x170 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? __pfx_trace_sched_migrate_callback+0x10/0x10 ? tracepoint_add_func+0x3b6/0x3f0 ? __pfx_trace_sched_migrate_callback+0x10/0x10 ? __pfx_trace_sched_migrate_callback+0x10/0x10 tracepoint_probe_register+0x78/0xb0 ? __pfx_trace_sched_migrate_callback+0x10/0x10 osnoise_workload_start+0x2b5/0x370 timerlat_tracer_init+0x76/0x1b0 tracing_set_tracer+0x244/0x400 tracing_set_trace_write+0xa0/0xe0 vfs_write+0xfc/0x570 ? do_sys_openat2+0x9c/0xe0 ksys_write+0x72/0xf0 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
  • Vulnerabilidad en kernel de Linux (CVE-2025-21734)
    Severidad: ALTA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: fastrpc: Se corrige el tamaño de página del búfer de copia Para un búfer no registrado, el controlador fastrpc copia el búfer y lo pasa al subsistema remoto. Hay un problema con la implementación actual del cálculo del tamaño de página que no considera el desplazamiento en el cálculo. Esto podría provocar que se pase un tamaño de página incorrecto y fuera de los límites, lo que podría generar un problema de memoria. Calcule el inicio y el final de la página utilizando la dirección ajustada por desplazamiento en lugar de la dirección absoluta.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21738)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: libata-sff: Asegúrese de que no podamos escribir fuera del búfer asignado reveliofuzzing informó que un ioctl SCSI_IOCTL_SEND_COMMAND con out_len establecido en 0xd42, comando SCSI establecido en ATA_16 PASS-THROUGH, comando ATA establecido en ATA_NOP y protocolo establecido en ATA_PROT_PIO, puede hacer que ata_pio_sector() escriba fuera del búfer asignado, sobrescribiendo memoria aleatoria. Si bien se supone que un dispositivo ATA debe abortar un comando ATA_NOP, parece haber un error en libata-sff o QEMU, donde este estado no está establecido o el estado se borra antes de la lectura por ata_sff_hsm_move(). De todos modos, es muy probable que se trate de un error separado. Si analizamos __atapi_pio_bytes(), veremos que ya tiene una comprobación de seguridad para garantizar que __atapi_pio_bytes() no pueda escribir fuera del búfer asignado. Agreguemos una comprobación similar a ata_pio_sector(), de modo que ata_pio_sector() tampoco pueda escribir fuera del búfer asignado.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21746)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: synaptics - arregla el fallo al habilitar el puerto de paso Al habilitar un puerto de paso, puede aparecer una interrupción antes de que el controlador psmouse se vincule al puerto de paso. Sin embargo, el subcontrolador synaptics intenta acceder a la instancia psmouse presuntamente asociada con el puerto de paso para averiguar si solo se necesita reenviar 1 byte de respuesta o el paquete de protocolo completo al puerto de paso y puede bloquearse si la instancia psmouse aún no se ha adjuntado al puerto. Arregla el bloqueo introduciendo los métodos open() y close() para el puerto y comprueba si el puerto está abierto antes de intentar acceder a la instancia psmouse. Debido a que psmouse llama a serio_open() solo después de adjuntar la instancia psmouse a la instancia del puerto serio, esto evita el posible bloqueo.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21747)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/ast: astdp: Se ha solucionado el problema del tiempo de espera para habilitar la señal de vídeo. El transmisor ASTDP a veces tarda hasta 1 segundo en habilitar la señal de vídeo, mientras que el tiempo de espera es de solo 200 ms. Esto da como resultado un mensaje de error del kernel. Aumente el tiempo de espera a 1 segundo. A continuación se muestra un ejemplo del mensaje de error. [ 697.084433] ------------[ cortar aquí ]------------ [ 697.091115] ast 0000:02:00.0: [drm] drm_WARN_ON(!__ast_dp_wait_enable(ast, enabled)) [ 697.091233] ADVERTENCIA: CPU: 1 PID: 160 en drivers/gpu/drm/ast/ast_dp.c:232 ast_dp_set_enable+0x123/0x140 [ast] [...] [ 697.272469] RIP: 0010:ast_dp_set_enable+0x123/0x140 [ast] [...] [ 697.415283] Seguimiento de llamadas: [ 697.420727] [ __warn.cold+0xaf/0xca [ 697.464713] ? ast_dp_set_enable+0x123/0x140 [ast] [ 697.472633] ? report_bug+0x134/0x1d0 [ 697.479544] ? handle_bug+0x58/0x90 [ 697.486127] ? exc_invalid_op+0x13/0x40 [ 697.492975] ? asm_exc_invalid_op+0x16/0x20 [ 697.500224] ? preempt_count_sub+0x14/0xc0 [ 697.507473] ? ast_dp_set_enable+0x123/0x140 [ast] [ 697.515377] ? ast_dp_set_enable+0x123/0x140 [ast] [ 697.523227] drm_atomic_helper_commit_modeset_enables+0x30a/0x470 [ 697.532388] drm_atomic_helper_commit_tail+0x58/0x90 [ 697.540400] ast_mode_config_helper_atomic_commit_tail+0x30/0x40 [ast] [ 697.550009] commit_tail+0xfe/0x1d0 [ 697.556547] drm_atomic_helper_commit+0x198/0x1c0 Este es un problema cosmético. La habilitación de la señal de video aún funciona incluso con el mensaje de error. El problema siempre ha estado presente, pero solo las versiones recientes del controlador ast advierten sobre la pérdida del tiempo de espera.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21750)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: brcmfmac: comprobar el valor de retorno de of_property_read_string_index() En algún momento entre 6.10 y 6.11, el controlador comenzó a fallar en mi MacBookPro14,3. La propiedad no existe y 'tmp' permanece sin inicializar, por lo que pasamos un puntero aleatorio a devm_kstrdup(). El fallo que estoy teniendo se parece a esto: ERROR: no se puede manejar el error de página para la dirección: 00007f033c669379 PF: acceso de lectura del supervisor en modo kernel PF: error_code(0x0001) - violación de permisos PGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025 Oops: Oops: 0001 [#1] SMP PTI CPU: 4 UID: 0 PID: 827 Comm: (udev-worker) No contaminado 6.11.8-gentoo #1 Nombre del hardware: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 23/06/2024 RIP: 0010:strlen+0x4/0x30 Código: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc RSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202 RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001 RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379 RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a R10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8 R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30 FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ? __die+0x23/0x70 ? page_fault_oops+0x149/0x4c0 ? raw_spin_rq_lock_nested+0xe/0x20 ? sched_balance_newidle+0x22b/0x3c0 ? update_load_avg+0x78/0x770 ? exc_page_fault+0x6f/0x150 ? asm_exc_page_fault+0x26/0x30 ? __pfx_pci_conf1_write+0x10/0x10 ? strlen+0x4/0x30 devm_kstrdup+0x25/0x70 brcmf_of_probe+0x273/0x350 [brcmfmac]
  • Vulnerabilidad en kernel de Linux (CVE-2025-21752)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no use btrfs_set_item_key_safe en extensiones de bandas RAID No use btrfs_set_item_key_safe() para modificar las claves en el árbol de bandas RAID, ya que esto puede provocar la corrupción del árbol, lo que es detectado por las comprobaciones en btrfs_set_item_key_safe(): Información de BTRFS (dispositivo nvme1n1): leaf 49168384 gen 15 total ptrs 194 free space 8329 owner 12 Información de BTRFS (dispositivo nvme1n1): refs 2 lock_owner 1030 current 1030 [ snip ] item 105 key (354549760 230 20480) itemoff 14587 itemsize 16 stride 0 devid 5 physical 67502080 elemento 106 clave (354631680 230 4096) itemoff 14571 tamaño del elemento 16 paso 0 devid 1 físico 88559616 elemento 107 clave (354631680 230 32768) itemoff 14555 tamaño del elemento 16 paso 0 devid 1 físico 88555520 elemento 108 clave (354717696 230 28672) itemoff 14539 tamaño del elemento 16 paso 0 devid 2 físico 67604480 [ snip ] BTRFS crítico (dispositivo nvme1n1): ranura 106 clave (354631680 230 32768) nueva clave (354635776 230 4096) ------------[ cortar aquí ]------------ ¡ERROR del kernel en fs/btrfs/ctree.c:2602! Oops: código de operación no válido: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 1055 Comm: fsstress No contaminado 6.13.0-rc1+ #1464 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 01/04/2014 RIP: 0010:btrfs_set_item_key_safe+0xf7/0x270 Código: RSP: 0018:ffffc90001337ab0 EFLAGS: 00010287 RAX: 000000000000000 RBX: ffff8881115fd000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 000000000000001 RDI: 000000000ffffffff RBP: ffff888110ed6f50 R08: 00000000ffffefff R09: ffffffff8244c500 R10: 00000000ffffefff R11: 00000000ffffffff R12: ffff888100586000 R13: 00000000000000c9 R14: ffffc90001337b1f R15: ffff888110f23b58 FS: 00007f7d75c72740(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa811652c60 CR3: 0000000111398001 CR4: 0000000000370eb0 Seguimiento de llamadas: ? __die_body.cold+0x14/0x1a ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? btrfs_set_item_key_safe+0xf7/0x270 ? exc_invalid_op+0x50/0x70 ? btrfs_set_item_key_safe+0xf7/0x270 ? asm_exc_invalid_op+0x1a/0x20 ? btrfs_set_item_key_safe+0xf7/0x270 btrfs_partially_delete_raid_extent+0xc4/0xe0 btrfs_delete_raid_extent+0x227/0x240 __btrfs_free_extent.isra.0+0x57f/0x9c0 ? exc_coproc_segment_overrun+0x40/0x40 __btrfs_run_delayed_refs+0x2fa/0xe80 btrfs_run_delayed_refs+0x81/0xe0 btrfs_commit_transaction+0x2dd/0xbe0 ? preempt_count_add+0x52/0xb0 btrfs_sync_file+0x375/0x4c0 do_fsync+0x39/0x70 __x64_sys_fsync+0x13/0x20 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f7d7550ef90 Código: RSP: 002b:00007ffd70237248 EFLAGS: 00000202 ORIG_RAX: 000000000000004a RAX: ffffffffffffffda RBX: 000000000000004 RCX: 00007f7d7550ef90 RDX: 000000000000013a RSI: 000000000040eb28 RDI: 0000000000000004 RBP: 000000000000001b R08: 0000000000000078 R09: 00007ffd7023725c R10: 00007f7d75400390 R11: 0000000000000202 R12: 028f5c28f5c28f5c R13: 8f5c28f5c28f5c29 R14: 000000000040b520 R15: 00007f7d75c726c8 Si bien la causa raíz de la corrupción del orden del árbol no está clara, usar btrfs_duplicate_item() para copiar el elemento y luego ajustar tanto la clave como las direcciones físicas por dispositivo es una forma segura de contrarrestar este problema.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21754)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige el error de aserción al dividir la extensión ordenada después de la interrupción de la transacción Si mientras estamos realizando una escritura de E/S directa ocurre una interrupción de la transacción, marcamos todas las extensiones ordenadas existentes con el indicador BTRFS_ORDERED_IOERR (hecho en btrfs_destroy_ordered_extents()), y luego de eso si ingresamos btrfs_split_ordered_extent() y la extensión ordenada tiene bytes restantes (lo que significa que tenemos una biografía que no cubre toda la extensión ordenada, vea los detalles en btrfs_extract_ordered_extent()), fallaremos en la siguiente aserción en btrfs_split_ordered_extent(): ASSERT(!(flags & ~BTRFS_ORDERED_TYPE_FLAGS)); porque el indicador BTRFS_ORDERED_IOERR está configurado y la definición de BTRFS_ORDERED_TYPE_FLAGS es solo la unión de todos los indicadores que identifican el tipo de escritura (regular, nocow, prealloc, comprimido, E/S directa, codificado). Solucione esto devolviendo un error de btrfs_extract_ordered_extent() si encontramos el indicador BTRFS_ORDERED_IOERR en la extensión ordenada. El error será el error que resultó en la interrupción de la transacción o -EIO si no ocurrió ninguna interrupción de la transacción. Esto fue informado recientemente por syzbot con el siguiente seguimiento: FAULT_INJECTION: forzando una falla. nombre failslab, intervalo 1, probabilidad 0, espacio 0, multiplicado por 1 CPU: 0 UID: 0 PID: 5321 Comm: syz.0.0 No contaminado 6.13.0-rc5-syzkaller #0 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 fail_dump lib/fault-inject.c:53 [en línea] should_fail_ex+0x3b0/0x4e0 lib/fault-inject.c:154 should_failslab+0xac/0x100 mm/failslab.c:46 slab_pre_alloc_hook mm/slub.c:4072 [en línea] slab_alloc_node mm/slub.c:4148 [en línea] __do_kmalloc_node mm/slub.c:4297 [en línea] __kmalloc_noprof+0xdd/0x4c0 mm/slub.c:4310 kmalloc_noprof include/linux/slab.h:905 [en línea] kzalloc_noprof include/linux/slab.h:1037 [en línea] btrfs_chunk_alloc_add_chunk_item+0x244/0x1100 fs/btrfs/volumes.c:5742 reserve_chunk_space+0x1ca/0x2c0 fs/btrfs/block-group.c:4292 check_system_chunk fs/btrfs/block-group.c:4319 [en línea] do_chunk_alloc fs/btrfs/block-group.c:3891 [en línea] btrfs_chunk_alloc+0x77b/0xf80 fs/btrfs/block-group.c:4187 find_free_extent_update_loop fs/btrfs/extent-tree.c:4166 [en línea] find_free_extent+0x42d1/0x5810 fs/btrfs/extent-tree.c:4579 btrfs_reserve_extent+0x422/0x810 fs/btrfs/extent-tree.c:4672 btrfs_new_extent_direct fs/btrfs/direct-io.c:186 [en línea] btrfs_get_blocks_direct_write+0x706/0xfa0 fs/btrfs/direct-io.c:321 btrfs_dio_iomap_begin+0xbb7/0x1180 fs/btrfs/direct-io.c:525 iomap_iter+0x697/0xf60 fs/iomap/iter.c:90 __iomap_dio_rw+0xeb9/0x25b0 fs/iomap/direct-io.c:702 btrfs_dio_write fs/btrfs/direct-io.c:775 [en línea] btrfs_direct_write+0x610/0xa30 fs/btrfs/direct-io.c:880 btrfs_do_write_iter+0x2a0/0x760 fs/btrfs/file.c:1397 do_iter_readv_writev+0x600/0x880 vfs_writev+0x376/0xba0 fs/read_write.c:1050 do_pwritev fs/read_write.c:1146 [en línea] __do_sys_pwritev2 fs/read_write.c:1204 [en línea] __se_sys_pwritev2+0x196/0x2b0 fs/read_write.c:1195 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1281f85d29 RSP: 002b:00007f12819fe038 EFLAGS: 00000246 ORIG_RAX: 0000000000000148 RAX: ffffffffffffffda RBX: 00007f1282176080 RCX: 00007f1281f85d29 RDX: 0000000000000001 RSI: 0000000020000240 RDI: 00000000000000005 RBP: 00007f12819fe090 R08: 0000000000000000 R09: 0000000000000003 R10: 0000000000007000 R11: 0000000000000246 R12: 0000000000000002 R13: 0000000000000000 R14: 00007f1282176080 R15: 00007ffcb9e23328 Error BTRFS (estado A del bucle 0 del dispositivo): transacción abortada (error -12) BTRFS: ---truncado---
  • CVE-2025-21758
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: mcast: agregar protección RCU a mld_newpack() mld_newpack() se puede llamar sin que se mantenga RTNL o RCU. Tenga en cuenta que ya no podemos usar sock_alloc_send_skb() porque ipv6.igmp_sk usa asignaciones GFP_KERNEL que pueden dormir. En su lugar, use alloc_skb() y cargue el socket net->ipv6.igmp_sk bajo la protección RCU.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21765)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: usar protección RCU en ip6_default_advmss() ip6_default_advmss() necesita protección RCU para asegurarse de que la estructura de red que lee no desaparezca.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21766)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv4: usar protección RCU en __ip_rt_update_pmtu() __ip_rt_update_pmtu() debe usar protección RCU para asegurarse de que la estructura de red que lee no desaparezca.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21767)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clocksource: Use migrants_disable() para evitar llamar a get_random_u32() en un contexto atómico El siguiente informe de error ocurrió con un kernel PREEMPT_RT: ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog preempt_count: 1, expected: 0 Profundidad de anidamiento de RCU: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0x6b/0x330 clocksource_watchdog_kthread+0x193/0x1a0 Esto se debe al hecho de que clocksource_verify_choose_cpus() se invoca con la preempción deshabilitada. Esta función invoca get_random_u32() para obtener números aleatorios para elegir las CPU. El bloqueo local batched_entropy_32 y/o el spinlock base_crng.lock en driver/char/random.c se adquirirán durante la llamada. En el kernel PREEMPT_RT, ambos son bloqueos inactivos y, por lo tanto, no se pueden adquirir en un contexto atómico. Solucione este problema utilizando migrants_disable() para permitir que smp_processor_id() se utilice de manera confiable sin introducir un contexto atómico. Luego, se llama a preempt_disable() después de clocksource_verify_choose_cpus() pero antes de que se ejecute la medición de la fuente de reloj para evitar introducir una latencia inesperada.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21768)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ipv6: arreglo de bucles de referencia dst en lwtunnels rpl, seg6 y ioam6 Algunos lwtunnels tienen una caché dst para dst posterior a la transformación. Si el destino del paquete no cambió, podemos terminar registrando una referencia al lwtunnel en su propia caché, y el estado del lwtunnel nunca se liberará. Descubierto por la prueba ioam6.sh, kmemleak se corrigió recientemente para detectar fugas de memoria por CPU. No estoy seguro de si rpl y seg6 realmente pueden alcanzar esto, pero en principio no veo por qué no.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21771)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched_ext: Se corrige la detección incorrecta de la migración de autogrupos. scx_move_task() se llama desde sched_move_task() y le dice al programador BPF que se está confirmando la migración de cgroup. sched_move_task() se usa tanto en las migraciones de cgroup como de autogrupos y scx_move_task() intentó filtrar las migraciones de autogrupos probando el cgroup de destino y PF_EXITING, pero esto no es suficiente. De hecho, sin etiquetar explícitamente el hilo que está realizando la migración de cgroup, no hay una buena manera de diferenciar las invocaciones de scx_move_task() para la migración de ejecución al cgroup raíz y una migración de autogrupo. Esto provocó que scx_move_task() ignorara incorrectamente una migración desde un cgroup no raíz a un autogrupo del cgroup raíz, lo que activaba la siguiente advertencia: ADVERTENCIA: CPU: 7 PID: 1 en kernel/sched/ext.c:3725 scx_cgroup_can_attach+0x196/0x340 ... Seguimiento de llamadas: cgroup_migrate_execute+0x5b1/0x700 cgroup_attach_task+0x296/0x400 __cgroup_procs_write+0x128/0x140 cgroup_procs_write+0x17/0x30 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x31d/0x4a0 __x64_sys_write+0x72/0xf0 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e Solucione el problema agregando un argumento a sched_move_task() que indique si el movimiento es para una migración de cgroup o de autogroup. Después del cambio, se llama a scx_move_task() solo para migraciones de cgroup y se le cambia el nombre a scx_cgroup_move_task().
  • Vulnerabilidad en kernel de Linux (CVE-2025-21772)
    Severidad: ALTA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: particiones: mac: se corrige el manejo de la tabla de particiones falsa Corrige varios problemas en el sondeo de particiones: - El rescate para un partoffset incorrecto debe usar put_dev_sector(), ya que el read_part_sector() anterior tuvo éxito. - Si la tabla de particiones reclama un tamaño de sector tonto como 0xfff bytes (lo que da como resultado que las entradas de la tabla de particiones se extiendan a ambos lados de los límites del sector), salga en lugar de acceder a la memoria fuera de los límites. - No debemos asumir que la tabla de particiones contiene la terminación NUL adecuada: use strnlen() y strncmp() en lugar de strlen() y strcmp().
  • Vulnerabilidad en kernel de Linux (CVE-2025-21777)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ring-buffer: validar la matriz de subbuf de metadatos persistentes Los metadatos de un búfer de anillo asignado contienen una matriz de índices de todos los subbúferes. La primera entrada es la página del lector y el resto de las entradas establecen el orden de los subbúferes en cómo se creará la lista de enlaces del búfer de anillo. El validador actualmente se asegura de que todas las entradas estén dentro del rango de 0 y nr_subbufs. Pero no verifica si hay duplicados. Mientras trabajaba en el búfer de anillo, corrompí esta matriz, donde agregué duplicados. El validador no lo detectó y creó la lista de enlaces del búfer de anillo encima. Afortunadamente, la corrupción fue solo que la página del lector también estaba en la ruta del escritor y solo presentó datos corruptos pero no bloqueó el kernel. Pero si había duplicados en el lado del escritor, entonces podría corromper la lista de enlaces del búfer de anillo y causar un bloqueo. Cree una matriz de máscara de bits con el tamaño del número de subbúferes. Luego, bórrelo. Al recorrer la matriz subbuf para verificar si las entradas están dentro del rango, verifique si su bit ya está configurado en subbuf_mask. Si es así, entonces hay duplicados y falla la validación. Si no es así, configure el bit correspondiente y continúe.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21778)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing: No permitir mmap() de búfer de anillo persistente Al intentar mmap un búfer de instancia de seguimiento que está adjunto a reserve_mem, se bloquearía: BUG: no se puede manejar el error de página para la dirección: ffffe97bd00025c8 #PF: acceso de lectura de supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 2862f3067 P4D 2862f3067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT_RT SMP PTI CPU: 4 UID: 0 PID: 981 Comm: mmap-rb No contaminado 6.14.0-rc2-test-00003-g7f1a5e3fbf9e-dirty #233 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 RIP: 0010:validate_page_before_insert+0x5/0xb0 Código: e2 01 89 d0 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 <48> 8b 46 08 a8 01 75 67 66 90 48 89 f0 8b 50 34 85 d2 74 76 48 89 RSP: 0018:ffffb148c2f3f968 EFLAGS: 00010246 RAX: ffff9fa5d3322000 RBX: ffff9fa5ccff9c08 RCX: 00000000b879ed29 RDX: ffffe97bd00025c0 RSI: ffffe97bd00025c0 RDI: ffff9fa5ccff9c08 RBP: ffffb148c2f3f9f0 R08: 000000000000004 R09: 0000000000000004 R10: 0000000000000000 R11: 0000000000000200 R12: 0000000000000000 R13: 00007f16a18d5000 R14: ffff9fa5c48db6a8 R15: 0000000000000000 FS: 00007f16a1b54740(0000) GS:ffff9fa73df00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 CR2: ffffe97bd00025c8 CR3: 00000001048c6006 CR4: 0000000000172ef0 Seguimiento de llamadas: ? __die_body.cold+0x19/0x1f ? __die+0x2e/0x40 ? page_fault_oops+0x157/0x2b0 ? search_module_extables+0x53/0x80 ? validation_page_before_insert+0x5/0xb0 ? kernelmode_fixup_or_oops.isra.0+0x5f/0x70 ? __bad_area_nosemaphore+0x16e/0x1b0 ? bad_area_nosemaphore+0x16/0x20 ? do_kern_addr_fault+0x77/0x90 ? exc_page_fault+0x22b/0x230 ? asm_exc_page_fault+0x2b/0x30 ? validate_page_before_insert+0x5/0xb0 ? vm_insert_pages+0x151/0x400 __rb_map_vma+0x21f/0x3f0 ring_buffer_map+0x21b/0x2f0 tracing_buffers_mmap+0x70/0xd0 __mmap_region+0x6f0/0xbd0 mmap_region+0x7f/0x130 do_mmap+0x475/0x610 vm_mmap_pgoff+0xf2/0x1d0 ksys_mmap_pgoff+0x166/0x200 __x64_sys_mmap+0x37/0x50 x64_sys_call+0x1670/0x1d70 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f La razón fue que el código que asigna las páginas del búfer de anillo al espacio de usuario tiene: page = virt_to_page((void *)cpu_buffer->subbuf_ids[s]); Y lo usa en: vm_insert_pages(vma, vma->vm_start, pages, &nr_pages); Pero virt_to_page() no funciona con la memoria vmap() que es la que tiene el búfer de anillo persistente. Es bastante trivial permitir esto, pero por ahora simplemente deshabilite mmap() de las instancias que tienen su búfer de anillo desde la opción reserve_mem. Si se realiza un mmap() en un búfer persistente, devolverá -ENODEV tal como lo haría si el campo .mmap no estuviera definido en la estructura file_operations.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21781)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: batman-adv: se corrige el pánico durante la eliminación de la interfaz. El recuento de referencias se utiliza para garantizar que batadv_hardif_neigh_node y batadv_hard_iface no se liberen antes o durante la finalización del trabajo de batadv_v_elp_throughput_metric_update. Pero no hay garantía de que el if duro permanezca asociado con una interfaz blanda hasta que finalice el trabajo. Esto corrige un fallo provocado por el reinicio que se parece a esto: Seguimiento de llamada: batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20 (la llamada batadv_v_mesh_free es engañosa y en realidad no sucede) Pude hacer que el problema sucediera de manera más confiable al cambiar hardif_neigh->bat_v.metric_work work para que sea delayed work. Esto me permitió rastrear y confirmar la solución. [sven@narfation.org: evitar ingresar batadv_v_elp_get_throughput sin soft_iface]
  • Vulnerabilidad en kernel de Linux (CVE-2025-21784)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: se bloquea cuando no se puede cargar el firmware en psp_init_cap_microcode() En la función psp_init_cap_microcode(), debería bloquearse cuando no se puede cargar el firmware; de lo contrario, puede provocar un acceso no válido a la memoria.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21795)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: se corrige el bloqueo en nfsd4_shutdown_callback Si nfs4_client está en estado de cortesía, no tiene sentido enviar la devolución de llamada. Esto hace que nfsd4_shutdown_callback se bloquee ya que cl_cb_inflight no es 0. Este bloqueo dura unos 15 minutos hasta que TCP notifica a NFSD que se interrumpió la conexión. Este parche modifica nfsd4_run_cb_work para omitir la llamada RPC si nfs4_client está en estado de cortesía.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21799)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: ti: am65-cpsw: arreglo de liberación de IRQ en am65_cpsw_nuss_remove_tx_chns() Al obtener la IRQ, usamos k3_udma_glue_tx_get_irq() que devuelve un valor de error negativo en caso de error. Por lo tanto, la comprobación de que no sea NULL no es suficiente para determinar si la IRQ es válida. Compruebe que la IRQ sea mayor que cero para asegurarse de que sea válida. No hay ningún problema en el momento de la prueba, pero en el momento de la ejecución, el usuario puede invocar .set_channels, lo que da como resultado la siguiente cadena de llamadas. am65_cpsw_set_channels() am65_cpsw_nuss_update_tx_rx_chns() am65_cpsw_nuss_remove_tx_chns() am65_cpsw_nuss_init_tx_chns() En este punto, si am65_cpsw_nuss_init_tx_chns() falla debido a k3_udma_glue_tx_get_irq(), tx_chn->irq se establecerá en un valor negativo. Luego, en los .set_channels posteriores con un mayor conteo de canales, intentaremos liberar una IRQ no válida en am65_cpsw_nuss_remove_tx_chns(), lo que generará una advertencia del kernel. El problema está presente en el commit original que introdujo este controlador, aunque allí, am65_cpsw_nuss_update_tx_rx_chns() existía como am65_cpsw_nuss_update_tx_chns().
  • Vulnerabilidad en kernel de Linux (CVE-2024-58092)
    Severidad: MEDIA
    Fecha de publicación: 16/04/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: corrección de la inicialización del seguimiento de clientes heredados. Se ha eliminado la llamada a nfsd4_legacy_tracking_ops->init() en check_for_legacy_methods(). Esto se gestionará en el llamador (nfsd4_client_tracking_init()). De lo contrario, se llamaría a nfsd4_legacy_tracking_ops->init() dos veces, y la segunda vez se activaría BUG_ON() en nfsd4_init_recdir().
  • Vulnerabilidad en kernel de Linux (CVE-2025-22019)
    Severidad: MEDIA
    Fecha de publicación: 16/04/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcachefs: bch2_ioctl_subvolume_destroy() corrige el bloqueo de bch2_evict_subvolume_inodes() debido a una poda incorrecta de dcache. También se corrigen las comprobaciones de permisos que faltaban.
  • Vulnerabilidad en kernel de Linux (CVE-2025-22021)
    Severidad: MEDIA
    Fecha de publicación: 16/04/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: socket: Lookup orig tuple for IPv6 SNAT nf_sk_lookup_slow_v4 realiza la búsqueda conntrack de paquetes IPv4 para restaurar la 5-tupla original en caso de SNAT, para poder encontrar el socket correcto (si lo hay). Entonces socket_match() puede verificar correctamente si el socket era transparente. Sin embargo, la contraparte IPv6 (nf_sk_lookup_slow_v6) carece de esta búsqueda conntrack, lo que hace que xt_socket no coincida en el socket cuando el paquete fue SNATed. Agregue la misma lógica a nf_sk_lookup_slow_v6. SNAT IPv6 se usa en clústeres de Kubernetes para paquetes pod-to-world, ya que las direcciones de los pods están en la subred fd00::/8 ULA y deben reemplazarse con la dirección externa del nodo. Cilium utiliza Envoy para implementar políticas L7, y Envoy utiliza sockets transparentes. Cilium inserta una regla de preenrutamiento de iptables que coincide con `-m socket --transparent` y redirige los paquetes a localhost, pero no coincide con los paquetes IPv6 SNAT debido a la falta de búsqueda de conntrack.
  • Vulnerabilidad en kernel de Linux (CVE-2025-22022)
    Severidad: ALTA
    Fecha de publicación: 16/04/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: xhci: Aplicar la peculiaridad de la cadena de enlace en los endpoints isoc de NEC Se observó que dos ejemplares claramente diferentes de NEC uPD720200 (uno con un error de inicio/detención y otro sin él) causaban fallas de IOMMU después de algunos errores de servicio perdido. La dirección con fallas se encuentra inmediatamente después de un segmento de anillo de transferencia y los mensajes de depuración dinámica parcheados revelaron que se recibió el MSE cuando se esperaba un TD cerca del final de ese segmento: [1.041954] xhci_hcd: Error de intervalo de servicio faltante para la ranura 1 ep 2 se esperaba TD DMA ffa08fe0 [1.042120] xhci_hcd: AMD-Vi: Evento registrado [IO_PAGE_FAULT dominio=0x0005 dirección=0xffa09000 indicadores=0x0000] [1.042146] xhci_hcd: AMD-Vi: Evento registrado [IO_PAGE_FAULT dominio=0x0005 dirección=0xffa09040 indicadores=0x0000] Se vuelve aún más divertido si la siguiente página es un segmento de anillo accesible para el HC. A continuación, informa MSE en el segmento en ff1e8000, recorre una página llena de ceros en ff1e9000 y comienza a informar eventos para TRB en la página en ff1ea000 cada microtrama, en lugar de saltar al segmento ff1e6000. [7.041671] xhci_hcd: Error de intervalo de servicio perdido para la ranura 1 ep 2 esperada TD DMA ff1e8fe0 [7.041999] xhci_hcd: Error de intervalo de servicio perdido para la ranura 1 ep 2 esperada TD DMA ff1e8fe0 [7.042011] xhci_hcd: ADVERTENCIA: evento de desbordamiento de búfer para la ranura 1 ep 2 en el endpoint [7.042028] xhci_hcd: Se omitieron todos los TD para la ranura 1 ep 2. Borrar el indicador de omisión. [ 7.042134] xhci_hcd: ADVERTENCIA: evento de desbordamiento de búfer para la ranura 1 ep 2 en el endpoint [ 7.042138] xhci_hcd: ERROR Evento de transferencia TRB DMA ptr no forma parte del TD actual ep_index 2 comp_code 31 [ 7.042144] xhci_hcd: Buscando evento-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhci_hcd: ADVERTENCIA: evento de desbordamiento de búfer para la ranura 1 ep 2 en el endpoint [ 7.042262] xhci_hcd: ERROR Evento de transferencia TRB DMA ptr no forma parte del TD actual ep_index 2 comp_code 31 [ 7.042266] xhci_hcd: Buscando evento-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 En algún punto, los eventos de finalización cambian de Desbordamiento de búfer de isocrono a Paquete corto y el HC finalmente encuentra una falta de coincidencia de bits de ciclo en ff1ec000. [ 7.098130] xhci_hcd: ERROR El punto de transferencia TRB DMA del evento no forma parte del TD actual ep_index 2 comp_code 13 [ 7.098132] xhci_hcd: Buscando el punto de transferencia event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhci_hcd: ERROR El punto de transferencia TRB DMA del evento no forma parte del TD actual ep_index 2 comp_code 13 [ 7.098256] xhci_hcd: Buscando el punto de transferencia event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [7.098379] xhci_hcd: Evento de saturación en la ranura 1, episodio 2. Es posible que los datos del dispositivo isócrono se escribieran en búferes aleatorios de TD pendientes en otros endpoints (de entrada o de salida), otros dispositivos o incluso otros HC en el mismo dominio IOMMU. Por último, se produjo un error de un dispositivo USB diferente en otro HC. ¿Fue causado por lo anterior? No lo sé, pero podría haber sido. El disco funcionaba sin problemas y generó tráfico PCIe que privó al NEC de BW ascendente y activó esos MSE. Los dos HC compartían una ranura x1 mediante una placa divisora PCIe comercial. [ 7.162604] usb 10-2: restablecer el dispositivo USB SuperSpeed número 3 usando xhci_hcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Resultado: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] Error de E/S, dev sdb, sector 67284480 op 0x0:(READ) ---truncated---
  • Vulnerabilidad en kernel de Linux (CVE-2025-22023)
    Severidad: ALTA
    Fecha de publicación: 16/04/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: xhci: Don't skip on Stopped - Length Invalid Hasta el commit d56b0b2ab142 ("usb: xhci: ensure skipped isoc TDs are returns when is stopped ring") en v6.11, el controlador no omitía los TD isócronos omitidos al gestionar los eventos Stoppend y Stopped - Length Invalid. En su lugar, borraba erróneamente el indicador de omisión, lo que provocaría que el anillo se atascara, ya que los eventos futuros no coincidirán con el TD omitido, que nunca se elimina de la cola hasta que se cancela. Esta lógica defectuosa parece haber estado en su lugar sustancialmente sin cambios desde la serie 3.x hace más de 10 años, lo que probablemente habla en primer lugar sobre la relativa rareza de este caso en el uso normal, pero por la especificación no veo razón por la que no debería ser posible. Después de d56b0b2ab142, los TD se omiten inmediatamente al gestionar los eventos "Detenidos". Esto plantea un problema potencial en caso de "Detenido - Longitud Inválida", que ocurre en TD completados (probablemente ya devueltos) o en TRB de Enlace y No-Op. Este evento no se reconocerá como coincidente con ningún TD (a menos que se trate del inusual TRB de Enlace dentro de un TD) y provocará la omisión de todos los TD pendientes, devolviéndolos posiblemente antes de que finalicen, con el riesgo de pérdida de datos de isoc y posiblemente un fallo de hardware no operativo (UAF). Como solución intermedia, no omita ni borre el indicador de omisión en este tipo de evento. De este modo, el siguiente evento omitirá los TD omitidos. Una desventaja de no gestionar "Detenido - Longitud Inválida" en un Enlace dentro de un TD es que, si el TD se cancela, su longitud real no se actualizará para tener en cuenta los TRB completados (silenciosamente) antes de que se detuviera el TD. No tuve éxito en generar esta secuencia de eventos de finalización, por lo que no hay una demostración convincente de ningún desastre resultante. Puede ser una condición muy rara y desconocida. La única motivación para este parche es que, si ocurre un evento tan improbable, prefiero arriesgarme a reportar un marco isoc cancelado parcialmente completado como vacío que arriesgarme con UAF. Esto se solucionará mejor analizando el puntero TRB del evento detenido al tomar decisiones de omisión, pero es poco probable que esta modificación se incorpore a la versión 6.12, que se mantendrá vigente durante algunos años.
  • Vulnerabilidad en Oracle VM VirtualBox de Oracle Virtualization (CVE-2025-30712)
    Severidad: ALTA
    Fecha de publicación: 15/04/2025
    Fecha de última actualización: 28/10/2025
    Vulnerabilidad en el producto Oracle VM VirtualBox de Oracle Virtualization (componente: Core). La versión compatible afectada es la 7.1.6. Esta vulnerabilidad, fácilmente explotable, permite a un atacante con privilegios elevados, con acceso a la infraestructura donde se ejecuta Oracle VM VirtualBox, comprometer Oracle VM VirtualBox. Si bien la vulnerabilidad se encuentra en Oracle VM VirtualBox, los ataques pueden afectar significativamente a otros productos (cambio de alcance). Los ataques exitosos de esta vulnerabilidad pueden resultar en la creación, eliminación o modificación no autorizada de datos críticos o de todos los datos accesibles de Oracle VM VirtualBox, así como en el acceso no autorizado a datos críticos o a todos los datos accesibles de Oracle VM VirtualBox, y en la posibilidad no autorizada de provocar una denegación de servicio parcial (DOS parcial) de Oracle VM VirtualBox. Puntuación base de CVSS 3.1: 8.1 (Afecta a la confidencialidad, integridad y disponibilidad). Vector CVSS: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:L).
  • Vulnerabilidad en kernel de Linux (CVE-2023-53034)
    Severidad: ALTA
    Fecha de publicación: 16/04/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ntb_hw_switchtec: Se corrige el desplazamiento fuera de los límites en switchtec_ntb_mw_set_trans. Existe una API del kernel ntb_mw_clear_trans() que pasaría 0 tanto a addr como a size. Esto haría que xlate_pos fuera negativo. [ 23.734156] switchtec switchtec0: MW 0: parte 0 addr 0x0000000000000000 tamaño 0x0000000000000000 [ 23.734158] ======================================================================================== [ 23.734172] UBSAN: desplazamiento fuera de los límites en drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7 [ 23.734418] el exponente de desplazamiento -1 es negativo. Se garantiza que xlate_pos sea positivo o cero antes de BIT.
  • Vulnerabilidad en kernel de Linux (CVE-2024-58093)
    Severidad: ALTA
    Fecha de publicación: 16/04/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI/ASPM: Corrección de la salida del estado del enlace durante la eliminación de la función ascendente del conmutador. Antes de la versión 456d8aa37d0f ("PCI/ASPM: Deshabilitar ASPM al eliminar la función MFD para evitar el use-after-free"), liberábamos el enlace ASPM solo después de eliminar la última función del bus correspondiente al enlace en cuestión. Era demasiado tarde. Si la función 0 se elimina antes que la función hermana, enlace->descendente apuntaría a la memoria liberada después. Tras el cambio mencionado, liberábamos el estado del enlace principal ASPM al eliminar cualquier función del bus correspondiente a un enlace determinado. Era demasiado pronto. Si el enlace es a un conmutador PCIe con MFD en el puerto ascendente, eliminar primero las funciones distintas de la 0 liberaría un enlace que aún permanece como parent_link para los puertos descendentes restantes. Los GPF resultantes son especialmente frecuentes durante la desconexión en caliente, ya que pciehp elimina los dispositivos del bus de enlace en orden inverso. En ese conmutador, la función 0 es el puente P2P virtual al bus interno. Se libera exactamente cuando se elimina la función 0: antes de que el enlace principal quede obsoleto, pero después de que todos los enlaces subordinados desaparezcan. [kwilczynski: registro de confirmaciones]
  • Vulnerabilidad en kernel de Linux (CVE-2024-58094)
    Severidad: MEDIA
    Fecha de publicación: 16/04/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: añadir comprobación de solo lectura antes del truncamiento en jfs_truncate_nolock(). Se añadió una comprobación para el modo de "solo lectura" en la función `jfs_truncate_nolock` para evitar errores relacionados con la escritura en un sistema de archivos de solo lectura. Pila de llamadas: block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL) Si se activa la condición `isReadOnly(ip)` en `jfs_truncate_nolock`, la ejecución de la función se detendrá y no se realizarán más modificaciones de datos. En su lugar, se llamará a la función `xtTruncate` con el indicador "COMMIT_WMAP", lo que impide las modificaciones en modo de "solo lectura".
  • Vulnerabilidad en kernel de Linux (CVE-2024-58095)
    Severidad: MEDIA
    Fecha de publicación: 16/04/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: añadir comprobación de solo lectura antes de llamar a txBeginAnon(). Se añadió una comprobación de solo lectura antes de llamar a `txBeginAnon` en `extAlloc` y `extRecord`. Esto impide intentos de modificación en un sistema de archivos montado de solo lectura, lo que evita posibles errores o bloqueos. Rastreo de llamadas: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [en línea] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299
  • Vulnerabilidad en kernel de Linux (CVE-2024-58096)
    Severidad: MEDIA
    Fecha de publicación: 16/04/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath11k: añadir srng->lock para ath11k_hal_srng_* en modo monitor. ath11k_hal_srng_* debe usarse con srng->lock para proteger los datos de srng. Para ath11k_dp_rx_mon_dest_process() y ath11k_dp_full_mon_process_rx(), usan ath11k_hal_srng_* repetidamente, pero nunca llaman a srng->lock. Por lo tanto, al ejecutar el modo monitor (completo), se mostrará la advertencia: RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] Seguimiento de llamadas: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319 Por lo tanto, agregue srng->lock para evitar estas advertencias. Para obtener srng->lock, debe cambiar la definición de srng de 'void' a 'struct hal_srng'. Inicialícelos en otro lugar para evitar que una línea de código sea demasiado larga. Esto es coherente con otras funciones de proceso de anillo, como ath11k_dp_process_rx(). Probado en: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Probado en: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
  • Vulnerabilidad en kernel de Linux (CVE-2025-22025)
    Severidad: MEDIA
    Fecha de publicación: 16/04/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: poner dl_stid si no se puede poner en cola dl_recall. Antes de llamar a nfsd4_run_cb para poner en cola dl_recall en callback_wq, incrementamos el recuento de referencia de dl_stid. Esperamos que, tras procesar el work_struct correspondiente, el recuento de referencia de dl_stid se reduzca mediante la función de devolución de llamada nfsd4_cb_recall_release. Sin embargo, si falla la llamada a nfsd4_run_cb, el recuento de referencia incrementado de dl_stid no se reducirá correspondientemente, lo que provocará la siguiente pérdida de nfs4_stid: objeto sin referencia 0xffff88812067b578 (tamaño 344): comm "nfsd", pid 2761, jiffies 4295044002 (edad 5541.241s) volcado hexadecimal (primeros 32 bytes): 01 00 00 00 6b 6b 6b 6b b8 02 c0 e2 81 88 ff ff ....kkkk........ 00 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .kkkkkkk.....N.. seguimiento inverso: kmem_cache_alloc+0x4b9/0x700 nfsd4_process_open1+0x34/0x300 nfsd4_open+0x2d1/0x9d0 nfsd4_proc_compound+0x7a2/0xe30 nfsd_dispatch+0x241/0x3e0 svc_process_common+0x5d3/0xcc0 svc_process+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 objeto sin referencia 0xffff8881499f4d28 (tamaño 368): comm "nfsd", pid 2761, jiffies 4295044005 (edad 5541.239s) volcado hexadecimal (primeros 32 bytes): 01 00 00 00 00 00 00 00 30 4d 9f 49 81 88 ff ff ........0M.I.... 30 4d 9f 49 81 88 ff ff 20 00 00 00 01 00 00 00 0M.I.... ....... seguimiento inverso: kmem_cache_alloc+0x4b9/0x700 nfs4_alloc_stid+0x29/0x210 alloc_init_deleg+0x92/0x2e0 nfs4_set_delegation+0x284/0xc00 nfs4_open_delegation+0x216/0x3f0 nfsd4_process_open2+0x2b3/0xee0 nfsd4_open+0x770/0x9d0 nfsd4_proc_compound+0x7a2/0xe30 nfsd_dispatch+0x241/0x3e0 svc_process_common+0x5d3/0xcc0 svc_process+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 Solucione el problema comprobando el resultado de nfsd4_run_cb y llama a nfs4_put_stid si no se puede poner en cola dl_recall.
  • Vulnerabilidad en kernel de Linux (CVE-2025-22026)
    Severidad: MEDIA
    Fecha de publicación: 16/04/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: no ignore el código de retorno de svc_proc_register() Actualmente, nfsd_proc_stat_init() ignora el valor de retorno de svc_proc_register(). Si la creación de procfile falla, el kernel emitirá una ADVERTENCIA cuando intente eliminar la entrada posteriormente. Corrija nfsd_proc_stat_init() para que devuelva el mismo tipo de puntero que svc_proc_register() y corrija nfsd_net_init() para que lo compruebe y falle la construcción de nfsd_net si ocurre. svc_proc_register() puede fallar si no se puede asignar la dentry o si ya existe una dentry idéntica. El segundo caso es bastante improbable en la ruta de código de construcción de nfsd_net, por lo que si esto sucede, devuelva -ENOMEM.
  • Vulnerabilidad en kernel de Linux (CVE-2025-22028)
    Severidad: MEDIA
    Fecha de publicación: 16/04/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: vimc: omite .s_stream() para entidades detenidas. Syzbot reportó [1] una advertencia generada por una comprobación en call_s_stream() que verifica si la operación de .s_stream() está justificada para subdesarrollos no iniciados o detenidos. Se ha añadido una solución sencilla en vimc_streamer_pipeline_terminate() que garantiza que las entidades omitan una llamada a .s_stream() a menos que se hayan iniciado correctamente previamente. [1] Informe de Syzbot: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 call_s_stream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460 Modules linked in: CPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0 ... Call Trace: vimc_streamer_pipeline_terminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62 vimc_streamer_pipeline_init drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline] vimc_streamer_s_stream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203 vimc_capture_start_streaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256 vb2_start_streaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789 vb2_core_streamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348 vb2_streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline] vb2_ioctl_streamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118 __video_do_ioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122 video_usercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463 v4l2_ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2b85c01b19 ...
  • Vulnerabilidad en kernel de Linux (CVE-2025-22030)
    Severidad: MEDIA
    Fecha de publicación: 16/04/2025
    Fecha de última actualización: 28/10/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: zswap: corrección del bloqueo de crypto_free_acomp() en zswap_cpu_comp_dead(). Actualmente, zswap_cpu_comp_dead() llama a crypto_free_acomp() mientras mantiene el mutex acomp_ctx por CPU. A continuación, crypto_free_acomp() mantiene scomp_lock (mediante crypto_exit_scomp_ops_async()). Por otro lado, crypto_alloc_acomp_node() mantiene scomp_lock (mediante crypto_scomp_init_tfm()) y luego asigna memoria. Si la asignación resulta en una recuperación, podemos intentar mantener el mutex acomp_ctx por CPU. Las dependencias anteriores pueden causar un bloqueo de ABBA. Por ejemplo, en el siguiente escenario: (1) Tarea A ejecutándose en la CPU n.º 1: crypto_alloc_acomp_node() Retiene scomp_lock Ingresa a recuperación Lee per_cpu_ptr(pool->acomp_ctx, 1) (2) La tarea A se desprograma (3) La CPU n.º 1 se desconecta zswap_cpu_comp_dead(CPU n.º 1) Retiene per_cpu_ptr(pool->acomp_ctx, 1)) Llama a crypto_free_acomp() Espera a scomp_lock (4) Tarea A ejecutándose en la CPU n.º 2: Espera a per_cpu_ptr(pool->acomp_ctx, 1) // Lee en la CPU n.º 1 BLOQUEO INTERMEDIO Dado que no es necesario llamar a crypto_free_acomp() con el mutex acomp_ctx por CPU retenido en zswap_cpu_comp_dead(), muévalo después de que se desbloquee el mutex. También se desplazan las llamadas acomp_request_free() y kfree() para mantener la coherencia y evitar posibles dependencias de bloqueo sutil en el futuro. Con esto, solo se establece el valor NULL de los campos acomp_ctx con el mutex retenido. Esto es similar a cómo zswap_cpu_comp_prepare() solo inicializa los campos acomp_ctx con el mutex retenido, después de realizar todas las asignaciones antes de retener el mutex. Oportunistamente, se desplaza la comprobación de valores NULL en acomp_ctx para que se realice antes de la desreferencia del mutex.
  • Vulnerabilidad en Samsung Mobile (CVE-2025-20996)
    Severidad: MEDIA
    Fecha de publicación: 04/06/2025
    Fecha de última actualización: 28/10/2025
    Una autorización incorrecta en Smart Switch instalado en dispositivos que no son Samsung (versión anterior a la 3.7.64.10) permite a atacantes locales leer datos con el privilegio de Smart Switch. Se requiere la interacción del usuario para activar esta vulnerabilidad.