Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: SVM: Rechazar la migración intrahost de SEV{-ES} si la creación de vCPU está en vuelo Rechazar la migración del estado SEV{-ES} si la VM de origen o de destino está creando activamente una vCPU, es decir, si kvm_vm_ioctl_create_vcpu() está en la sección entre el incremento de created_vcpus y online_vcpus. La mayor parte de la creación de vCPU se ejecuta _fuera_ de kvm->lock para permitir la creación de múltiples vCPU en paralelo, y por lo tanto sev_info.es_active puede alternarse de false=>true en la VM de destino después (o durante) svm_vcpu_create(), lo que resulta en que una VM SEV{-ES} tenga efectivamente una vCPU que no es SEV{-ES}. El problema se manifiesta de forma más visible como un bloqueo al intentar liberar una página VMSA NULL de una vCPU en una VM SEV-ES, pero hay muchas cosas que pueden salir mal. BUG: unable to handle page fault for address: ffffebde00000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline] RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline] RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline] RIP: 0010:PageHead include/linux/page-flags.h:866 [inline] RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067 Code: <49> f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0 RSP: 0018:ffff8984551978d0 EFLAGS: 00010246 RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000 RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000 R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000 R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000 FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0 DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169 svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515 kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396 kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline] kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490 kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895 kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310 kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369 __fput+0x3e4/0x9e0 fs/file_table.c:465 task_work_run+0x1a9/0x220 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x7f0/0x25b0 kernel/exit.c:953 do_group_exit+0x203/0x2d0 kernel/exit.c:1102 get_signal+0x1357/0x1480 kernel/signal.c:3034 arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218 do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f87a898e969 Modules linked in: gq(O) gsmi: Log Shutdown Reason 0x03 CR2: ffffebde00000000 ---[ end trace 0000000000000000 ]--- Deliberately don't check for a NULL VMSA when freeing the vCPU, as crashing the host is likely desirable due to the VMSA being consumed by hardware. E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a bogus VMSA page. Accessing P ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: ad1816a: Se corrige la posible desreferencia de puntero NULL en snd_card_ad1816a_pnp(). Utilice pr_warn() en lugar de dev_warn() cuando 'pdev' sea NULL para evitar una posible desreferencia de puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: Abort __tc_modify_qdisc si la clase padre no existe. El parche de Lion [1] reveló un error antiguo en la API de qdisc. Siempre que un usuario crea o modifica una qdisc que especifica otra qdisc como padre, la API de qdisc detecta, durante el injerto, que el usuario no intenta asociarse a una clase y lo rechaza. Sin embargo, el injerto se realiza después de ejecutar qdisc_create (y, por lo tanto, la devolución de llamada de inicio de la qdisc). En las qdisc que eventualmente llaman a qdisc_tree_reduce_backlog durante la inicialización o el cambio (como fq, hhf, choke, etc.), surge un problema. Por ejemplo, al ejecutar los siguientes comandos: sudo tc qdisc add dev lo root handle a: htb default 2 sudo tc qdisc add dev lo parent a: handle beef fq Las Qdisc como fq, hhf, choke, etc., invocan incondicionalmente qdisc_tree_reduce_backlog() en su ruta de control init() o change(), lo que provoca un error al no encontrar la clase hija; sin embargo, esto no detiene la invocación incondicional de qlen_notify de la qdisc hija asumida con una clase nula. Todas estas qdisc asumen que la clase no es nula. La solución es garantizar que qdisc_leaf(), que busca la clase padre y se invoca antes que qdisc_create(), devuelva un error al no encontrar la clase. En este parche, aprovechamos qdisc_leaf para devolver ERR_PTR siempre que el parentid no corresponda a una clase, de modo que podamos detectarlo antes y abortar antes de que se llame a qdisc_create. [1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: u_serial: Corrección de la condición de ejecución en la activación de TTY. Una condición de ejecución ocurre cuando gs_start_io() llama a gs_start_rx() o gs_start_tx(), ya que estas funciones desactivan brevemente el port_lock para usb_ep_queue(). Esto permite que gs_close() y gserial_disconnect() borren port.tty y port_usb, respectivamente. Utilice la función auxiliar de puerto TTY segura para nulos para activar TTY. Ejemplo CPU1: CPU2: gserial_connect() // bloquear gs_close() // esperar bloqueo gs_start_rx() // desbloquear usb_ep_queue() gs_close() // bloquear, restablecer port.tty y desbloquear gs_start_rx() // bloquear tty_wakeup() // NPE

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: imx: Se corrige un acceso fuera de los límites en dispmix_csr_clk_dev_data. Cuando num_parents es 4, __clk_register() genera un acceso fuera de los límites al acceder al miembro parent_names. Use ARRAY_SIZE() en lugar de codificar el número. BUG: KASAN: global-out-of-bounds in __clk_register+0x1844/0x20d8 Read of size 8 at addr ffff800086988e78 by task kworker/u24:3/59 Hardware name: NXP i.MX95 19X19 board (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x8c/0xcc print_report+0x398/0x5fc kasan_report+0xd4/0x114 __asan_report_load8_noabort+0x20/0x2c __clk_register+0x1844/0x20d8 clk_hw_register+0x44/0x110 __clk_hw_register_mux+0x284/0x3a8 imx95_bc_probe+0x4f4/0xa70

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/rmap: corrige el posible acceso fuera de los límites de la tabla de páginas durante la desasignación por lotes Como señaló David[1], la lógica de desasignación por lotes en try_to_unmap_one() puede leer más allá del final de una tabla PTE cuando las asignaciones PTE de un folio grande no están completamente contenidas dentro de una sola tabla de páginas. Si bien este escenario puede ser poco común, un problema desencadenable desde el espacio de usuario debe corregirse independientemente de su probabilidad. Este parche corrige el acceso fuera de los límites refactorizando la lógica en un nuevo ayudante, folio_unmap_pte_batch(). El nuevo ayudante calcula correctamente el tamaño de lote seguro al limitar el escaneo en los límites de VMA y PMD. Para simplificar el código, también admite el procesamiento por lotes parcial (es decir, cualquier número de páginas desde 1 hasta el máximo seguro calculado), ya que no hay una razón sólida para un caso especial de folios completamente mapeados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/gem: Adquisición de referencias en manejadores GEM para framebuffers. Un manejador GEM puede liberarse mientras el objeto de búfer GEM está asociado a un framebuffer DRM. Esto provoca la liberación del dma-buf que respalda el objeto de búfer, si lo hay. [1] Intentar usar el framebuffer en otras operaciones de configuración de modo provoca un fallo de segmentación. Esto ocurre con mayor frecuencia con controladores que utilizan planos de sombra para vmapear el dma-buf durante un cambio de página. A continuación se muestra un ejemplo. [ 156.791968] ------------[ cut here ]------------ [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430 [...] [ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430 [ 157.043420] Call Trace: [ 157.045898] [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710 [ 157.065567] ? dma_buf_vmap+0x224/0x430 [ 157.069446] ? __warn.cold+0x58/0xe4 [ 157.073061] ? dma_buf_vmap+0x224/0x430 [ 157.077111] ? report_bug+0x1dd/0x390 [ 157.080842] ? handle_bug+0x5e/0xa0 [ 157.084389] ? exc_invalid_op+0x14/0x50 [ 157.088291] ? asm_exc_invalid_op+0x16/0x20 [ 157.092548] ? dma_buf_vmap+0x224/0x430 [ 157.096663] ? dma_resv_get_singleton+0x6d/0x230 [ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10 [ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10 [ 157.110697] drm_gem_shmem_vmap+0x74/0x710 [ 157.114866] drm_gem_vmap+0xa9/0x1b0 [ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0 [ 157.123086] drm_gem_fb_vmap+0xab/0x300 [ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10 [ 157.133032] ? lockdep_init_map_type+0x19d/0x880 [ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0 [ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180 [ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40 [...] [ 157.346424] ---[ end trace 0000000000000000 ]--- Acquiring GEM handles for the framebuffer's GEM buffer objects prevents this from happening. The framebuffer's cleanup later puts the handle references. Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object instance") triggers the segmentation fault easily by using the dma-buf field more widely. The underlying issue with reference counting has been present before. v2: - acquire the handle instead of the BO (Christian) - fix comment style (Christian) - drop the Fixes tag (Christian) - rename err_ gotos - add missing Link tag

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7925: evitar la desreferencia de puntero nulo en mt7925_sta_set_decap_offload(). Se ha añadido una comprobación nula para msta->vif antes de acceder a sus miembros para evitar un pánico del kernel en la implementación en modo AP. Esto también soluciona el problema reportado en [1]. El fallo se produce cuando esta función se activa antes de que la estación se inicialice por completo. El seguimiento de llamadas muestra un fallo de página en mt7925_sta_set_decap_offload() debido al acceso a recursos cuando msta->vif es nulo. Para solucionar esto, se añade un retorno anticipado si msta->vif es nulo y se comprueba que wcid.sta esté listo. Esto garantiza que solo procedamos con la configuración de descarga de decap cuando el estado de la estación se inicialice correctamente. [14739.655703] Unable to handle kernel paging request at virtual address ffffffffffffffa0 [14739.811820] CPU: 0 UID: 0 PID: 895854 Comm: hostapd Tainted: G [14739.821394] Tainted: [C]=CRAP, [O]=OOT_MODULE [14739.825746] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) [14739.831577] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [14739.838538] pc : mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common] [14739.845271] lr : mt7925_sta_set_decap_offload+0x58/0x1b8 [mt7925_common] [14739.851985] sp : ffffffc085efb500 [14739.855295] x29: ffffffc085efb500 x28: 0000000000000000 x27: ffffff807803a158 [14739.862436] x26: ffffff8041ececb8 x25: 0000000000000001 x24: 0000000000000001 [14739.869577] x23: 0000000000000001 x22: 0000000000000008 x21: ffffff8041ecea88 [14739.876715] x20: ffffff8041c19ca0 x19: ffffff8078031fe0 x18: 0000000000000000 [14739.883853] x17: 0000000000000000 x16: ffffffe2aeac1110 x15: 000000559da48080 [14739.890991] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000 [14739.898130] x11: 0a10020001008e88 x10: 0000000000001a50 x9 : ffffffe26457bfa0 [14739.905269] x8 : ffffff8042013bb0 x7 : ffffff807fb6cbf8 x6 : dead000000000100 [14739.912407] x5 : dead000000000122 x4 : ffffff80780326c8 x3 : 0000000000000000 [14739.919546] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8041ececb8 [14739.926686] Call trace: [14739.929130] mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common] [14739.935505] ieee80211_check_fast_rx+0x19c/0x510 [mac80211] [14739.941344] _sta_info_move_state+0xe4/0x510 [mac80211] [14739.946860] sta_info_move_state+0x1c/0x30 [mac80211] [14739.952116] sta_apply_auth_flags.constprop.0+0x90/0x1b0 [mac80211] [14739.958708] sta_apply_parameters+0x234/0x5e0 [mac80211] [14739.964332] ieee80211_add_station+0xdc/0x190 [mac80211] [14739.969950] nl80211_new_station+0x46c/0x670 [cfg80211] [14739.975516] genl_family_rcv_msg_doit+0xdc/0x150 [14739.980158] genl_rcv_msg+0x218/0x298 [14739.983830] netlink_rcv_skb+0x64/0x138 [14739.987670] genl_rcv+0x40/0x60 [14739.990816] netlink_unicast+0x314/0x380 [14739.994742] netlink_sendmsg+0x198/0x3f0 [14739.998664] __sock_sendmsg+0x64/0xc0 [14740.002324] ____sys_sendmsg+0x260/0x298 [14740.006242] ___sys_sendmsg+0xb4/0x110

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: rtsn: Se corrige una desreferencia de puntero nulo en rtsn_probe(). Se agrega una verificación para el valor de retorno de rcar_gen4_ptp_alloc() para evitar una posible desreferencia de puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/msg_ring: garantizar que la liberación de io_kiocb se posponga para RCU syzbot informa que agregar defer/local task_work mediante msg_ring puede afectar a una solicitud que se ha liberado: CPU: 1 UID: 0 PID: 19356 Comm: iou-wrk-19354 No contaminado 6.16.0-rc4-syzkaller-00108-g17bbde2e1716 #0 PREEMPT(full) Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Rastreo de llamadas: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 io_req_local_work_add io_uring/io_uring.c:1184 [inline] __io_req_task_work_add+0x589/0x950 io_uring/io_uring.c:1252 io_msg_remote_post io_uring/msg_ring.c:103 [inline] io_msg_data_remote io_uring/msg_ring.c:133 [inline] __io_msg_ring_data+0x820/0xaa0 io_uring/msg_ring.c:151 io_msg_ring_data io_uring/msg_ring.c:173 [inline] io_msg_ring+0x134/0xa00 io_uring/msg_ring.c:314 __io_issue_sqe+0x17e/0x4b0 io_uring/io_uring.c:1739 io_issue_sqe+0x165/0xfd0 io_uring/io_uring.c:1762 io_wq_submit_work+0x6e9/0xb90 io_uring/io_uring.c:1874 io_worker_handle_work+0x7cd/0x1180 io_uring/io-wq.c:642 io_wq_worker+0x42f/0xeb0 io_uring/io-wq.c:696 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 que se supone que es seguro con la asignación de solicitudes. Sin embargo, las solicitudes del anillo msg asignan y liberan por sí solas, por lo que deben posponer la liberación hasta un momento razonable. Agregue un rcu_head y use kfree_rcu() en ambos puntos donde se liberan las solicitudes. Solo el de io_msg_tw_complete() es estrictamente obligatorio, ya que ha sido visible en el otro anillo, pero úselo consistentemente también en el otro punto. Esto no debería causar otros problemas, aparte de las quejas legítimas de KASAN.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md/md-bitmap: corrección de GPF en bitmap_get_stats(). El mensaje del commit 6ec1f0239485 ("md/md-bitmap: corrección de la recopilación de estadísticas para mapas de bits externos") indica: Se elimina la comprobación de mapas de bits externos, ya que las estadísticas deben estar disponibles independientemente de su ubicación de almacenamiento. Se devuelve -EINVAL solo para mapas de bits no válidos sin almacenamiento (ni en superbloque ni en archivo externo). Sin embargo, el código no cumple con lo anterior, ya que solo comprueba si hay un superbloque válido para mapas de bits "internos". Por lo tanto, observamos: Oops: GPF, probablemente para la dirección no canónica 0x1cd66f1f40000028 RIP: 0010:bitmap_get_stats+0x45/0xd0 Rastreo de llamadas: seq_read_iter+0x2b9/0x46a seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6d/0xf0 do_syscall_64+0x8c/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Solucionamos esto verificando la existencia de un superbloque tanto para el caso interno como para el externo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nbd: corrección de uaf en la ruta de error nbd_genl_connect() Hay un problema de use-after-free en nbd: bloque nbd6: Error en el control de recepción (resultado -104) bloque nbd6: apagado de sockets ================================================================== BUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022 Write of size 4 at addr ffff8880295de478 by task kworker/u33:0/67 CPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: nbd6-recv recv_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_dec include/linux/atomic/atomic-instrumented.h:592 [inline] recv_work+0x694/0xa80 drivers/block/nbd.c:1022 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 nbd_genl_connect() no detiene correctamente el dispositivo en ciertas rutas de error después de llamar a nbd_start_device(). Esto provoca que la ruta de error coloque nbd->config mientras que recv_work sigue usando la configuración después de colocarla, lo que provoca un error de use-after-free en recv_work. Esta corrección mueve nbd_start_device() después de la creación del archivo de backend.