Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: corrección del use-after-free en la autenticación Kerberos. Se introdujo la configuración sess->user = NULL para corregir el puntero colgante creado por ksmbd_free_user. Sin embargo, es posible que otro hilo esté operando en la sesión y utilice sess->user después de que se haya pasado a ksmbd_free_user, pero antes de que sess->user se establezca en NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige el problema de use-after-free en ksmbd_session_rpc_open. Un problema de UAF puede ocurrir debido a una condición de ejecución entre ksmbd_session_rpc_open() y __session_rpc_close(). Agregue rpc_lock a la sesión para protegerla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: Se corrige la escritura fuera de los límite en trace_seq_to_buffer() syzbot informó este error: ====================================================================== ERROR: KASAN: slab-out-of-bounds en trace_seq_to_buffer kernel/trace/trace.c:1830 [en línea] ERROR: KASAN: slab-out-of-bounds en tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 Escritura de tamaño 4507 en la dirección ffff888032b6b000 por tarea syz.2.320/7260 CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 No contaminado 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full) Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [en línea] 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 [en línea] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106 trace_seq_to_buffer kernel/trace/trace.c:1830 [en línea] tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 .... ===================================================================== Se ha informado que trace_seq_to_buffer() intenta copiar más datos que PAGE_SIZE a buf. Por lo tanto, para evitarlo, debemos usar el valor menor entre trace_seq_used(&iter->seq) y PAGE_SIZE como argumento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: book3s64/radix : Alinear la dirección de inicio de la sección vmemmap a PAGE_SIZE Un altmap de vmemmap es una región proporcionada por el dispositivo que se utiliza para proporcionar almacenamiento de respaldo para páginas de estructura. Para cada espacio de nombres, el altmap debe pertenecer a ese mismo espacio de nombres. Si los espacios de nombres se crean sin alinear, existe la posibilidad de que la dirección de inicio de la sección vmemmap también esté desalineada. Si la dirección de inicio de la sección vmemmap no está alineada, la página altmap asignada desde el espacio de nombres actual también podría ser utilizada por el espacio de nombres anterior. Durante la operación de liberación, dado que el altmap se comparte entre dos espacios de nombres, el espacio de nombres anterior puede detectar que la página no pertenece a su altmap y asumir incorrectamente que la página es una página normal. Entonces intenta liberar la página normal, lo que provoca un fallo del kernel. El kernel intentó leer la página del usuario (18): ¿intento de explotación? (uid: 0) ERROR: Desreferencia de puntero NULL del kernel en lectura en 0x00000018 Dirección de instrucción con errores: 0xc000000000530c7c Oops: Acceso del kernel al área incorrecta, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries CPU: 32 PID: 2104 Comm: ndctl Kdump: cargado Contaminado: GW NIP: c000000000530c7c LR: c000000000530e00 CTR: 0000000000007ffe REGS: c000000015e57040 TRAP: 0300 Contaminado: GW MSR: 800000000280b033 CR: 84482404 CFAR: c000000000530dfc DAR: 00000000000000018 DSISR: 40000000 IRQMASK: 0 GPR00: c000000000530e00 c000000015e572e0 c000000002c5cb00 c00c000101008040 GPR04: 00000000000000000 0000000000000007 0000000000000001 0000000000000001f GPR08: 0000000000000005 0000000000000000 0000000000000018 0000000000002000 GPR12: c0000000001d2fb0 c0000060de6b0080 0000000000000000 c0000060dbf90020 GPR16: c00c000101008000 0000000000000001 000000000000000 c000000125b20f00 GPR20: 0000000000000001 0000000000000000 ffffffffffffffff c00c000101007fff GPR24: 0000000000000001 0000000000000000 0000000000000000 0000000000000000 GPR28: 0000000004040201 000000000000001 000000000000000 c00c000101008040 NIP [c000000000530c7c] máscara_obtener_indicadores_pfnblock+0x7c/0xd0 LR [c000000000530e00] free_unref_page_prepare+0x130/0x4f0 Rastreo de llamadas: free_unref_page+0x50/0x1e0 free_reserved_page+0x40/0x68 free_vmemmap_pages+0x98/0xe0 remove_pte_table+0x164/0x1e8 remove_pmd_table+0x204/0x2c8 remove_pud_table+0x1c4/0x288 remove_pagetable+0x1c8/0x310 vmemmap_free+0x24/0x50 section_deactivate+0x28c/0x2a0 __remove_pages+0x84/0x110 arch_remove_memory+0x38/0x60 Otro problema es que si no hay un altmap, se asignará una página vmemmap del tamaño de PMD desde la RAM, independientemente de la alineación de la dirección de inicio de la sección. Si la dirección de inicio de la sección no está alineada con el tamaño de PMD, se activará un error VM_BUG_ON al configurar la página de tamaño PMD en la tabla de páginas. En esta revisión, estamos alineando la dirección de inicio de vmemmap de la sección con PAGE_SIZE. Después de la alineación, la dirección de inicio no formará parte del espacio de nombres actual y se asignará una página normal para la asignación de vmemmap de la sección actual. Para las secciones restantes, se asignarán mapas alternativos. Durante la operación de liberación, la página normal se liberará correctamente. De la misma manera, se asignará una página vmemmap PMD_SIZE solo si la dirección de inicio de la sección está alineada con PMD_SIZE; de lo contrario, se recurrirá a una asignación de vmemmap de tamaño PAGE. Sin esta revisión ===================== Inicio de NS1 Inicio de NS2 _________________________________________________________ | NS1 | NS2 | --------------------------------------------------------- | Altmap| Altmap | .....|Altmap| Altmap | ........... | NS1 | NS1 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vxlan: vnifilter: Se corrige la eliminación desbloqueada de la entrada FDB predeterminada. Cuando se elimina una VNI de un dispositivo VXLAN en modo 'vnifilter', la entrada FDB asociada al control remoto predeterminado (si se configuró uno) se elimina sin mantener el bloqueo hash. Esto es incorrecto y generará una advertencia [1] generada por la anotación lockdep, añadida por el commit ebe642067455 ("vxlan: Crear envoltorios para la búsqueda FDB"). Reproductor: # ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0 # bridge vni del vni 10010 dev vx0 Se corrige adquiriendo el bloqueo hash antes de la eliminación y liberándolo después. Culpe a el commit original que introdujo el problema en lugar de a la que lo expuso. [1] ADVERTENCIA: CPU: 3 PID: 392 en drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0 [...] RIP: 0010:vxlan_find_mac+0x17f/0x1a0 [...] Rastreo de llamadas: __vxlan_fdb_delete+0xbe/0x560 vxlan_vni_delete_group+0x2ba/0x940 vxlan_vni_del.isra.0+0x15f/0x580 vxlan_process_vni_filter+0x38b/0x7b0 vxlan_vnifilter_process+0x3bb/0x510 rtnetlink_rcv_msg+0x2f7/0xb70 netlink_rcv_skb+0x131/0x360 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x121/0x1b0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: amd: acp: Corregir la desreferencia del puntero NULL en acp_i2s_set_tdm_slot Actualizar los datos del chip usando dev_get_drvdata(dev->parent) para corregir la desreferencia del puntero NULL en acp_i2s_set_tdm_slot.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btusb: evitar la desreferencia de puntero NULL en skb_dequeue() Una desreferencia de puntero NULL puede ocurrir en skb_dequeue() cuando se procesa un volcado de memoria de firmware QCA en WCN7851 (0489:e0f3). [ 93.672166] Bluetooth: hci0: tamaño de volcado de memoria ACL (589824) [ 93.672475] ERROR: Desreferencia de puntero nulo del kernel, dirección: 0000000000000008 [ 93.672517] Cola de trabajo: hci0 hci_devcd_rx [bluetooth] [ 93.672598] RIP: 0010:skb_dequeue+0x50/0x80. El problema se debe a que handle_dump_pkt_qca() devuelve 0 incluso cuando un paquete de volcado se procesa correctamente. Esto se debe a que reenvía incorrectamente el valor de retorno de hci_devcd_init() (que devuelve 0 en caso de éxito). Como resultado, el llamador (btusb_recv_acl_qca() o btusb_recv_evt_qca()) asume que el paquete no fue procesado y lo pasa a hci_recv_frame(), lo que provoca un kfree() prematuro del skb. Posteriormente, hci_devcd_rx() intenta retirar el mismo skb de la cola de volcado, lo que resulta en una desreferencia de puntero nulo. Para solucionar esto: 1. Hacer que handle_dump_pkt_qca() devuelva 0 en caso de éxito y errno negativo en caso de error, de acuerdo con las convenciones del kernel. 2. Dividir la detección de paquetes de volcado en funciones independientes para ACL y paquetes de eventos para una mejor estructura y legibilidad. Esto garantiza que los paquetes de volcado se identifiquen y consuman correctamente, evitando el doble manejo y el acceso a punteros nulos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: mtk-star-emac: corrige problemas de recursión de spinlock en el sondeo rx/tx Utilice spin_lock_irqsave y spin_unlock_irqrestore en lugar de spin_lock y spin_unlock en el controlador mtk_star_emac para evitar que se produzca una recursión de spinlock que puede suceder cuando se habilitan nuevamente las interrupciones DMA en el sondeo rx/tx. ``` ERROR: recursión de bloqueo de giro en CPU#0, bloqueo swapper/0/0: 0xffff00000db9cf20, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 No contaminado 6.15.0-rc2-next-20250417-00001-gf6a27738686c-dirty #28 PREEMPT Nombre del hardware: MediaTek MT8365 Open Platform EVK (DT) Rastreo de llamadas: show_stack+0x18/0x24 (C) dump_stack_lvl+0x60/0x80 dump_stack+0x18/0x24 spin_dump+0x78/0x88 do_raw_spin_lock+0x11c/0x120 _raw_spin_lock+0x20/0x2c mtk_star_handle_irq+0xc0/0x22c [mtk_star_emac] __handle_irq_event_percpu+0x48/0x140 handle_irq_event+0x4c/0xb0 handle_fasteoi_irq+0xa0/0x1bc handle_irq_desc+0x34/0x58 generic_handle_domain_irq+0x1c/0x28 gic_handle_irq+0x4c/0x120 do_interrupt_handler+0x50/0x84 el1_interrupt+0x34/0x68 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 regmap_mmio_read32le+0xc/0x20 (P) _regmap_bus_reg_read+0x6c/0xac _regmap_read+0x60/0xdc regmap_read+0x4c/0x80 mtk_star_rx_poll+0x2f4/0x39c [mtk_star_emac] __napi_poll+0x38/0x188 net_rx_action+0x164/0x2c0 handle_softirqs+0x100/0x244 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x20 call_on_irq_stack+0x24/0x64 do_softirq_own_stack+0x1c/0x40 __irq_exit_rcu+0xd4/0x10c irq_exit_rcu+0x10/0x1c el1_interrupt+0x38/0x68 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 cpuidle_enter_state+0xac/0x320 (P) cpuidle_enter+0x38/0x50 do_idle+0x1e4/0x260 cpu_startup_entry+0x34/0x3c rest_init+0xdc/0xe0 console_on_rootfs+0x0/0x6c __primary_switched+0x88/0x90 ```

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: drr: Se corrige la doble adición de lista en la clase con netem como qdisc hija. Como se describe en el informe de Gerrard [1], existen casos de uso en los que una qdisc hija de netem hará que la devolución de llamada de encolado de la qdisc madre sea reentrante. En el caso de drr, no habrá un UAF, pero el código agregará el mismo clasificador a la lista dos veces, lo que causará corrupción de memoria. Además de verificar que qlen sea cero, este parche verifica si la clase ya se agregó a active_list (cl_is_active) antes de agregarla a la lista para cubrir el caso reentrante. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pds_core: eliminar escritura use-after-free de client_id Apareció un error de use-after-free en las pruebas de estrés: [Lun 21 Abr 21:21:33 2025] ERROR: KFENCE: escritura use-after-free en pdsc_auxbus_dev_del+0xef/0x160 [pds_core] [Lun 21 Abr 21:21:33 2025] Escritura use-after-free en 0x000000007013ecd1 (en kfence-#47): [Lun 21 Abr 21:21:33 2025] pdsc_auxbus_dev_del+0xef/0x160 [pds_core] [Lun 21 Abr 21:21:33 2025] pdsc_remove+0xc0/0x1b0 [pds_core] [Lun 21 Abr 21:21:33 2025] pci_device_remove+0x24/0x70 [Lun 21 Abr 21:21:33 2025] device_release_driver_internal+0x11f/0x180 [Lun 21 Abr 21:21:33 2025] driver_detach+0x45/0x80 [Lun 21 Abr 21:21:33 2025] bus_remove_driver+0x83/0xe0 [Lun 21 Abr 21:21:33 2025] pci_unregister_driver+0x1a/0x80 La desinicialización real del dispositivo suele ocurrir en un subproceso separado programado después de que se ejecuta este código, pero no hay garantía de que Orden de ejecución del hilo, por lo que esto podría ser un problema. No es necesario borrar el client_id en este punto; simplemente elimine el código problemático.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xsk: Corrige la condición de ejecución en la ruta RX genérica AF_XDP Mueve rx_lock de xsk_socket a xsk_buff_pool. Corrige la sincronización para el modo umem compartido en la ruta RX genérica donde varios sockets comparten un solo xsk_buff_pool. La cola RX es exclusiva de xsk_socket, mientras que la cola FILL se puede compartir entre varios sockets. Esto podría resultar en una condición de ejecución donde dos núcleos de CPU acceden a la ruta RX de dos sockets diferentes que comparten el mismo umem. Protege ambas colas adquiriendo spinlock en xsk_buff_pool compartido. La contención de bloqueos se puede minimizar en el futuro mediante algún búfer FQ por subproceso. Es seguro y necesario mover spin_lock_bh(rx_lock) después de xsk_rcv_check(): * xs->pool y spinlock_init se sincronizan mediante barreras de memoria xsk_bind() -> xsk_is_bound(). * xsk_rcv_check() puede devolver verdadero al ejecutar xsk_release() o xsk_unbind_dev(); sin embargo, esto no causará ejecucións de datos ni condiciones de ejecución. xsk_unbind_dev() elimina el socket xdp de todos los mapas y espera a que se completen todas las operaciones de recepción pendientes. Los paquetes en la ruta de recepción se completarán correctamente o se descartarán.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ptp: ocp: Corregir la desreferencia NULL en las operaciones sysfs de SMA de la placa Adva En las placas Adva, las operaciones de almacenamiento/obtención de SMA sysfs pueden llamar a __handle_signal_outputs() o __handle_signal_inputs() mientras los punteros `irig` y `dcf` no están inicializados, lo que provoca una desreferencia de puntero NULL en __handle_signal() y causa un fallo del kernel. Las placas Adva no usan la funcionalidad `irig` o `dcf`, así que añada las devoluciones de llamada específicas de Adva `ptp_ocp_sma_adva_set_outputs()` y `ptp_ocp_sma_adva_set_inputs()` que evitan invocar las rutinas de entrada/salida `irig` o `dcf`.