Vulnerabilidades

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: 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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: raid10: limpieza de fuga de memoria en raid10_make_request Si raid10_read_request o raid10_write_request registra una nueva solicitud y el indicador REQ_NOWAIT está configurado, el código no libera el malloc del grupo de memoria. objeto sin referencia 0xffff8884802c3200 (tamaño 192): comm "fio", pid 9197, jiffies 4298078271 volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 88 41 02 00 00 00 00 00 .........A...... 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ seguimiento inverso (crc c1a049a2): __kmalloc+0x2bb/0x450 mempool_alloc+0x11b/0x320 raid10_make_request+0x19e/0x650 [raid10] md_handle_request+0x3b3/0x9e0 __submit_bio+0x394/0x560 __submit_bio_noacct+0x145/0x530 submit_bio_noacct_nocheck+0x682/0x830 __blkdev_direct_IO_async+0x4dc/0x6b0 blkdev_read_iter+0x1e5/0x3b0 __io_read+0x230/0x1110 io_read+0x13/0x30 io_issue_sqe+0x134/0x1180 io_submit_sqes+0x48c/0xe90 __do_sys_io_uring_enter+0x574/0x8b0 do_syscall_64+0x5c/0xe0 entry_SYSCALL_64_after_hwframe+0x76/0x7e V4: Se modificó el árbol de respaldo para comprobar si las pruebas CKI superan las pruebas. El código del parche no ha cambiado entre versiones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md/raid1: Corregir el uso de memoria de la pila después del retorno en raid1_reshape En la función raid1_reshape, newpool se asigna en la pila y a conf->r1bio_pool. Esto da como resultado que conf->r1bio_pool.wait.head apunte a una dirección de pila. Acceder a esta dirección más tarde puede provocar un pánico del kernel. Ejemplo de ruta de acceso: raid1_reshape() { // newpool está en la pila mempool_t newpool, oldpool; // inicializar newpool.wait.head en la dirección de la pila mempool_init(&newpool, ...); conf->r1bio_pool = newpool; } raid1_read_request() o raid1_write_request() { alloc_r1bio() { mempool_alloc() { // si pool->alloc falla remove_element() { --pool->curr_nr; } } } } mempool_free() { if (pool->curr_nr < pool->min_nr) { // pool->wait.head es una dirección de pila // wake_up() intentará acceder a esta dirección no válida // lo que genera un pánico del kernel return; wake_up(&pool->wait); } } Solución: reinicie conf->r1bio_pool.wait después de asignar newpool.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: corrige el uso potencial use-after-free en el acuse de recibo de interrupción de oplock/lease Si ksmbd_iov_pin_rsp devuelve un error, el use-after-free puede ocurrir al acceder a opinfo->state y opinfo_put y ksmbd_fd_put podrían ser llamados dos veces.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt_en: Establezca la longitud de desasignación de DMA correctamente para XDP_REDIRECT. Al transmitir un paquete XDP_REDIRECT, llame a dma_unmap_len_set() con la longitud adecuada en lugar de 0. Este error activa esta advertencia en un sistema con IOMMU habilitado: WARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 __iommu_dma_unmap+0x159/0x170 RIP: 0010:__iommu_dma_unmap+0x159/0x170 Code: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c 89 45 b8 4c 89 45 c0 e9 77 ff ff ff <0f> 0b e9 60 ff ff ff e8 8b bf 6a 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ff22d31181150c88 EFLAGS: 00010206 RAX: 0000000000002000 RBX: 00000000e13a0000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff22d31181150cf0 R08: ff22d31181150ca8 R09: 0000000000000000 R10: 0000000000000000 R11: ff22d311d36c9d80 R12: 0000000000001000 R13: ff13544d10645010 R14: ff22d31181150c90 R15: ff13544d0b2bac00 FS: 0000000000000000(0000) GS:ff13550908a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005be909dacff8 CR3: 0008000173408003 CR4: 0000000000f71ef0 PKRU: 55555554 Call Trace: ? show_regs+0x6d/0x80 ? __warn+0x89/0x160 ? __iommu_dma_unmap+0x159/0x170 ? report_bug+0x17e/0x1b0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x18/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? __iommu_dma_unmap+0x159/0x170 ? __iommu_dma_unmap+0xb3/0x170 iommu_dma_unmap_page+0x4f/0x100 dma_unmap_page_attrs+0x52/0x220 ? srso_alias_return_thunk+0x5/0xfbef5 ? xdp_return_frame+0x2e/0xd0 bnxt_tx_int_xdp+0xdf/0x440 [bnxt_en] __bnxt_poll_work_done+0x81/0x1e0 [bnxt_en] bnxt_poll+0xd3/0x1e0 [bnxt_en]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: flowtable: cuenta para el encabezado Ethernet en nf_flow_pppoe_proto() syzbot encontró un acceso potencial a uninit-value en nf_flow_pppoe_proto() El commit culpado olvidó el encabezado Ethernet. BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xe1/0x3d0 net/netfilter/core.c:623 nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline] nf_ingress net/core/dev.c:5742 [inline] __netif_receive_skb_core+0x4aff/0x70c0 net/core/dev.c:5837 __netif_receive_skb_one_core net/core/dev.c:5975 [inline] __netif_receive_skb+0xcc/0xac0 net/core/dev.c:6090 netif_receive_skb_internal net/core/dev.c:6176 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6235 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x4ee0/0x6b40 drivers/net/tun.c:1938 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1984 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xb4b/0x1580 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline]<br />