Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/sched: Incremento del recuento de trabajos antes de intercambiar la cola de cola de spsc. Existe una pequeña competencia entre spsc_queue_push y el trabajador de ejecución de trabajos, en la que spsc_queue_push puede devolver un resultado no-first mientras el trabajador de ejecución de trabajos ya está inactivo debido a que el recuento de trabajos es cero. Si se produce esta competencia, se detiene la programación de trabajos, lo que provoca bloqueos mientras se espera en las barreras DMA del trabajo. Para solucionar esta competencia, incremente el recuento de trabajos antes de agregarlos a la cola de SPSC. Esta competencia se observó en una compilación drm-tip 6.16-rc1 con el controlador Xe en un caso de prueba SVM.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: qcom: msm: marcar ciertos pines como inválidos para interrupciones En algunas plataformas, el pin UFS-reset no tiene lógica de interrupción en TLMM pero sin embargo está registrado como un GPIO en el kernel. Esto permite que el espacio de usuario active un BUG() en el controlador pinctrl-msm ejecutando, por ejemplo: `gpiomon -c 0 113` en RB2. El culpable exacto es solicitar pines cuyo ajuste intr_detection_width no es 1 o 2 para interrupciones. Esto alcanza un BUG() en msm_gpio_irq_set_type(). Potencialmente, bloquear el kernel debido a una solicitud inválida del espacio de usuario no es óptimo, así que revisemos los pines y marquemos aquellos que fallarían la verificación como inválidos para el chip irq ya que ni siquiera deberíamos registrarlos como irq disponibles. Esta función se puede extender si determinamos que hay más casos especiales como este.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: lib/alloc_tag: no adquiere un bloqueo inexistente en alloc_tag_top_users() alloc_tag_top_users() intenta bloquear alloc_tag_cttype->mod_lock incluso cuando alloc_tag_cttype no está asignado porque: 1) el etiquetado de asignación está deshabilitado porque el perfil de memoria está deshabilitado (!alloc_tag_cttype) 2) el etiquetado de asignación está habilitado, pero aún no se ha inicializado (!alloc_tag_cttype) 3) el etiquetado de asignación está habilitado, pero falló la inicialización (!alloc_tag_cttype o IS_ERR(alloc_tag_cttype)) En todos los casos, alloc_tag_cttype no está asignado y, por lo tanto, alloc_tag_top_users() no debe intentar adquirir el semáforo. Esto genera un bloqueo por un error de asignación de memoria al intentar adquirir un semáforo inexistente: Oops: error de protección general, probablemente para una dirección no canónica 0xdffffc000000001b: 0000 [#3] SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x0000000000000d8-0x00000000000000df] CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: GD 6.16.0-rc2 #1 VOLUNTARY Tainted: [D]=DIE Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:down_read_trylock+0xaa/0x3b0 Código: d0 7c 08 84 d2 0f 85 a0 02 00 00 8b 0d df 31 dd 04 85 c9 75 29 48 b8 00 00 00 00 00 fc ff df 48 8d 6b 68 48 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 88 02 00 00 48 3b 5b 68 0f 85 53 01 00 00 65 ff RSP: 0000:ffff8881002ce9b8 EFLAGS: 00010016 RAX: dffffc0000000000 RBX: 0000000000000070 RCX: 0000000000000000 RDX: 0000000000000001b RSI: 000000000000000a RDI: 0000000000000070 RBP: 00000000000000d8 R08: 0000000000000001 R09: ffffed107dde49d1 R10: ffff8883eef24e8b R11: ffff8881002cec20 R12: 1ffff11020059d37 R13: 00000000003fff7b R14: ffff8881002cec20 R15: dffffc0000000000 FS: 00007f963f21d940(0000) GS:ffff888458ca6000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f963f5edf71 CR3: 000000010672c000 CR4: 0000000000350ef0 Rastreo de llamadas: codetag_trylock_module_list+0xd/0x20 Como señala David Wang, este problema se volvió más fácil de activar después de el commit 780138b12381 ("alloc_tag: verificar mem_profiling_support en alloc_tag_init"). Antes de el commit, el problema solo ocurría cuando no se asignaba ni inicializaba alloc_tag_cttype o si fallaba la asignación de memoria antes de llamar a alloc_tag_init(). Después de el commit, se puede activar fácilmente cuando el perfilado de memoria se compila, pero se deshabilita al arrancar. Para determinar correctamente si se ha llamado a alloc_tag_init() y si se han inicializado sus estructuras de datos, verifique que alloc_tag_cttype sea un puntero válido antes de adquirir el semáforo. Si la variable es NULL o un valor de error, no se ha inicializado correctamente. En tal caso, simplemente omita este paso y no intente adquirir el semáforo. [harry.yoo@oracle.com: v3]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/zcrx: corrección de advertencias de destrucción de pp. Con varios grupos de páginas y en otros casos, podemos asignar niovs al destruir el grupo de páginas. Se ha eliminado una advertencia incorrecta que verificaba que todos los niovs se devolvieran a zcrx en io_pp_zc_destroy(). Se informó anteriormente, pero aparentemente se perdió.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mwifiex: descarta marcos de disociación erróneos en la interfaz STA. Cuando se opera en modo STA/AP concurrente con MLME de host habilitado, el firmware envía incorrectamente marcos de disociación a la interfaz STA cuando los clientes se desconectan de la interfaz AP. Esto genera advertencias del kernel ya que la interfaz STA procesa eventos de desconexión que no se aplican a ella: [ 1303.240540] ADVERTENCIA: CPU: 0 PID: 513 en net/wireless/mlme.c:141 cfg80211_process_disassoc+0x78/0xec [cfg80211] [ 1303.250861] Módulos vinculados: 8021q garp stp mrp llc rfcomm bnep btnxpuart nls_iso8859_1 nls_cp437 onboard_us [ 1303.327651] CPU: 0 UID: 0 PID: 513 Comm: kworker/u9:2 No contaminado 6.16.0-rc1+ #3 PREEMPT [ 1303.335937] Nombre del hardware: Toradex Verdin AM62 WB en placa de desarrollo Verdin (DT) [ 1303.343588] Cola de trabajo: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex] [ 1303.350856] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1303.357904] pc : cfg80211_process_disassoc+0x78/0xec [cfg80211] [ 1303.364065] lr : cfg80211_process_disassoc+0x70/0xec [cfg80211] [ 1303.370221] sp : ffff800083053be0 [ 1303.373590] x29: ffff800083053be0 x28: 0000000000000000 x27: 00000000000000000 [ 1303.380855] x26: 0000000000000000 x25: 00000000ffffffff x24: ffff000002c5b8ae [ 1303.388120] x23: ffff000002c5b884 x22: 0000000000000001 x21: 0000000000000008 [ 1303.395382] x20: ffff000002c5b8ae x19: ffff0000064dd408 x18: 0000000000000006 [ 1303.402646] x17: 3a36333a61623a30 x16: 32206d6f72662063 x15: ffff800080bfe048 [ 1303.409910] x14: ffff000003625300 x13: 000000000000001 x12: 0000000000000000 [ 1303.417173] x11: 0000000000000002 x10: ffff000003958600 x9 : ffff000003625300 [ 1303.424434] x8 : ffff00003fd9ef40 x7 : ffff0000039fc280 x6 : 0000000000000002 [ 1303.431695] x5 : ffff0000038976d4 x4 : 0000000000000000 x3 : 0000000000003186 [ 1303.438956] x2 : 000000004836ba20 x1 : 0000000000006986 x0 : 00000000d00479de [ 1303.446221] Rastreo de llamadas: [ 1303.448722] cfg80211_process_disassoc+0x78/0xec [cfg80211] (P) [ 1303.454894] cfg80211_rx_mlme_mgmt+0x64/0xf8 [cfg80211] [ 1303.460362] mwifiex_process_mgmt_packet+0x1ec/0x460 [mwifiex] [ 1303.466380] mwifiex_process_sta_rx_packet+0x1bc/0x2a0 [mwifiex] [ 1303.472573] mwifiex_handle_rx_packet+0xb4/0x13c [mwifiex] [ 1303.478243] mwifiex_rx_work_queue+0x158/0x198 [mwifiex] [ 1303.483734] process_one_work+0x14c/0x28c [ 1303.487845]worker_thread+0x2cc/0x3d4 [ 1303.491680] kthread+0x12c/0x208 [ 1303.495014] ret_from_fork+0x10/0x20 Agregue validación en la ruta de recepción de STA para verificar que los marcos de desasociación/desautorización se originen en el AP conectado. Las tramas que no superan esta comprobación se descartan prematuramente, lo que impide que lleguen a la capa MLME y activen WARN_ON(). Esta lógica de filtrado es similar a la utilizada en la función ieee80211_rx_mgmt_disassoc() de mac80211, que descarta las tramas de desasociación que no coinciden con el BSSID actual (!ether_addr_equal(mgmt->bssid, sdata->vif.cfg.ap_addr)), garantizando así que solo se procesen las tramas relevantes. Probado en: - 8997 con firmware 16.68.1.p197

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: Permitir que la CPU reprograme mientras se configuran atributos de memoria por página Cuando se ejecuta un invitado SEV-SNP con una cantidad de memoria suficientemente grande (1 TB+), el host puede experimentar bloqueos suaves de la CPU cuando ejecuta una operación en kvm_vm_set_mem_attributes() para configurar los atributos de memoria en todo el rango de memoria del invitado. watchdog: BUG: bloqueo suave: ¡CPU n.º 8 bloqueada durante 26 s! [qemu-kvm:6372] CPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: cargado No contaminado 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntario) Nombre del hardware: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 13/11/2024 RIP: 0010:xas_create+0x78/0x1f0 Código: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 <74> 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87 RSP: 0018:ffffad890a34b940 EFLAGS: 00000286 RAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: 00000000000000000 RDX: 000000000000001e RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffad890a356868 R13: ffffad890a356860 R14: 000000000000000 R15: ffffad890a356868 FS: 00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f015c70fb18 CR3: 00000001109fd006 CR4: 0000000000f70ef0 PKRU: 55555554 Rastreo de llamadas: xas_store+0x58/0x630 __xa_store+0xa5/0x130 xa_store+0x2c/0x50 kvm_vm_set_mem_attributes+0x343/0x710 [kvm] kvm_vm_ioctl+0x796/0xab0 [kvm] __x64_sys_ioctl+0xa3/0xd0 do_syscall_64+0x8c/0x7a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f5578d031bb Código: ff ff ff 85 c0 79 9b 49 c7 c4 ff 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 2d 4c 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe0a742b88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000004020aed2 RCX: 00007f5578d031bb RDX: 00007ffe0a742c80 RSI: 000000004020aed2 RDI: 00000000000000b RBP: 000001000000000 R08: 0000010000000000 R09: 0000017680000000 R10: 0000000000000080 R11: 0000000000000246 R12: 00005575e5f95120 R13: 00007ffe0a742c80 R14: 0000000000000008 R15: 00005575e5f961e0 Mientras recorre el rango de memoria configurando los atributos, llame a cond_resched() para darle al programador la oportunidad de ejecutar una tarea de mayor prioridad en la cola de ejecución si es necesario y evitar permanecer en modo kernel el tiempo suficiente para activar el bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: nintendo: evitar bloqueos de suspensión/reinicio de bluetooth Asegúrese de que no bloqueemos ni hagamos que el kernel entre en pánico cuando usemos controladores conectados por bluetooth. Esto se informó como un problema en dispositivos Android que usan el kernel 6.6 debido al gancho de reanudación que se había agregado para los joycons usb. Primero, establezca un nuevo valor de estado en JOYCON_CTLR_STATE_SUSPENDED en un nintendo_hid_suspend recién agregado. Esto asegura que no bloquearemos el kernel esperando informes de entrada durante la suspensión de classdev led. Los bloqueos podrían ocurrir si la conectividad no es confiable o se pierde con el controlador antes de la suspensión. Segundo, dado que perdemos la conectividad durante la suspensión, no intentes joycon_init() para controladores bluetooth en la ruta nintendo_hid_resume. Probado a través de múltiples flujos de suspensión/reinicio al usar el controlador en modo USB y bluetooth.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/sev: Usar TSC_FACTOR para el cálculo de frecuencia de Secure TSC. Al usar Secure TSC, el MSR GUEST_TSC_FREQ informa una frecuencia basada en la frecuencia P0 nominal, que se desvía ligeramente (normalmente ~0,2 %) de la frecuencia media real de TSC debido a los parámetros de reloj. Con el tiempo de actividad prolongado de la máquina virtual, esta discrepancia se acumula, causando un sesgo de reloj entre el hipervisor y una máquina virtual SEV-SNP, lo que lleva a interrupciones tempranas del temporizador según lo percibe el invitado. El kernel invitado se basa en la frecuencia nominal informada para el control de tiempo basado en TSC, mientras que la frecuencia real establecida durante SNP_LAUNCH_START puede diferir. Esta falta de coincidencia resulta en cálculos de tiempo inexactos, lo que hace que el invitado perciba que los temporizadores hr se activan antes de lo esperado. Utilice el factor TSC_FACTOR de la página de secretos del firmware SEV (consulte "Formato de la página de secretos" en la especificación ABI del firmware SNP) para calcular la frecuencia media de TSC, lo que garantiza una sincronización precisa y mitiga el desfase de reloj en las máquinas virtuales SEV-SNP. Utilice early_ioremap_encrypted() para mapear la página de secretos, ya que ioremap_encrypted() utiliza kmalloc(), que no está disponible durante la inicialización temprana de TSC y provoca un pánico. [bp: Eliminar la variable ficticia: https://lore.kernel.org/r/20250630192726.GBaGLlHl84xIopx4Pt@fat_crate.local]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: rechazar el modo de operación VHT para anchos de canal no compatibles. Las notificaciones del modo de operación VHT no están definidas para anchos de canal inferiores a 20 MHz. En particular, 5 MHz y 10 MHz no son válidos según la especificación VHT y deben rechazarse. Sin esta comprobación, las notificaciones malformadas que utilicen estos anchos pueden alcanzar ieee80211_chan_width_to_rx_bw(), lo que genera un WARN_ON debido a una entrada no válida. Este problema fue reportado por syzbot. Rechace estos anchos no compatibles al principio de sta_link_apply_parameters() cuando se utilice opmode_notif. El conjunto aceptado incluye 20, 40, 80, 160 y 80+80 MHz, que son válidos para VHT. Si bien 320 MHz no está definido para VHT, se permite evitar rechazar clientes HE o EHT que aún puedan enviar una notificación de modo de operación VHT.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de la aserción al construir un árbol de espacio libre Al construir el árbol de espacio libre con la función de árbol de grupo de bloques habilitada, podemos encontrarnos con un error de aserción como este: BTRFS info (device loop0 state M): rebuilding free space tree assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102 ------------[ corte aquí ]------------ ¡ERROR del kernel en fs/btrfs/free-space-tree.c:1102! Error interno: Ups - BUG: 00000000f2000800 [#1] Módulos SMP vinculados: CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 No contaminado 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 lr : populate_free_space_tree+0x514/0x518 fs/btrfs/árbol-de-espacio-libre.c:1102 sp : ffff8000a4ce7600 x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8 x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001 x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160 x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0 x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011e740c0 x10: 0000000000ff0100 x9: 94ef24f55d2dbc00 x8: 94ef24f55d2dbc00 x7: 000000000000001 x6: 0000000000000001 x5: ffff8000a4ce6f98 x4: ffff80008f415ba0 x3: ffff800080548ef0 x2: 0000000000000000 x1: 0000000100000000 x0: 000000000000003e Rastreo de llamadas: populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P) btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337 btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074 btrfs_remount_rw fs/btrfs/super.c:1319 [en línea] btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543 reconfigure_super+0x1d4/0x6f0 fs/super.c:1083 do_remount fs/namespace.c:3365 [en línea] path_mount+0xb34/0xde0 fs/namespace.c:4200 do_mount fs/namespace.c:4221 [en línea] __do_sys_mount fs/namespace.c:4432 [en línea] __se_sys_mount fs/namespace.c:4409 [en línea] __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409 __invoke_syscall arch/arm64/kernel/syscall.c:35 [en línea] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Código: f0047182 91178042 528089c3 9771d47b (d4210000) ---[ fin del seguimiento 0000000000000000 ]--- Esto ocurre porque estamos procesando un grupo de bloques vacío, sin extensiones asignadas. No hay elementos para este grupo de bloques, incluido el elemento del grupo, ya que los elementos del grupo de bloques se almacenan en un árbol dedicado al usar la función de árbol de grupos de bloques. Esto también significa que este es el grupo de bloques con el desplazamiento inicial más alto, por lo que no hay claves superiores en la raíz de la extensión. Por lo tanto, btrfs_search_slot_for_read() devuelve 1 (no se encontró una clave superior). Para solucionar esto, establezca que 'ret' sea 0 solo si la función de árbol de grupos de bloques no está habilitada. En ese caso, deberíamos encontrar un elemento de grupo de bloques para el grupo de bloques, ya que se almacena en la raíz de la extensión y las claves de los elementos de grupo de bloques son mayores que las de la extensión (el valor de BTRFS_BLOCK_GROUP_ITEM_KEY es 192 y el de BTRFS_EXTENT_ITEM_KEY y BTRFS_METADATA_ITEM_KEY es 168 y 169, respectivamente). Si 'ret' es 1, simplemente necesitamos agregar un registro al árbol de espacio libre que abarque todo el grupo de bloques. Esto se logra estableciendo 'ret == 0' como condición del bucle while.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Corrección del acceso fuera de los límites en el almacenamiento local de cgroup Lonial informó que se puede manipular un acceso fuera de los límites en el almacenamiento local de cgroup mediante llamadas de cola. Dados dos programas, cada uno utilizando un almacenamiento local de cgroup con un tamaño de valor diferente, y un programa realizando una llamada de cola en el otro. El verificador validará cada uno de los programas individuales sin problemas. Sin embargo, en el contexto de tiempo de ejecución, bpf_cg_run_ctx contiene un bpf_prog_array_item que contiene el programa BPF, así como cualquier sabor de almacenamiento local de cgroup que use el programa. Los ayudantes como bpf_get_local_storage() recogen esto del contexto de tiempo de ejecución: ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype]; if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf); Para el segundo programa llamado desde el programa adjunto original, esto significa que bpf_get_local_storage() tomará el mapa del programa anterior, no el suyo. Con tamaños no coincidentes, esto puede resultar en un acceso fuera de los límites no deseado. Para solucionar este problema, necesitamos extender bpf_map_owner con una matriz de storage_cookie[] para que coincida con i) los mapas exactos del programa original si el segundo programa usaba bpf_get_local_storage(), o ii) permitir la combinación de llamadas de cola si el segundo programa no usaba ninguno de los mapas de almacenamiento local de cgroup.

El complemento Translate This gTranslate Shortcode para WordPress es vulnerable a Cross-Site Scripting almacenado a través del parámetro 'base_lang' en todas las versiones hasta la 1.0 incluida, debido a una depuración de entrada y un escape de salida insuficientes. Esto permite a atacantes autenticados, con acceso de colaborador o superior, inyectar scripts web arbitrarios en las páginas que se ejecutarán al acceder un usuario a una página inyectada.