Vulnerabilidades

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 />

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: Intel: hda: Usar devm_kstrdup() para evitar fugas de memoria. La dirección de sof_pdata-&amp;gt;tplg_filename puede ser asignada por kstrdup() y puede sobrescribirse. Se detectó una fuga de memoria con kmemleak:unreferenced object 0xffff88812391ff60 (size 16): comm "kworker/4:1", pid 161, jiffies 4294802931 hex dump (first 16 bytes): 73 6f 66 2d 68 64 61 2d 67 65 6e 65 72 69 63 00 sof-hda-generic. backtrace (crc 4bf1675c): __kmalloc_node_track_caller_noprof+0x49c/0x6b0 kstrdup+0x46/0xc0 hda_machine_select.cold+0x1de/0x12cf [snd_sof_intel_hda_generic] sof_init_environment+0x16f/0xb50 [snd_sof] sof_probe_continue+0x45/0x7c0 [snd_sof] sof_probe_work+0x1e/0x40 [snd_sof] process_one_work+0x894/0x14b0 worker_thread+0x5e5/0xfb0 kthread+0x39d/0x760 ret_from_fork+0x31/0x70 ret_from_fork_asm+0x1a/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Se corrige la competencia entre la desactivación de DIM y net_dim(). Existe una competencia entre la desactivación de las devoluciones de llamada de DIM y NAPI mediante el puntero dim en el RQ o SQ. Si NAPI comprueba el bit de estado de DIM y lo ve aún establecido, asume que `rq-&amp;gt;dim` o `sq-&amp;gt;dim` son válidos. Sin embargo, si DIM se desactiva justo después de dicha comprobación, es posible que el puntero ya esté establecido en NULL, lo que provoca una desreferencia de puntero NULL en net_dim(). Para solucionar esto, llame a `synchronize_net()` antes de liberar el contexto de DIM. Esto garantiza que todas las devoluciones de llamada de NAPI en curso finalicen antes de que se borre el puntero. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:net_dim+0x23/0x190 ... Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? common_interrupt+0xf/0xa0 ? sysvec_call_function_single+0xb/0x90 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? net_dim+0x23/0x190 ? mlx5e_poll_ico_cq+0x41/0x6f0 [mlx5_core] ? sysvec_apic_timer_interrupt+0xb/0x90 mlx5e_handle_rx_dim+0x92/0xd0 [mlx5_core] mlx5e_napi_poll+0x2cd/0xac0 [mlx5_core] ? mlx5e_poll_ico_cq+0xe5/0x6f0 [mlx5_core] busy_poll_stop+0xa2/0x200 ? mlx5e_napi_poll+0x1d9/0xac0 [mlx5_core] ? mlx5e_trigger_irq+0x130/0x130 [mlx5_core] __napi_busy_loop+0x345/0x3b0 ? sysvec_call_function_single+0xb/0x90 ? asm_sysvec_call_function_single+0x16/0x20 ? sysvec_apic_timer_interrupt+0xb/0x90 ? pcpu_free_area+0x1e4/0x2e0 napi_busy_loop+0x11/0x20 xsk_recvmsg+0x10c/0x130 sock_recvmsg+0x44/0x70 __sys_recvfrom+0xbc/0x130 ? __schedule+0x398/0x890 __x64_sys_recvfrom+0x20/0x30 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ... ---[ end trace 0000000000000000 ]--- ... ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: rechazar dispositivos de bloque bs &amp;gt; ps cuando THP está deshabilitado Si THP está deshabilitado y cuando hay un dispositivo de bloque con un tamaño de bloque lógico &amp;gt; tamaño de página, se produce el siguiente pánico de desreferencia de ptr nulo durante el arranque:[ [13.2 mK AOSAN: null-ptr-deref in range [0x0000000000000000-0x0000000000K0 0 0[07] [ 13.017749] RIP: 0010:create_empty_buffers+0x3b/0x380 [ 13.025448] Call Trace: [ 13.025692] [ 13.025895] block_read_full_folio+0x610/0x780 [ 13.026379] ? __pfx_blkdev_get_block+0x10/0x10 [ 13.027008] ? __folio_batch_add_and_move+0x1fa/0x2b0 [ 13.027548] ? __pfx_blkdev_read_folio+0x10/0x10 [ 13.028080] filemap_read_folio+0x9b/0x200 [ 13.028526] ? __pfx_filemap_read_folio+0x10/0x10 [ 13.029030] ? __filemap_get_folio+0x43/0x620 [ 13.029497] do_read_cache_folio+0x155/0x3b0 [ 13.029962] ? __pfx_blkdev_read_folio+0x10/0x10 [ 13.030381] read_part_sector+0xb7/0x2a0 [ 13.030805] read_lba+0x174/0x2c0 [ 13.045348] nvme_scan_ns+0x684/0x850 [nvme_core] [ 13.045858] ? __pfx_nvme_scan_ns+0x10/0x10 [nvme_core] [ 13.046414] ? _raw_spin_unlock+0x15/0x40 [ 13.046843] ? __switch_to+0x523/0x10a0 [ 13.047253] ? kvm_clock_get_cycles+0x14/0x30 [ 13.047742] ? __pfx_nvme_scan_ns_async+0x10/0x10 [nvme_core] [ 13.048353] async_run_entry_fn+0x96/0x4f0 [ 13.048787] process_one_work+0x667/0x10a0 [ 13.049219] worker_thread+0x63c/0xf60 Como la compatibilidad con folios grandes depende de THP, solo se permiten dispositivos de bloque bs &amp;gt; ps si THP está habilitado.

En entornos de alto tráfico, Silicon Labs OpenThread RCP (ver versiones afectadas) no logra borrar el búfer de transmisión SPI y puede enviar un paquete corrupto a través de SPI a su host, lo que hace que el host restablezca el RCP y esto resulte en una denegación de servicio.

Existe una vulnerabilidad de configuración incorrecta de seguridad del lado del cliente en la plataforma de denuncia OpenBlow en múltiples versiones e implementaciones predeterminadas, debido a la ausencia de encabezados de respuesta HTTP críticos, como Content-Security-Policy, Referrer-Policy, Permissions-Policy, Cross-Origin-Embedder-Policy y Cross-Origin-Resource-Policy. Esta omisión debilita las defensas del navegador y expone a los usuarios a ataques de cross-site scripting (xss), clickjacking y fugas de referencias. Aunque algunos casos intentan aplicar la CSP mediante etiquetas HTML , este método resulta ineficaz, ya que los navegadores modernos dependen de la aplicación basada en encabezados para bloquear de forma fiable los scripts en línea y los recursos no confiables.